Are we primarily helping the asker or building a repository (or sticking to the middle ground)?

Yes what you say there is very much the ethos around comments on StackExchange – that, and preferring to post a comment instead of editing each other’s answers.

This isn’t only an SE clone/replacement though, is it? But more general.

So IMO the use case, people meet online to discuss drafts of a document – and may or may not eventually produce a “final” version.

But, I don’t know, look at Parliament – they pass written legislation eventually after talking about it, but there are wonks (possibly including judges sometimes, I don’t know) who want to look behind the document and see the intent: whose idea was this? what did this bit mean, exactly? was it important, can I change it? and so on.

This functionality might not be for an initial MVP.

I’d like to propose it though as an inherent capability of the software, while we’re “brainstorming”. There might be a simple way to implement it – possibly by version controlling the lot, plus being able to assign moderator-like privileges to some user[s] but limited the scope of that to a specific document (i.e. not site-wide), so they can control the commentary.

Of the first 4 bullet points (i.e. “section headings, anchors, TOC, comment on sections”), the first three might be fairly localised, features of the markdown editor/converter.

It’s the last one – i.e. “comment on sections” – that’s the wildcard in terms of the “database schema” given that we’d also want to be able to edit the document, rearrange its sections. There’s the rub, perhaps, and how obviously to implement that I suppose might depend on what kind of database it is (“relational” or “document-oriented” or some hybrid).

I didn’t know the Beta existed, I wish I’d seen it.

I don’t know but this post …

… might imply that the problem was mostly commercial …

In order to hire more people, we need to make more money. That might mean helping more developers find a great job or selling more ads or signing up more businesses to use Enterprise. In the future, it might mean selling Channels to new teams. The business pitch for Documentation was that it’d bring in new users who might be in the market for a job. If the feature were particularly successful, it would create new opportunities to sell advertisements. At the end of 2016, we established a metric to aim for: substantially increase the number of Documentation users.

By May, it was clear we weren’t on the right path. New users weren’t coming to Documentation. So we went back to the drawing board and started another round of user interviews focused on Transact SQL. We brought on a user experience researcher to help us interview technical writers. The results were encouraging in the sense that we know a lot more about what makes for great documentation and how we might support that effort. But it was also clear fixing Documentation would require a significantly larger team.

In addition, it’ll be a very long time before that work will pay off in terms of bringing new users to Stack Overflow. Our interviews showed even very experienced users of T-SQL felt inadequate to contribute documentation. Users with less Stack Overflow experience tended to be intimidated by the prospect of making even trivial edits. So the programmers most likely to become Documentation contributors were already heavily engaged in using Stack Overflow.

… plus I don’t know it’s saying there about T-SQL but maybe it was hard to use as well.

Does that sound like “similar problems” or maybe not?

Good point. While conceptually trivial, it could easily fall apart in the case of deleted sections, merged sections or rearranged sections. Particularly if people comment on sections in the natural manner of:

Section A blah blah blah

Comment: Not enough blahs

Section B Lorem ipsum

Comment: Too much Latin

Section C Lorem ipsum blah blah blah

Comment: See my comments above

And then the author fixes up some stuff and moves Section C to the top and now that comment makes no sense without checking through the Edit History.

So yeah, probably best to leave that piece out of V1.0.

The original motivation for Docs was split: there was a notional technical reason (create value for the web by generating unified high-quality detailed documentation) and a rather divergent organizational reason (get lots of users). Docs failed for SO-the-business on the latter count, and was therefore shut down; it failed on the former count rather earlier, for various reasons that (I think) map reasonably well to my brief and opinionated summary.

Codidact doesn’t particularly have the same organizational motivation, but the technical rationale is similar, and the technical/social difficulties of implementation are therefore likely to be relevant.


4 posts were split to a new topic: What kind of database should we use?

My take on Docs (which is limited - I discovered Docs literally just a few days before it was shut down) is that it was attempting to replace “original vendor documentation” with something better. That is, arguably, something that a lot of systems could really use. It is also something that there are other very structured sites that already do it fairly well (e.g., W3Schools) and it is also a bit tough to get a bunch of volunteers motivated to do that type of documentation in a structured, consistent, comprehensive manner.

What I envision here is something a bit different. For DIY, I wouldn’t try to make a user-friendly version of the entire National Electrical Code - just bite off those few parts that are frequently relevant for the typical homeowner and mix them with real-world application notes. For programming, it wouldn’t be a full PHP or Python or C# manual - but it might be an article about setting up a web server with a common tech stack or some other fairly broad (more than a typical individual Question) but relatively common topic (can’t thing of any at the moment).

This thread has gotten very far afield, and it was pretty broad and opinion-seeking even before that happened. We’re here to build better community-driven Q&A. That can involve other related things like canonical posts too, but we’re not making an “any kind of document for any purpose” repository. When SE did Doc they had to make a whole new thing. Let’s get our first whole new thing off the ground here. Please focus.

1 Like

I’m surprised you’re not interested in a community’s being able to collaborate on authoring/reviewing/editing a body-of-knowledge. SE claimed that one of its two intents was to build a resource for future readers, as well as for getting your own question answered.

The only way to read SE though is via Search or Google, or chronologically if you’re avid and there from the beginning, the different topics are unconnected; it’s only a tag cloud, like a reference manual with an index but no table of contents.

Another use-case, I guess, might be building expertise around an existing document – for an example, start with the completed/published manual of which this is one subsection, and then be able to ask questions about the contents of that document – “I’m trying to X and it doesn’t work?”, “I don’t understand how to use X?”, and, “Can I see an example of using X?”.

I do think it’s also within the scope of the what SE is used for – i.e. canonical answers to novice questions, which are literally the “frequently-asked questions”. Those canonical answers are tagged, and they are (should be) curated so that they may cover some topic and subtopics but without overlapping – eventually you can read them like a book (if you are the kind of person who reads FAQs, which e.g. programmers are) – therefore IMO information-which-evolves-into-a-book is in-scope.

I mean it’s fine if your idea of “community-driven Q&A” is limited and isolated like SE’s. But theirs is limited by design – of the UI, of the social interaction, and of the structure of the resulting data.

If you wanted to make “a better SE” then I thought that “a better Wiki” might be in-scope too – not to implement immediately even but to foresee how the MVP might want to evolve – to avoid baking the MVP in a way that prevents such extension.

I’m a little fearful of using a relational database, not because I don’t know how but because of how that might constrain what can be implemented. I’ve been interested in this problem (“documents”) for a while – I’ve been a technical writer.

In a previous personal experiment I found that “trees” (e.g. “subsections” and “threads”) do not play nicely together with “SQL” (and DDL).

Combining them seems to me a job for the clever, or the professional masochist with an unlimited R&D budget – or systems programmers who write database engines and their extensions, and not for application programmers.

There are vendor-specific (database-engine-specific) extentions for trees and XML – but.

And I think you see that in SE – that the product is constrained by SQL (as if its underpants were showing) – that it’s all datatypes and relations which are easily modelled as a relational database.

You said …

… but I just don’t see that as a good thing – not a best practice to be copied.

Theoretically SE’s “tags” can be used to create a Wiki – i.e. each tag is a page of the Wiki, and has its own description, and associated topics.

It’s not used that way though and I’m not sure why, people rarely see more than the tag name and maybe the summary, and choosing the relevant tag[s] is an afterthought to writing your question.

So there’s something really inadequate there, IMO, in the design or support for that:

  • In the UI which leads a novice reader into the site – e.g. it’s not “tag-first”
  • In whether there’s a tag/subtag hierarchy
  • In whether it’s interesting/useful to have detailed text associated with a tag, beyond only the summary
  • In whether that text can be structured – whether you can link to subsections of it, edit bits individually
1 Like

This was not clear to me. Apparently you are proposing a different kind of top level post than a question, which then gathers answers? I thought you were asking about canonical questions, which would still be questions in usual sense, just perhaps tagged differently to point them out.

If you are talking about a truly separate top level post type that is meant to be a collaborative document, then I have no objection. I just won’t be writing any.

I’m not sure this is on topic for this thread (I apparently already misunderstood the topic once), but I’ve wanted a “paper” top-level post type for a while. This isn’t intended to solve your canonical question issue. It’s something different altogether.

These posts would be akin to research papers, but generally less formal and shorter. Several times I developed or discovered something interesting, and I would have liked to “publish” it somewhere. I don’t have time for, nor am I plugged into, the academic publishing scene. That’s way too heavy weight for what I’m thinking about anyway.

Such pages start with the paper as the main post, then allow for discussion below. The paper can be both up and down voted. That, together with the discussion, serve as the peer review process. Rep per vote should probably be higher for papers, since they are intended to be more work than an ordinary answer to a question. I wrote more on this over 7½ years ago at Would we benefit from a blog? - Electrical Engineering Meta Stack Exchange.


If I remember right, one of the zombies messed up the section formatting, and I then had to go fix it. I have no problem with spelling and minor grammar corrections, but beyond that, the author should own the post.

Even though the zombie edits were minor, the SE engine thinks they somehow add up to ¼ of the post. I did way more than ¾ of the work, particularly generating the content in the first place.

Yes, this!

Furthermore wanting several discussions (e.g. on aspects of the paper) – and evolving the paper to incorporate feedback.

So another scenario might be several short papers, from a longer piece – like an author getting peer reviews on successive chapters of their book.

Or a community being a study group, studying and discussing an already-published document.

1 Like

Where did I say that? That’s not true.

But we’re not building Wikipedia; we’re building a Q&A site that serves as a repository of knowledge. As part of building that Q&A site, we’ll end up with some content that is more “repository of knowledge” and less “Q&A”, as we’ve seen emerge on SE. SE doesn’t have great affordances for this; I’m all for making that better. But not at the expense of the core mission.

Most of the content will be Q&A. It’s why we’re here in the first place. We should therefore focus on that first. We shouldn’t close other doors in doing so, but let’s not get mired in attempts to build a better Wikipedia. Or Arxiv. Or Google Docs.

I think it’s because no one thinks to look there. It’s not very discoverable, edits don’t bump anything, and most tags don’t have good (or any) wikis so it’s not intuitive to look there. We can and should build canonical posts (whether they are tag wikis, blog posts, or some other kind of special post type) that are more visible.


There seem to be a few different ideas here, and this thread is long and meandering and hard to follow and maybe should be shut down – people with specific proposals should make them in narrower posts.

Q&A should have ownership like on SE. I thought that was clear to everybody. I hope it is now.

SE has canonical posts that are Q&A. “Canonical” isn’t a special status in the system; it’s just a post the community has agreed is canonical in some way. I see no reason to revoke ownership for such posts here, though authors are of course free to give up ownership and donate those posts to the community.

A suggestion that arose here is to have “canonical posts” that are not standard Q&A. These would be ownerless from the start, just like tag wikis are on SE. People can contribute or not. We haven’t discussed any processes for making these – can anybody just start one, or does there need to be some sort of community consensus, or what?

Relatedly, and it’s where I got some of my ideas for our canonical posts, somebody raised the precedent from academia of “review” articles, which are not original research but are compilations of and links to useful research elsewhere. This might be the closest idea I’ve seen to something akin to Wikipedia that fits within a Q&A framework.

We have also talked about blog posts, which might be the answer for your use case. Unlike canonical posts which are community-owned from the start, blog posts would be owned. Blog posts, like canonical posts, would allow comments/discussion but not answers.


That “expense” being only “spending time discussing future topics now instead of starting on the MVP”?

I doubt I need this discussed in any detail. All I can do, now, is hope that this might be a satisfactory solution if that time comes. Because as I said I’m worried (even doubtful) about your choosing a relational database as a back-end – even though relational is the SE way, I fear it’s a baked-in limitation which precludes/inhibits evolution of some features.

I hope so. When a site has even only thousands of extant topics and new people continue to ask novice or “frequently asked” questions, their questions are difficult to receive well.

1 Like

(This is a general comment, not aimed at you specifically. I’m just using your quote as a starting point.)

It sounded like some in the discussion wanted to build a completely different thing instead, but maybe I misunderstood – because a forum is a terrible way to handle focused questions, which is why we need a better Q&A platform, which is why all the “analysis paralysis” I’m perceiving bugs me so much. I know that some key people are busy and that’s part of the problem too, but I want to see us start building something. It’s been two and a half months! We have a good idea of what the MVP should be, granted with some parts still to be resolved. IMO nothing will move us forward faster than having running code we can use (and allow friendly alpha-testers to use).


That is exactly what I mean. Not an ordinary Question with Answers - in a sense the Title would be the “Question” and the body text the “one and only collaborative answer”.

That might fit better into the concept (which has also been discussed here 'n there) of a Blog type.
Like a Canonical post, it would be “one thing + comments” and not “Question + Answers + Comments”.

Unlike Canonical posts which would be (a) a fairly small group, (b) “always there”, (c) set up so that they become part of the available information when a user does a routine search - i.e., because hopefully these few posts would answer a large percentage of common questions without having to search through thousands of regular questions for a duplicate (which, as we know, users simply do not do), Blog entries would (a) vary in quantity significantly depending on the site (e.g., Worldbuilding had some via a linked site) and in any case the quantity would be expected to grow over time, (b) not be featured as a major element of the Q&A page since they are not designed to answer an incoming user’s typical questions and (c) be searchable (of course) but not, by default, included in a standard search of Questions.

Blogs would therefore be a good fit for:

  • Research Papers - e.g., new or innovative information about a specific topic. That could be technical, scientific or historical, depending on the community.
  • Creative Work - e.g., short stories on Worldbuilding or Writing that perhaps benefited from Q&A on the main community sites but which are not themselves either questions or research, but which are likely to be of interested to many people within those communities

What I would argue against allowing in Blogs, but which in the end would be determined by the Community and/or the Codidact Instance rules, is controversial topics such as politics (but historical analysis would be fine - as often enters (appropriately) into Answers on SE Politics), religion (again, depends on context - a Blog in Mi Yodeya that is a Dvar Torah/Drasha (Monica knows what I am talking about, the rest of you can Google it) would be fine but many other things would not.

I wonder how those % are determined. If they are based on “number of Edits” then that could easily cause inappropriate attribution. I think it should be based primarily on amount of text changed, with (arguably & configured per instance/community) extra weight towards (a) initial post and (b) declared Major vs. Minor edits and (c) a small bump per Edit.

I think anyone above a certain Trust Level should be able to start one. Not “anybody” - but not requiring moderator level either.


Your description sounds like what I want for “papers”. However, can we please call it something other than “blog”? That has some negative connotations, at least in some areas. Perhaps the name for such post types is site-configurable.

There is a very different feeling between “blog” and “paper”. The former sounds more like show-and-tell, “What I did on my summer vacation.”. For papers, I want something a bit more respectable, even if it’s just a name change.


How this type of post is represented in the UI to the community should be configurable. Different communities have different norms.


Actually I would say you should need to have enough tag reputation (or whatever our equivalent is) in at least one of the tags in order to create a canonical question. The requirements to edit one could be lower (because editing an existing post is generally easier than creating a meaningful one from scratch).