Don’t forget why SE has the closing mechanism in the first place. This is to that the resident users don’t have to keep answering the same thing over and over again. Closing similar questions and pointing them to one canonical question is very useful. I have written questions just for the purpose of them being the canonical question we point others to after closing them. It saves a lot of work. By the way, these canonical questions usually get highly upvoted, so I’m not the only one that appreciates them.
Again, folks, keep the resident users and experts in mind. In general, you seem to be too focused on the users asking questions. You have to make life easy and rewarding for the experts, else the site will devolve rapidly.
I’m not sure what you intended here, but I’m worried how this might be interpreted.
Yes, we don’t care who writes good content. Content stands by itself, regardless of author. However, that is not an invitation to allow any post, regardless of site rules for topicness, technical level, minimum research to be expected before asking, etc.
Each site needs to be able set their own rules in this regard, and then enforce them ruthlessly. It doesn’t matter who posts something, but what is posted matters a lot.
Unfortunately, we often see the what and who blurred, especially when people want less stringent rules. At least on SE Electrical Engineering, we’ve had way way too many rants about how newbies are ill-treated. Bad questions get rough treatment, as they should. Most bad questions are written by newbies. However, that does not mean newbies are ill-treated. There are plenty of newbies that post good questions and get good responses. It’s not about the poster but the post.
So yes, we should welcome good content from anyone, but we also have to deal with bad content in the most expedient manner before it drags down the site and burns out the resident answerers. Let’s make sure that welcome useful content from anyone doesn’t turn into “save the poor newbies” mentality or any other excuse to be less vigilant against low quality.
I agree with the pointing to canonical questions. But I do not agree with the closing of the question (or at least a reasonable sized group on stats.se seems to think so).
A lot of questions on stats.se are applied mathematics questions. Such questions stand on their own, yet they may relate to each other. For instance, there are many questions about finding the maximum likelihood in some way or another. Sometimes several relate to a similar concept, and for this case you could often direct them to some more abstract or more general canonical question. However it is not entirely useless to have those more pragmatic worked out cases.
I do not believe that closing such questions would do justice to reasonable questions that may not be fully answered by the canonical example.
Otherwise, we might suffice with only a couple thousands of general questions like ‘how to fit a curve?’ or ‘how to detect and remove outliers?’. I do not believe that this is a good way. The power of the SE sites is that the questions are very applied and from real world problems rather than these idealised questions types.
Or take math.se as example. Often questions boil down to using a particular technique (which is reoccurring in many questions). But the challenge is to find which technique to use. You can’t refer all those questions like ‘what is the integral of … ?’ to a canonical answer like ‘how to integrate?’.
Bear in mind, folks, that a lot of this sort of thing will be determined not by the software, but by site/community policy - in which case it’s not a question of what we’re trying to build, it’s a question of what community we’re trying to foster.
What we’re trying to build remains, as it always has been, an open, community-focused Q&A platform, and we’ll build the software to support that aim. How we handle different kinds of content from different people will be down to community policy.
Not entirely. The software has to include the mechanisms to carry out that community policy. The ability to close questions is one of those.
Experience has shown that with a large enough user base, there are always a few that give direct answers to homework questions, answer really bad questions, or otherwise can’t resist looking smart even at the expense of the site. Closing questions is necessary to prevent these people from hurting the site in the long run. Those that post bad questions must not get the desired result. Otherwise, there is no cost, and they’ll keep doing the same.
I intended to refer to useful content; that which is off-topic, blatantly duplicate, spam, rude ranting is in my view not useful for QA.
As for the ‘anyone’ part; there had been some discussion about being expert-focused, expert-driven, for experts by experts. While such things can produce valuable output, and I can definitely see potential value in such a proposal in some areas, the software we build and the wider community we surround it with should not cater to that exclusively.
I think this distinction is a useful thing to bear in mind, in the same way that Codidact is the name of the software, not the (or an) eventual community site.
However, while fostering is a good word to describe gathering a community; ‘building’ is good as well. We’re setting in place limits on what the software will achieve, definitely for MVP and in some cases perhaps for the long term, if not for good. Some folks would be delighted with an identical clone of SE’s software, absent SE Inc. Others have a more radical view of how to shake up QA.
This topic has gathered a wide range of views which fall on the spectrum of community policy vs functionality determined by software; and that’s very useful. It behoves us all to know the rough direction of travel on both. If nothing else than purely from the point of view of engagement and contributions-- in the same way it would be unfair to expect someone with absolute no knowledge of C# or similar to write our backend; people want to create the kind of QA site they feel is beneficial.
…what’s actually being built? Are we building software for people to run on, a central site for people to work from like SE, or something else entirely?
The primary goal is to get a better replacement site for SE. Which we plan to run ourselves because we know best what we want.
For that, we are building our own software (because we decided that the available software doesn’t fit our needs). Thus our secondary goal is to write software for the site to run on.
And since that software will be Open Source (so that, should our site go bad any time in the future, others can just take the source and take over). and since Open Source works best if there are more users to it, a tertiary goal is to make the software sufficiently flexible that other people can use it for their own purposes (this also indirectly benefits our site because it increases the likelihood that newcomers to our site will already be familiar with the interface e.g. from some company-internal Q&A site).
And if someone else uses our software to make a site that fulfils our goals, and people go there, my personal opinion would be: Mission accomplished. After all, we don’t want to build the site in order to be the ones who run it, we build it in order to have a site that works well. If others do that work for us,more power to them.
A rival/friendly and better than SE network based on a customized version of that under non-profit, quality content oriented government.
Interestingly enough, this doesn’t say that “the user community” governs. It states the goals of that government, but in no way how it expresses the wishes of the “majority” of users of that service.
For me, that is a key thing: to define a “constitution” upfront that ensures that
“the community” is clearly defined
the rules and interactions between “the community” and the “service providers” are clearly defined
This is not a discussion we are having here. Everyone is welcome to participate in the Codidact project or on the Q&A site when we get there, as long as they adhere to our Code of Conduct.
My feeling is that tag-wikis are to hard to find on stack exchange and are vastly under-utilized.
But to change that—if we want to have an equivalent—they need to interact with both the user-rating system and the search system on an equal (or at least comparable) footing with normal posts.
The only incentives to work on tag-wikis on stack exchange are intrinsic: say I want the site to host a good summary of neutrino basics. Because the system provides no extrinsic incentives.
And for that, a Codidact community can create a wiki or canonical-posts category. Maybe we don’t need tag descriptions. I think we don’t need them for MVP in any case; let’s drop that and save ourselves some UI scope for now. If there are tag wikis they need to be created, editable, edit-reviewable (and we don’t have queues, so you’d have to notice the pending edit in the wild), and they’re hard to monitor… let’s not.
I think we should distinguish between “tag descriptions” and “tag wikis”. In my (limited compared to some others here) experience on various SE sites:
Tag descriptions
Tag descriptions - the basic text with no markdown - are very important. Some tags on some sites are truly obvious. But some are not, and a few lines of text can be incredibly useful when posting a question. We don’t need full editing MVP - it could be a very basic moderator-only page initially - just a list of tags and descriptions and fill in the blanks. No markdown. Nothing fancy. Initial rollout of each community can have “load up initial tags with descriptions into the database” as part of the process.
Tag Wikis
I think these are way underutilized in SE, because they are hard to find. At least they are for me, and I am a reasonably advanced user (and a programmer). Actually, at the moment the only way I can find to view Tag Wikis is to Edit a tag - and getting to that is non-trivial. I should, for example, be able to get to view a Tag Wiki by clicking on the tag on a question - Aha! now I found that “Learn more…” will get me to the Tag Wiki. Not obvious at all.
End result: If we have Tag Wikis, definitely not MVP and definitely not without serious consideration as to how use them effectively and to consider “Wiki” (hyperlinked series of information pages about a topic) or “Canonical” (Individual pages about specific topics in-depth) as possibly more useful alternatives.
I’d prefer the short descriptions have markdown, or at least a way to make links to other tags and meta discussions. If they have a max length it should also be longer than SE’s.
I admit I don’t see much need for a fuller wiki system. For the sites I’m familiar with they’d usually prefer to use Wikipedia. But I can imagine that some sites might not meet Wikipedia’s standards and they could prefer to have a fuller wiki system.
But in that case, should it really be tied to the tag system? What advantages does that hold? Thinking long past MVP, if blogs etc come into scope, why not a separate wiki system, not too closely connected to the tags?
It occurs to me that the same markdown and length limits that apply to comments should probably apply to tag descriptions too.
Makes sense to me. And a tag description could always link to a blog post if they are tightly coupled.
I’m hoping blog posts will be v 1.1. A blog post, structurally, is just a question that doesn’t accept answers. Eventually we’ll need UI for choosing a post type, if a category supports more than one type, but a step on the way there would be to say that blog posts can’t mingle with Q&A. We could fix that in 1.2 or 1.3…
I think each Category should be a single Post type. That keeps the UI - and a lot of the coding - much simpler. As I’ve mentioned before, the differences between different Categories can be a combination of:
Which set of Tags (Meta typically different from Main, but others (Canonical, Blog, Sandbox) likely sharing with Main)
Title of “Question” - Q&A = “Question”, Canonical = “Post”, Blog = “Blog”, etc.
Are there Answers?
Are there Comments?
Single Author (though editing by others is OK) or “List of Authors with % of Changes” (sort of like “Community Wiki” in SE), which would be appropriate for Canonical and some other types that are more collaborative.
Overall Structure - this is where Wiki would be different because (in my concept), Wiki would be a single master post with everything “linked in”. So while there could be a list of Pages which would be like a list of Questions or Blogs or Canonical Posts or Meta Topics, for a Wiki to work well each page needs to be linked to at least one other page - i.e., need to track/manage “orphan pages”.
I don’t want to bake in “one post type per category”, because meta can reasonably call for all of question, discussion, and announcement (blog post). We don’t need that flexibility now, but we shouldn’t cut off that path. For MVP meta has Q&A, but we’ve seen plenty of cases on SE where that was not the right tool for the job. We can do better.
The post types I currently envision are:
Question: accepts answers, comments collapsed
Discussion: accepts a single answer (resolution) with restrictions about authorship; comments are expanded (the whole point being to have a discussion)
Article (aka blog post aka announcement aka wiki) – name TBD): no answers, comments collapsed
Community-edited canonical posts are articles with broader editing access (wiki).
That’s one way to use wiki posts, but I don’t think we need to bake in that assumption. Maybe a wiki post stands alone without links. For example, maybe a community’s FAQ is implemented as a wiki.
Sandbox. No answers; comments expanded. Also should have a way (not just “embed in the markdown text”) to connect to a single Question in the Main Category once the Sandbox Question “goes live”.
I think of “category” as a way to organize the information in different “categorical” ways. My solution to Meta might have two different categories (e.g., Meta Q&A, Meta Discussion), just like (in a sense) Main would have Main Q&A, Main Canonical, Main Wiki, etc.