How do we decide what goes into each release of Discourse?

Releases
1

How do we decide what goes into each release of Discourse?

Generally speaking, this is the model:

That is amortized across:

  1. How many different Discourse instances are complaining / asking about this?

  2. How many of these Discourse instances are paying customers, either ours or someone else’s?

  3. What is the community composition of those Discourse instances? Large, small, specialist, generalist, cranky (we dislike change), progressive (we love change)? How active is the instance? Is it a massive bustling city with big city problems, or a small town?

  4. How strongly does the team feel this would help many (or all) other Discourse instances?

  5. How in tune with the “Discourse philosophy” is this feature? Example: downvoting / next page buttons, very much not in tune; optional anonymous posting / export personal posts, in tune.

  6. What discussion has there been about this, if any, here on meta.discourse?

  7. How strongly does the Discourse team personally like/want/need this feature?

This is ranked from strongest (#1) to weakest (#7). The more we see the higher numbers the more that particular thing is prioritized. Discussion is weighted, but only to the extent that the people discussing have regular visibility into multiple Discourse instances with different audiences, 5 to 10 of them ideally, but even 2 or 3 is good.

We always encourage discussion of features and direction for current and future versions of Discourse, within the following guidelines:

  • A little discussion is great. However, we try to avoid having too much discussion in favor of Just Trying Something.

  • In the event that there isn’t any kind of real consensus in the discussion, or significant disagreement among a minority in the discussion, the Discourse team reserves the right to make arbitrarily binding decisions and move forward.

    In the case where it’s kind of a UI or design thing where there’s no way to have a solution that can satisfy everyone, our philosophy is:

    • Do the simple / clean thing whenever possible

    • Gather basic feedback

    • Try it for a while – live with it

    • Adjust it over time based on feedback from living with it

  • We reserve the right to be wrong about any of those binding decisions and revisit them at some later date.

  • We don’t like exploding Discourse with zillions of confusing settings, we’d rather have sensible out-of-box defaults that work for 90% of communities and can be tweaked. But in some (rare) cases the needs are so divergent that a new setting must be added. This should be a method of last resort.

  • Discourse is open source software! Try to be the change you wish to see, via a plugin or pull request.

38 Likes
3
6 Likes
4

Comment is about Postgres but could easily be applied to Discourse as well:

Actually as great as Postgres is and as generally approachable the community is - my experience was the same a few times and I read it on the mailing list happening to others:

Someone comes along with a patch or idea. Bunch of big Postgres people come knock it and it dies right there.

Happened to me when I suggested a more multi-tenant approach back around 2010 and today we have Citus. I was told that (paraphrased) no users were asking for that sort of thing.

I see it kind of happening with the Foreign Key Array patch that the author asked for help to rebase and no one bothered to reply.

Someone suggested replacing the Postmaster with a threaded approach so it could scale better (and showed benchmarks of their implementation handling more connections). Community response was there were already 3rd party connection pools that do the job. An outsider looking in considers this nuts - most people would not run additional components if they did not need to!

Another example: NAMEDATALEN restricts every identifier to 63 bytes - a limit that causes frequent issues (more so now that we have partitioning) and also a problem for multi-lingual table names. It’s been proposed to increase this limit a few times. Every time the answer has been: abbreviate your table names or recompile your own version of Postgres.

Could name a few other examples too I’ve noticed over the years and just sighed at. I don’t expect every idea to be accepted or even welcomed - but there is that sense of bias against change.

Response on HN:

While this can and does suck when it happens to you, this is exactly what it takes to keep products focused so they don’t die death by a thousand cuts (or feature requests). For every awesome feature embarked upon, there’s an opportunity cost of bug fixes, stability updates, tech debt reductions, and other inglorious but necessary work. Aggressively de-scoping is the difficult but necessary work of keeping a product alive in a competitive marketplace. And yes, it’s a marketplace even if the product is open source.

18 Likes