I appreciate the Discourse team being open towards new people’s suggestions there and elsewhere too.
I’ve seen this issue happen a lot on Meta over the years, but this prompted me to also offer my thoughts in general. It had also been frustrating to me to see it, but I didn’t really know how to raise the matter. So I will try write about it now:
Context
Sometimes around Meta, I’ve seen a trend of piling onto new people’s suggestions for Discourse features or changes. Instead of listening and understanding the experience of people newer to the software – whose insights can be helpful even to those of us who have used Discourse for over 10 years – sometimes people from the community pre-emptively knock down the idea.
Often this is done if an idea was rejected in the past by the Discourse team, or if a particular default setting was chosen over other configurations by the Discourse team and so on.
Even if that is the case, I would like to offer my thoughts on why we shouldn’t pre-emptively jump to dismiss ideas or complaints about the software, even if they have been discussed in the past before.
Discourse team has the final say. Much has changed. Things from back then may not apply now.
Firstly, we, as community members, are not the product managers for Discourse. If we jump to tell someone that their idea has been rejected in the past and why, this may not actually necessarily reflect the current decisions of the Discourse product team.
Sometimes even the Discourse team themselves can decide to work on a feature that was previously ruled out in the past. For a long time, chat was one such feature.
So there is never a 100% guarantee that past decisions will be the same as present decisions.
Even people on the Discourse team can have different views with each other regarding what should be a priority for Discourse.
For example, I often followed @erlend_sh’s blog and he discusses how he had a different view to the rest of the team about how chat should be in Discourse – bold emphasis is mine:
Most open source projects don’t have a dedicated forum, but the ones that do almost certainly also have a group chat. My last stint at Discourse was an attempt to merge the two modes together, with the introduction of Discourse Chat.
I’m really proud of that MVP (which has since graduated into core), but the direction I wanted to go from there was understandably incompatible with the Discourse project’s DNA as a traditional forum: I proposed we make chat the lead of our community experience. Community begins in the chat rooms, I thought. Discourse thought not, so we amicably parted ways.
Years later, my position remains unchanged. ‘Group chat’ and ‘forum’ ought to mean roughly the same thing. That’s in fact the direction we seem to be headed in, since Discord, ruler of our community lands, now supports a variety of threads & boards features that fit neatly into the forum paradigm.
So it is not really for us to prematurely decide what should not go into Discourse, since that can also change over time.
Those of us in the earlier days of Discourse will remember when CDCK was less than 10 people and the product management was often very much driven by Discourse cofounders. But nowadays CDCK is 100 people strong and CDCK has an entire product team!
Discourse itself has a much, much larger userbase, whose needs and usage for the software have grown beyond the initial earlier adopters of Discourse. More broadly, the landscape of social platforms has changed (momentum has moved from Facebook to Discord and more, and so on), and people’s general expectations have changed.
Since the team is much bigger than in the early days of Discourse, they have more capacity to work on other features that may have been much lower priority during the early days of product development, in yesteryear.
So how they review feature requests now will probably be quite different from early on. The product team will have their own process for decision-making and deciding what ultimately gets worked on and when.
More data points is better
Secondly, it’s usually helpful for the Discourse team to hear more data points rather than less.
There was something loosely popularized on Meta as a Rule of 3 (minimum of 3 people make a complaint about something before that feature request is considered). Even with that, you have to let people share their experiences and complain, in order to listen to 3 different people find a problem with something.
Aside from that, another popularized idea was Complaint Driven Development. And with this, you do also have to listen to people’s opinions:
The only thing I’ve ever seen work is getting down deep and dirty in the trenches with your users, communicating with them and cultivating relationships .
After re-reading that, I also really strongly submit that the original premise behind that “rule of 3” is actually NOT that your opinion doesn’t matter if no one else is complaining about it.
The heart of it was that (especially if you are a low-resource team) finding the things that people complain about the most is an efficient way of finding the problems that bug your users the most – so you can fix those first.
As Steve Krug says in Don’t Make Me Think:
You’ll always find more problems than you have the resources to fix, so it’s very important that you focus on fixing the most serious ones first. And three users are very likely to encounter many of the most significant problems related to the tasks that you’re testing.
So just because not a lot of other people have complained about the same thing, doesn’t mean that it doesn’t matter. More data points is still helpful for the Discourse team when considering what are the current major/minor pain points for users.
It’s possible to appreciate people’s feedback, even if you won’t implement it
Thirdly, it’s still possible to say thanks for people’s feedback, even if you can’t implement all their suggestions or if you have decided not to.
I got more practiced at handling feedback in this way, after I studied game design where giving and receiving feedback was a huge part of the process. On iterations of every game level, design document, or anything, we would give feedback on at least 3 other people’s work and receive feedback from at least 3 others. I used to try and give feedback for 4 or 5 people to help make up for other people being absent / submitting their assignments late, etc.
Often people’s feedback is very insightful and helpful, but there are more than 10 important points and right now you only have time to implement 1-3 things.
This was also the case when I worked professionally as a software engineer often interacting with the community, as part of a small startup. There may be 10+ important bug reports, but in the next update, you have time to fix 1-3 of them.
In any case, I still feel very much quite obliged to thank people for their observations, thank them for sharing their thoughts, thank them for making the time to write the steps to reproduce a bug and apologise for the inconvenience.
Most of the time, users/players don’t say anything unless they’re really bothered. So pretty much most written feedback/feature requests/bug reports are each coming from someone who took the time to share their thoughts on something – things that many others may have thought about but didn’t yet identify or say anything about, things that you probably missed, and so on.
So even if you can’t implement everything that everyone says — which might even be 90% of the time — it doesn’t mean you have to jump on all that feedback and drive it down. The feedback is still important, even if you don’t have the resources to act on it right now or even if you have decided not to act on it.
Anyway, so that’s why I think it’s worth it, for us as community members, to let other newer people share their thoughts and not immediately jump on to dismiss people’s suggestions for Discourse. This is because Discourse team’s position on features may change over time, and the feedback is still helpful as data points to the Discourse team, even if they may not implement it right now.