We need to be clear about database structure versus presentation. I agree that what you describe is a reasonable compromise between not wanting meta in your way when dealing with normal site content, but making it more obvious to everyone that it exists.
In contrast, the database structure doesn’t need anything more than some sort of ID field indicating a post is meta. Of course it could be quite separate in the database too. I leave that to the DB experts here. I’m not qualified to understand the pros and cons of such a choice.
Meta shouldn’t too prominent either. We don’t want every lazy student that didn’t get his homework answered in 60 seconds coming to meta to complain, ask why it’s off topic, etc. It has to be at least a little effort. The presentation shouldn’t make it appear as if asking in meta is the “normal” thing to do in using the site. We want people in meta that are at least a little invested in the site. Perhaps that’s done by earning the privilege, a minimum rep level, or something.
Exactly. Not sure (as I have been only partly following the Trust Level discussion), but maybe something like not allowing any posting (Q/A/comment/anything but read-only or simply voting) until Trust Level 2 on the matching Main site (IIRC, TL0 = new/not-even-signed-in, TL1 = signed-in, TL2 = moderate activity completed).
Right. I’m talking in this thread about function and presentation, not implementation. The proposed DB schema already has the “isMeta” flag.
I actually don’t mind if we do something similar to SE here: anybody can post to meta about one of that user’s posts on main. New users with good intentions who get a bad start should be able to seek guidance, and not by having long discussions in comments on main. But I also don’t even mind meta, like main, being open to anybody (subject to the usual rate limits); meta shouldn’t be more strict than main. If something is out of place, the community will handle it.
A first visit to meta, and starting a first meta post, should be met with some just-in-time guidance – hey, this is meta, which means… etc.
Meta isn’t just site-building; it’s also support. And new users need support too, sometimes more than experienced ones. Do we really want to drive away that expert we wanted, just because he asked his first question badly and had no place to turn to for help? This seems counter to everything you’ve said about how we need to cater to, and at least have no barriers for, experts. And at the beginning we don’t know who’s an expert, so that means we need to be open to everyone.
I think the same trust-level restrictions that apply to main should also apply to meta. Meta shouldn’t be stricter.
I’m figuring someone who’s an expert is going to take the trouble to read the site rules, look at some questions, and maybe peruse meta a bit before writing the first answer. If they don’t, then they don’t seem very expert to me. These are things completely under their control. I have little sympathy for someone that just barges in answering questions without at least trying to learn the site norms first. What I don’t want is the site getting in their way if they take a little time to make sure they do things right. People that trip over their own stupidity or laziness, well that’s their problem.
That said, I’m not really stuck on what barriers, if any, should be for meta. I don’t want the place overrun by lazy students, but as you say, there has to be a means to get reasonable help when you at least tried to do everything right.
I think the usual moderation tools will deal with lazy students, and lazy-student posts on meta are already out of the way of the main site. We should be able to handle this without additional restrictions.
Every community has its own quirks and expectations. I’ve seen conscientious SE users still bump into problems that weren’t obvious. Those people aren’t barging in without learning the site rules; they just learned imperfectly or incompletely. If they find their way to meta to ask (as we expect such people will), they should be able to do so. I’d rather presume good faith from users until shown a reason not to.
This reminds me quite a lot of Wiki - each question could have a ‘main’ Q+A tab, a discussion tab, history/timeline tab, as well as other potentially useful things (links to and from, moderation tab etc.)
Based on the discussion here I added Categories to the functional specification. Meta is a category, and is explained as a use case there.
In a chat discussion earlier it seemed like some folks weren’t really getting what I intend here, so here is a crude drawing to show the kind of thing I mean. There’s some other stuff in the picture for context, but the important part is those tab-like things that say “questions”, “blog”, etc. Those are categories. Again, I am not a designer; this is not a design proposal; this is a sketch on a napkin. The questions tab is currently active in this diagram and, yeah, those aren’t good colors either. Work with me…
@becky82 We’ve had quite a few conversations about this. @cellio and I and some others think there is some real value to having items that are not-quite-normal-Q-&-A as part of the user-provided content. This is based on the goal not being simply “best Q&A system”. A key quote from Jeff Atwood’s blog in 2008 https://blog.codinghorror.com/introducing-stackoverflow-com/
It is by programmers, for programmers, with the ultimate intent of collectively increasing the sum total of good programming knowledge in the world. No matter what programming language you use, or what operating system you call home. Better programming is our goal.
Some of that same concept applies here. (Substitute writers/writing knowledge, physicists/physics knowledge, etc.) There are plenty of ways to increase the sum of knowledge besides Q&A.
There are many times I have looked at a SE site and wished there were blogs about important topics - imparting shared wisdom in a non-Q-A format. Or “Canonical posts” that would answer frequently asked questions about a specific domain of knowledge. These are things that can and often are answered via Q&A in SE, but with the catch that the information ends up largely buried as questions age (which typically happens very quickly). Yes, the information can be found if you happen to search for the right stuff - that’s how very old answers to very old questions keep getting (often deservedly so) more Upvotes. But the buried nature of old questions also leads to a lot of problems with duplicates or near-duplicates, or people asking relatively basic questions where if they saw the answers to the “easy/common” stuff they would think a bit more and ask the more detailed expert-worthy questions about the parts that have not been answered before.
This is not to propose an encyclopedia - we have Wikipedia for that. But there is plenty of useful information that can be posted alongside Q&A - that is complementary to Q&A - but which can be best presented in some non-Q-A format.
That being said, not every community will have every piece. Worldbuilding might want a Blog section for people to write their own short stories. DIY might want Canonical to answer the top 10 (or 20 or more) most common questions about electric panels and unclogging toilets, etc. Code Golf might want Sandbox to help people get their Questions ready for the public. And Superuser might not want any of these pieces. Each community will decide what works for them.
Maybe it is just me, but I think this is the general feeling of a lot of users within the network: I don’t care.
The “Canonical” idea seems similar to Stack Overflow’s Documentation (requested for other SE sites), which also failed, despite the massive size of Stack Overflow.
We have finite human resources: users, moderators, and developers. So… I discourage creating competing features (feature creep); features take effort to maintain are hard to subsequently remove without alienating people.
In any case, I’m okay if we disagree here. (I just wanted to mention this in passing.)
I think part of the problem on SE/SO was “one size fits all”. Some communities can (and did) make good use of Blogs. For others there are real problems with that format. I see a few different possible uses for it, both in creative environments (e.g., Worldbuilding) and some of the more technical/scientific. But it won’t be for “everyone”.
Similarly, Canonical posts have a value in some communities (I have already seen attempts in a few SE sites, but hampered by the limit of “just Q&A”). But I don’t see how one would work in, for example, Code Golf. Canonical is not the same as Documentation. It is much more limited and (hopefully) won’t have the same problems. But it is similar in certain ways.
The feature, in this case, is the concept of categories. It’s no additional work for us to have only main and meta, or also wiki or blog or canonical or critique or… whatever sites want. We’re implementing a mechanism.
Some sites invest in canonical posts – not the same as the failed Documentation project, but well-developed oft-needed posts. Because SE has only Q&A and tag wikis, canonical posts end up as one or the other. Users talk about canonical posts but there’s no place to go get them all. If one of those communities were on Codidact, it could decide to do that as a category. Or not – up to each site.
Blogs would be similar. If a site doesn’t want to maintain one, they won’t have a blog category. If SF&F comes here, they’ll probably want that category. Meanwhile, Photography wants something like critiques and (not Codidact but) Physica Overflow has articles for peer review. These are use cases we can support without imposing on sites that don’t need them or wasting development effort on one-offs.
However the failure of blogs on SE raises one question: Should there be a way to retire a category?
Say, a community adds a blog, and then it turns out that it doesn’t work out for that community. Thus they decide to not continue it, but they don’t want to delete all the content. Then there could be a way to retire the blog, which would (a) close it for any new contributions, and (b) remove it from the tabs (but keeps it accessible in a different way, say a special “categories of this site” page).
Thinking about it, a “categories of this site” page would be useful in general. It would list all categories of the site, together with the intended use. For example:
Retired categories also give us a straightforward way to “incubate” new sites. Instead of building a whole separate thing like SE did with Area 51, we can have a “community” called something like new-sites or incubator or whatever. Each proposal is a category within that site. Each proto-site uses its category like a meta site, working out scope and any other points needed before they can open. When the site launches, the category becomes inactive and the content gets copied to the new community’s meta. (I say copy rather than link so that scope discussions can be maintained and marked as dupe targets later, and I say copy rather than move so that the incubator retains history of what did/didn’t work out.)
At first I was going to say “don’t do it that way because it will mess up the code”. Which is because the community_id will be a part of “everything” and in this case it would end up having to be changed.
However, with the understanding that this will be a copy rather than a move, this could work just fine. The catch is that if you have something like Code Golf, where Sandbox is a must, there would end up being two categories within the Incubator community and things could get confusing. Additionally, this would work well for a handful of communities-under-development but not for a large number like Area 51.
We probably won’t have that many concurrent in-development communities in the incubator, but even if we do and that causes “tab overflow” in the UI, the incubator site is going to operate a little differently anyway – its focus won’t be main-site Q&A, after all. So long as there’s an easy way to get to the full list of categories, we can direct people there as needed. I think the benefit of using our own software and not building a one-off thing mitigates the UI not being perfectly tuned for this case.
Sorry, I don’t understand. Each in-incubation site gets one category to use. The incubator won’t have a sandbox. Or are you talking about managing an extant site’s sandbox? In that case yes, I agree it’d be a copy, like what people do with sandboxes on SE today. The point of the sandbox is to get meta-feedback; when you’re ready for it to be on main you want only “regular” feedback.
Worldbuilding - ultimately Main, Meta, Blog - on Incubator they would just have Main (and share Meta)
DIY - ultimately Main, Meta, Canonical - on Incubator they would just have Main (and share Meta)
Code Golf - ultimately Main, Meta - on Incubator they would have Main (and share Meta) but they would also need Sandbox because it is really critical for that specific community.
A shared Sandbox would probably be fine for all the other Incubator sites, but Code Golf uses it in a special way - the level of detail and back-and-forth to work on questions is sometimes quite a big deal. Now, in their case they’ve been limping along with Sandbox = “One question with each proposed Question as an Answer” where what we will hopefully have is “Each question is a Question with discussion/comments but no Answers” - a different mode of operation that should work much better. They can’t just do the same thing here if we make Meta = Questions + discussion with no Answers (which is actually what Code Golf Sandbox should be) because then all those separate Questions would overwhelm the shared Meta. (Not a problem if Meta has Answers).
Oh! We have different ideas about the incubator site (so maybe I need a better name).
I don’t mean something akin to a private beta, where you start using the site in a special mode. I’m talking about a replacement for Area 51. The topics discussed on the incubator site are by definition meta. The purpose is to give a proto-community a place to discuss potential questions, scope boundaries, whether to launch with a sandbox, tagging approaches, and stuff like that. For that, one category per site is sufficient, and the only sharing is for the Q&A about incubation itself (which go on the incubator’s “main” list).
Personally, I don’t think it matters that much if meta is on a separate site or not. However, one thing I think was bad with their version of meta was to have discussions on a QA-platform.
When there are actual questions about the main site, QA-form works perfectly. But it works far less good when it comes to things that are actual discussions.
On the SE-network, I always missed a regular forum connected to the network.
