Continuing the discussion from Starting a new message while browsing a topic:
Yesterday @Ossama shared some important feedback with us.
As I began to collect my thoughts, they eventually took the form of a blog post. So here’s my reply to the above:
http://blog.erlend.sh/optimising-for-communication-efficiency-to-a-fault/
(Ossama already replied to me in a separate exchange)
Looks like your URL changed:
Thanks for putting these thoughts together @erlend_sh.
If a Close Enough consensus can’t be reached within a reasonable span of time, we’d rather end a discussion promptly and revive it later
I think it’s important to emphasize that making decisions quickly and efficiently does not need to imply the end to a discussion.
[Within the team,] knowing nothing is personal, we cut to the chase. This is the norm in our day-to-day dialogue, and we’re better communicators for it.
We feel so at home on Meta that we tend to speak in the same manner there as we do when addressing one another. We probably shouldn’t do that.
That’s fine and completely understandable. As a small team, you have limited hours and resources to devote to productive work, and can only spend so much time discussing it. @codinghorror often exemplifies an important characteristic that I feel many Product Managers are lacking: encouraging people to really defend their ideas.
But the discussion shouldn’t be discouraged, in my opinion, even if the idea is opposed. As a team member, if it becomes a drain on your time, I think there are other ways you can excuse yourself from the discussion while making the current position of the team clear.
But as a community, our resources are not as limited.
Some of us do not have the skills to contribute directly to the project, so talking about our ideas is our form of contribution.
Seen that way, our breaths and hours are not the ones you need to worry about wasting.
And for those of us with the skills to contribute, it’s not always clear how best to do so.
Which features are “pr-welcome”? Which are “plugin-material”? Which ones go against what the team wants to see in the product vs. just don’t have the time and attention to spend on?
Finally, it’s worth mentioning that you guys have made great strides to improve this over the time I’ve been participating here.
And it’s clear that you are making a more concerted effort to do so since you joined the team. Keep up the good work!
I think that’s an area where the vagueness is at least somewhat intentional out of a desire to not drive people away even when they’re expressing terrible ideas.
Or maybe that “terrible” idea could be a plugin on their site, and that is fine.
Or maybe it’s a great idea that just isn’t fully fleshed out yet…
I am not advocating we add a terrible-idea tag. I think there is a level of maturity here where the community generally understands that there is a relatively high bar to clear in order for an idea to be welcome as pull request to the core project.
But when the idea does achieve that level of support, I think it’d be worth tagging it as such so the community can see which things are available to work on that are more likely to be accepted so long as the code quality meets the standards set by the core team.
How is that different than releases category and the existing tag we already use for that purpose planned, and the dedicated topic in the releases category for long term todos?
I swear the pr-welcome did not exist when I wrote my earlier comments. With that, it looks like everything is covered.