How does the Discourse project work?

I would not say “Jeff’s decision is final” is the model. 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 (I hate change), friendly (we love change)?

  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. How strongly does the Discourse team personally like/want/need this feature?

This is ranked from strongest (#1) to weakest (#5+), so the more we see the higher numbers the more that particular thing is prioritized. This assumes 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.

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, my philosophy is:

  1. Do the simple / clean thing whenever possible
  2. Gather basic feedback
  3. Try it for a while (live with it)
  4. Adjust it over time based on feedback from living with it

After a point, I do think you want to avoid having too much discussion and Just Try Something, and I’m fine with taking the role of the person who decides to arbitrarily move forward with a contentious decision. But this is limited to stuff where there isn’t any kind of real consensus, or significant disagreement among the minority.

16 Likes