Proposal: Meta and discussion posts

[cellio]

Our MVP requirements include having a place for meta activity.

We know from our experience on SE that the Q&A format does not always fit meta needs well. Meta is by definition more discussion-oriented, and voting doesn’t necessarily mean much. Also, on SE most users don’t participate in meta; it’s another place you have to go and, even with the publicity of the community bulletin, most don’t seem to go there.

With all that in mind, I propose the following functionality:

• Meta is not a separate site but a flag on a post. “Meta post” here means posts that have this flag set.
• There is a post type of “discussion” that is modeled on the “question” post.
• Question posts may set the meta flag. Discussion posts must set the meta flag, barring a strong argument to the contrary. Discussion posts are an affordance for meta, not an invitation to turn Q&A into Quora.
• On discussion posts, comments are visible by default – comments are more important in meta discussions than on main Q&A.
• Discussion posts have a way to record a resolution. (This might be something like a pinned answer. TBD.)
• Discussion posts with recorded outcomes are treated as resolved (closed? something else?).
• Meta posts are clearly visually different from questions; a casual observer can tell that it’s a meta post.
• During the first “reasonable amount of time” of a site’s existence (configurable), meta posts are displayed on the main site alongside regular questions. I expect this to be controversial. My reasoning is that these are formative times for a community and we want to increase engagement. After this time passes, meta posts are not mingled with main Q&A.
• At all times, users can easily see just the meta posts or just the main Q&A posts.
• Meta posts have tags, which do not mingle with main-site tags.
• Meta posts do not contribute to any reputation score we might display, but meta activity is shown on user profiles and could contribute to privileges in ways TBD.

[celtschk]

I don’t think meta should be a posting type. Meta is a far more diverse beast. For some things that come up in meta, the Q&A format is quite a good fit (when someone has a question about the site). For other things (for example, improvement requests), a discussion format is a better fit.

If we make meta a posting type, then we restrict all meta topics to be of only one type forever.

Now whether meta posts should be stored (and possibly displayed) alongside normal questions, or should be treated more like a separate site is another question; I think a meta flag (or better, a ”subsite” field that could be either “main” or “meta”, so that we can easily add more subsite types should we want them in the future) separate from posting type (question, request) would make sense.

Obviously the only post type allowed on main would be questions (but even that could be configurable, in case we ever change our mind on it, or to support the needs of specific communities), while meta would allow both questions and requests.

[cellio]

That’s a good point. So “meta” is a place, there is a “discussion” post type, discussion post types are only allowed on meta, but meta posts (of all types) can be mingled on main.

[cellio]

@celtschk since this post has only been up a few minutes and I agree with your proposal, I’m going to edit to incorporate it.

[cwellsx]

What’s the effect of SE’s having it on a different site?

1. You must visit one site or the other – topics don’t co-mingle in the list of recent/active topics
2. They have separate tags
3. They have different social conventions (“voting is different on Meta”)

You’re proposing to keep #2 so that doesn’t change.

The main difference seems to be that topics and meta-topics co-mingle.

I think SE separated them because Meta-topics was seen as polluting the main site, and uninteresting to all but the most avid users.

Discourse (e.g. this site) has “Categories” – you can see topics all categories on one page, or topics from one category from one page.

That’s the generalization IMO – if you’re going to have two categories (Meta and non-Meta) then why two 2 – it might as well be ‘n’ instead.

Unlike SE, Discourse has little or nothing in the margins of a page – so very “mobile-first”.

If the design were more like SE’s design for widescreens, then the category-links on https://forum.codidact.org/categories might be a navigation menu in the left-hand-margin.

I think you ought to consider:

• What do browsers/users see – people who only read the site without posting
• What do new contributors see?
• What do experienced/regular contributors see?

Perhaps the first two deserve default setting which are adapted to their condition; and the power users a UI which lets them customise what they see (e.g. a checkbox for each category so they select which categories they see by default).

My principle sadness with the current design on SE is that with vanishingly little new activity on Meta (now that the site is old) people don’t visit and don’t see any new posts there even if there are some – separating the sites works all too well.

As moderator I might like a popup banner I could use occasionally to notify everyone of something new, that’s a different topic probably.

[cellio]

In fact yes, there could be more than two areas. The canonical posts being discussed in another thread (modeled on academic reviews) could be another. And a question sandbox could be yet another.

[celtschk]

I think drive-by users (that is, users that are not logged in) should not see meta posts between the normal questions by default. They have no use for them.

For logged-in users, one option would be to show only unresolved meta posts on the main page (so that independent on your sort order, you’ll never be overwhelmed by obsolete meta posts). That would require a way to mark any type of meta post as resolved.

Of course if you go to the dedicated meta section, you’ll always see all meta posts.

[luap42]

I think this could be differentiated into the “homepage” and the “question list page”, as SE is doing it already. We could show all elements on the homepage, as it would be the site activity summary. On the other hand, when you only want specific elements, you have to go to special pages (for example question page, meta discussion pages…)

[cwellsx]

Right, so you might just have two predefined (out of the box) categories – one being “Meta” – and pre-populate Meta with standard meta-tags.

If you’ll use “category” e.g. to implement “sandbox” and “canonical” use-cases, then when an Admin creates a new Category perhaps they should be allowed to specify whether this new category has its own set of tags, or whether it shares tags with another category.

---

Incidentally (on the subject of tags) when I wrote my little prototype it was the tag selector (i.e. under the edit box of a new topic) that was by far the most complicated/interactive bit of UI to implement – it took more than week iirc admittedly I was a beginner and learned while doing it)

https://codereview.stackexchange.com/questions/223796/emulation-of-ses-text-input-control-for-tags

So I hope you may pay due attention to your UI design of that, before you code it.

[Olin]

@cellio

In fact yes, there could be more than two areas.

As a SE user, I always liked that meta was separate from the regular Q&A. I’m in a different mental mode when answering technical questions than when discussing the site. Also, I would check meta maybe once a day or two, but check active questions whenever I had a few spare minutes. When checking regular site questions, I wouldn’t have wanted meta questions in my way.

I suppose you can mix various types of posts together, but “switching” from exclusively regular site content to exclusively talking about the site needs to be a simple click, as it is now.

[cellio]

New proposal, taking into account all the feedback here:

Site structure:

• A site has a concept of categories. Main-site content (the main Q&A) is the main category. Meta is another. (There could be others in the future, like blog posts or a sandbox or canonical posts.)
• The site provides clear affordances for switching among categories, such as tabs.
• A category may share a tag set with another category or have its own.
• By default, posts are shown only in their own categories.
• Moderators can additionally publicize a post in any category to the main category.
• Not MVP, but don’t preclude: users can choose to show all posts from selected other categories on the main page alongside the main Q&A.

Meta:

• The meta area, meta posts, and meta tags have clear visual differences from main-site analogues.
• There is a clear way to make a meta post. This could be a separate “ask on meta” affordance or a choice on the “ask question” page or something else.
• Meta posts use a tag set that is separate from the main-site tag set.

New post type: discussion (not required for MVP, but desired)

• A discussion is a top-level post (like a question), but the only supported responses are comments (which will be threaded, same as elsewhere).
• Comments on discussion posts will not be as aggressively collapsed as on questions and answers. (Ideally comments are expanded by default unless there’s a ridiculously large number.)
• A discussion can be resolved by either the author or a moderator. Resolving a discussion adds an answer in which the resolver describes the resolution.
• Discussion posts must be meta posts.

[manassehkatz]

@cellio

(There could be others in the future, like blog posts or a sandbox or canonical posts.)

I think Blog posts and Canonical posts related to the prime topic matter of the site should not be separate categories, they are simply different Post Types. That is important because it affects search - both manual and automatic “related” displays.

Sandbox, which AFAIK currently only gets serious use with Code Golf (where it is vital), is a different Category because, like Meta, it is different in usage. Just as Meta is for Q&A about the site/community as opposed to the prime content of the community, a sandbox is different because it is about getting Q ready for publication - i.e., those questions are not “to be viewed and answered” but rather “fine tuned and improved until they are ready to become main site Qs”. Having this as a separate category of Q&A should be a big improvement as the current Code Golf sandbox is simply one Meta Q with 2,653 A.

@cellio

A category may share a tag set with another category or have its own.

Agree they may need to be separate. I suppose sharing could be done with a flag in the Category table (much like a flag in the Member table to say “same info for community as for main instance”). But definitely not “mix and match” - each Category within a Community has to either share the main Tag set of that Community or have its own Tag set.

@cellio

users can choose to show all posts from selected other categories on the main page alongside the main Q&A.

This would be very nice.

@cellio

Meta posts use a tag set that is separate from the main-site tag set.

Not inherently. But agree it makes sense. My point is: no need to code that special - just use the “Category has same/different Tag set” setting for Meta as for anything else, and default it to “different” on any new Community-Meta.

@cellio

New post type: discussion (not required for MVP, but desired)

• Discussion posts must be meta posts.

Don’t look at it as “Discussion posts must be meta posts”. Instead look at it as:

• Each Category has certain types of Posts. With a typical setup being:
• Main: Q&A, Blog, Canonical
• Meta: Q&A, Discussion
• Sandbox: Q&A
  etc.

Then it is not “Here is how Meta works”. Rather, it is:

• We recommend each Community in each Instance have a Meta Category, configured as follows:
• Name: Meta
• Post Types: Q&A, Discussion
• CSS: “meta-style”
• Specific Privilege/Trust Level settings
  etc.

How Meta gets used - or even whether it has the name “Meta” vs. “Town Square”, etc. becomes very configurable (aside from also being “directed” by the policy statements of the founders and moderators of the Community). Some places may not want much of a Meta - maybe just Q&A. Some may want 2 Meta-like communities - one for administrative issues and one for technical. etc.

[cellio]

Worldbuilding makes heavy use of its sandbox too. And I thought there was at least one more site that does so, though I don’t remember which.

@manassehkatz

But definitely not “mix and match” - each Category within a Community has to either share the main Tag set of that Community or have its own Tag set.

Definitely. Share or don’t share, but you can’t share just some.

@manassehkatz

Meta posts use a tag set that is separate from the main-site tag set.

Not inherently. But agree it makes sense. My point is: no need to code that special - just use the “Category has same/different Tag set” setting for Meta as for anything else, and default it to “different” on any new Community-Meta.

I’m specifying function, not implementation. I agree this shouldn’t be hard-coded; it should use the general mechanism. Functionally, we’re specifying that meta will set that flag in that particular way.

@manassehkatz

Don’t look at it as “Discussion posts must be meta posts”. Instead look at it as:

• Each Category has certain types of Posts. With a typical setup being:
• Main: Q&A, Blog, Canonical
• Meta: Q&A, Discussion
• Sandbox: Q&A
  etc.

Yes, that’s better – and points to a flaw in my proposal: a sandbox area should have only discussion posts! That is, the point of the sandbox is to post a draft and collect feedback (and, ideally, edit in response to that). SE sandboxes only use answers because they don’t want to have a gazillion sandbox questions. But we can have a segregated category for those, with one post per sandboxed question.

[Olin]

@cellio

Site structure:

• A site has a concept of categories . Main-site content (the main Q&A) is the main category. Meta is another. (There could be others in the future, like blog posts or a sandbox or canonical posts.)
• The site provides clear affordances for switching among categories, such as tabs.
• A category may share a tag set with another category or have its own.
• By default, posts are shown only in their own categories.
• Moderators can additionally publicize a post in any category to the main category.
• Not MVP, but don’t preclude: users can choose to show all posts from selected other categories on the main page alongside the main Q&A.

This seems to conflate two distinct things: Structure (Q&A, blogs, papers, discussions) and content (site topic or meta).

Your idea of tabs or similar for switching content makes sense. But, posts with different structure should be mixed, although clearly marked.

For example, on the Basket Weaving site, the recent activity on the front page for the main site content would show both a question on how to make shaved pine strips with a blog about someone’s experience on using dried seaweed as the material. You’d have to deliberately switch to meta to see questions and discussions about the site itself.

@cellio

New post type: discussion (not required for MVP, but desired)

Agreed that forum-like discussions could be useful, but certainly not MVP.

[Tensibai]

Maybe a bit blunt: this actual place sound very fitting for “meta” talks about the system, specially as the design talk about the system are taking place here actually, most supports talks would also fit.

Does replicating SE “way of being” with a Q/A for talks really worth it or could this role be delegated to something more like this forum ?

From the few posts/points I’ve seen here, talks flow, decision are marked with a nice “yellow” highlight. What is missing that require to spend the extra work to create a “Meta” clone as well ?

(extra side note: with the loaded reputation of the term “meta”, should it be named something else ?)

[Lundin]

Regarding categories and tabs:

One thing I’d love to see (though not necessarily MVP) is to have a “meta tab” per main-site post. On the meta tab, all discussion, clarifications, support issues etc related to the specific post could be posted. Including stuff like:

• “How should we moderate this post? Why was it closed/deleted/re-opened?”
• “Why wasn’t this question well-received? How can it be improved?”
• “I did a review of an edit (etc) on this post but it was declined, why?”
• Comments/discussions migrated/moved away from the main post.
• A place to dump deleted answers visible only to those who can see them.
• Canonical status/community wiki maintenance discussion.

This way we can separate the endless localized support requests like the examples above from big picture meta discussions. The whole community does not need to read or have an opinion about why Bob got his question closed this morning. But they do need to know about upcoming site changes, moderator elections etc.

This also solves common meta problems like:

• “Please link to the post where this happened”.
• People on meta are discussing your post, but nobody remembered to poke you. With this model, the site itself will do the poking.

[cellio]

@Olin

This seems to conflate two distinct things: Structure (Q&A, blogs, papers, discussions) and content (site topic or meta).

No, content types can be mixed in all areas. There could be canonical meta posts or sandbox blog posts for all we know.

“Meta” is a category of content. We expect it to contain Q&A and discussion posts. It could contain other things.

“Main” (which needs a better name) is a, and the primary, category of content. It’ll be mostly Q&A but could include other post types.

I brought up discussion posts here because there’s been a lot of talk about Q&A not working well for some meta cases, and we already know we’ll want other post types. Meta is a motivation for the discussion post type. The discussion post type is not required for MVP; if our meta category has only Q&A, we’re not worse off than where we’re coming from. Ultimately we should do better.

@Olin

For example, on the Basket Weaving site, the recent activity on the front page for the main site content would show both a question on how to make shaved pine strips with a blog about someone’s experience on using dried seaweed as the material. You’d have to deliberately switch to meta to see questions and discussions about the site itself.

Yes, agreed. This is what I had in mind. How can I make it clearer in what I wrote?

@Tensibai

Maybe a bit blunt: this actual place sound very fitting for “meta” talks about the system, specially as the design talk about the system are taking place here actually, most supports talks would also fit.

We’re using this forum for discussions about building the system itself, and we’re already seeing the strain with long, hard-to-navigate, unsorted threads sometimes. It’s fine for us for now, but I don’t think it’s a good solution for communities to work out their questions around site scope, moderation policies, appeals (why was my question closed etc), seasonal challenges, and whatever.

@Tensibai

From the few posts/points I’ve seen here, talks flow, decision are marked with a nice “yellow” highlight.

This is the idea with the “discussion” post type, which includes a resolution. Sometimes that’s what we need. Other times the Q&A format works better. Meta can use both.

@Tensibai

(extra side note: with the loaded reputation of the term “meta”, should it be named something else ?)

Probably. Suggestions welcome.

@Lundin

One thing I’d love to see (though not necessarily MVP) is to have a “meta tab” per main-site post. On the meta tab, all discussion, clarifications, support issues etc related to the specific post could be posted.

I like this idea. We’ll need to talk more about how it would work and how it integrates with the actual meta category (the post should show up there too). Not MVP but we should think about this more.

[shagie]

One of the challenges that trying to sequester discussions to a meta place is that many users (especially new users) want discussions. It is not infrequent at all to see new users post on foo.meta.stackexchange.com with the discussion tag looking for a discussion on a main site topic. SE tried to encourage chat for discussions, but only a very small percentage of the people who want to discuss things want to discuss them in a real time chat.

Trying to keep meta there (but in the same overall format), and have only discussions on meta means that that new users will continue to be confused about the boundary of what is meta and what is a discussion.

Having meta be on a completely different site (not mixing meta in with main), with a completely different format is thus a good thing. This is one of those things that SE did get right (and it took them some time to get there). The two posts about these lessons learned are https://blog.codinghorror.com/meta-is-murder/ and https://stackoverflow.blog/2009/06/28/cmon-get-meta/ … and ironically, its what they’re getting wrong now.

From the coding horror post:

(Josh Millard, a MetaFilter moderator): … A lot of people cite MetaTalk as a reason that MetaFilter works. If you talk to a regular from the site they’ll tell you MetaTalk is key to the success of the site because it’s a sort of release valve. Talk pages on Wikipedia are a similar thing. I had the same experience as you the first time I checked those out – it’s not necessarily comprehensible to the casual user what is going on there. But for the people who are regulars, the people who develop a certain amount of passionate attachment to the sites, or really, really need to make their voice heard out of day one beyond just normal participation, you have this safe place you can let people … let their freak flag fly, as it were, without damaging the core function of the site. You don’t have big messes on the front page.

And while SO did get part of it right, they didn’t go far enough. From the SO Blog post:

• Comments? word and formatting limitations prevent any meaningful discussion.

But they also got it wrong in that they left it in the Q&A format that was specifically designed to stifle discussions in comments.

And so the comments of Kyle bad then haven’t ever happened.

• wording needs to be tweaked (i.e. questions->topics, answers->replies)
• need to be able to follow questions/get notices of additional replies
• remove notion of community wiki, as discussion sites have a stronger sense of ownership, plus nothing will be off-topic
• ensure that chronological ordering is the default, if not the only, sort order, both for replies and comments
• remove accepting an answer
• some of the close reasons will have to be removed or tweaked

Same identity maintained between the main site and meta, but SE made a huge mistake in restricting meta to the same engine as the main site and thus hampering the discussions that happen… and more recently, not recognizing its value as a release value for the social pressures.

Keeping this in mind, it is important to recognize also that meta is a poor bug tracking system, Q&A makes a poor format for blogging and announcements, and the community that forms around meta needs to be able to discuss things. From https://tools.ietf.org/html/rfc1925

(5) It is always possible to aglutenate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.
(6) It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it.

[celtschk]

@Tensibai

Maybe a bit blunt: this actual place sound very fitting for “meta” talks about the system, specially as the design talk about the system are taking place here actually, most supports talks would also fit.

There are several reasons why this place is not a good fit for “meta”:

• First, this place is about the development of the software.

  Global meta is about the instance. There are lots of things you would discuss on meta that simply don’t fit here. For example, policies of how the site operates.

  Community-specific metas would be about the specific topic communities. Topics that belong there, like questions on what is on-topic and off-topic in that community, are even more off-topic here.

• Besides our instance, there may be other instances of the software, possibly used for completely different purposes. I hope it is clear that we don’t want those to discuss their specific issues here. And conversely, since those instances may be private, and possibly even contain confidential data, people on those instances may not want to discuss their stuff here either.

• It is a separate place with separate user handling, separate login, separate everything. I’m already not happy with the number of different places for Codidact development (GitHub, Discord, this place, and someone suggested a fourth place for organizing development, where I’m not sure about the status of that proposal (I didn’t sign up for it, because I only will do as soon as I know it will be required). Now I understand why this happened, but it would be much better if GitHub provided all the facilities we need for development (forum, chat, whatever that other site provides that GitHub apparently doesn’t), so I’d need to follow just one place.

  Moreover, the more different places you use, the more danger you have of having identities bleeding over. You may be content to have just one identity for everything on the internet, but I maintain different internet identities for different purposes. And the Discord use by this project already caused an unintended link between two identities of mine.

Does replicating SE “way of being” with a Q/A for talks really worth it or could this role be delegated to something more like this forum ?

You are mixing two concepts: Meta being on the same site, and meta being the same format. We are already planning to have discussion-type posts (that is, posts that function more like forum posts) for meta (besides conventional Q&A type meta posts, because for some things also on meta, the Q&A form is just right).

From the few posts/points I’ve seen here, talks flow, decision are marked with a nice “yellow” highlight. What is missing that require to spend the extra work to create a “Meta” clone as well ?

Integration with the site. Note that one reason why I’m very rarely using chat on SE is its bad integration (and it’s still better integrated than this forum would be in our site!).

Differentiation per community. Our instance will run many communities (sites in SE parlance). Each community should have (or at least have the option to have) its own meta.

(extra side note: with the loaded reputation of the term “meta”, should it be named something else ?)

Suggestions welcome.

[cellio]

The flip side of completely segregating meta is that you have a community with a bunch of people active on main, and meta decisions are made by the eight people who showed up and voted. I think this is why SE started adding “hot” meta posts to the community bulletin, and why featured posts exist.

I speculate that something that looks more integrated but is still a separate collection of content – like a “meta” tab next to the “questions” tab – will draw more people in while still maintaining a clear differentiation. Things can even be styled differently there to emphasize that meta is different; we’ve recently done this on the Writing site to reduce confusion. It doesn’t have to be, or look like, a completely different site.

But yes, I’m speculating; I don’t have data. I don’t think anyone else does either.