# Some weekend ponderings on communication habits
**URL:** https://meta.discourse.org/t/some-weekend-ponderings-on-communication-habits/39607
**Category:** Site feedback
**Created:** [2월 15, 2016, 3:34오후 UTC](https://meta.discourse.org/t/some-weekend-ponderings-on-communication-habits/39607 "2016-02-15T15:34:57Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@erlend\_sh](https://meta.discourse.org/u/erlend_sh)
#### Post date: [2월 15, 2016, 3:34오후 UTC](https://meta.discourse.org/t/some-weekend-ponderings-on-communication-habits/39607/1 "2016-02-15T15:34:57Z")
Continuing the discussion from [Starting a new message while browsing a topic](https://meta.discourse.org/t/starting-a-new-message-while-browsing-a-topic/39528/19):
Yesterday @Ossama shared some important feedback with us.
> [@Starting a new message while browsing a topic](https://meta.discourse.org/t/starting-a-new-message-while-browsing-a-topic/39528/19):
>
> The good thing i like here about the `@team` is how quick and responsive you guys are and the community to new ideas and suggestions. In 21 Hrs this small issue which is not a critical bug, but could improve user experience got resolved. So much respect for your efforts guys here. Claps hands
>
> The other point could be a complaint. Whenever report something here, I feel like I’ve done something wrong. I feel the feedback i provide is either unimportant or a burden. I used to browse and contribute to Discourse community everyday. Now only when a problem pops up. Who knows what next.
>
> We users/admin of Communities using Discourse, support you. We shall send you feedback and discuss even the tiniest details. That is what a community about, but from your side, try to make it friendly and welcoming. You can get much more from the community here, only if you show them the way.
>
> Thank you for your time.
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/](http://blog.erlend.sh/optimising-for-communication-efficiency-to-a-fault/)
(Ossama already replied to me in a separate exchange)
---
### Author:  [@joebuhlig](https://meta.discourse.org/u/joebuhlig)
#### Post date: [2월 15, 2016, 4:31오후 UTC](https://meta.discourse.org/t/some-weekend-ponderings-on-communication-habits/39607/2 "2016-02-15T16:31:45Z")
Looks like your URL changed:
[http://blog.erlend.sh/optimising-for-communication-efficiency-to-a-fault/](http://blog.erlend.sh/optimising-for-communication-efficiency-to-a-fault/)
---
### Author:  [@mcwumbly](https://meta.discourse.org/u/mcwumbly)
#### Post date: [2월 15, 2016, 4:41오후 UTC](https://meta.discourse.org/t/some-weekend-ponderings-on-communication-habits/39607/3 "2016-02-15T16:41:15Z")
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!
---
### Author:  [@riking](https://meta.discourse.org/u/riking)
#### Post date: [3월 12, 2016, 1:18오전 UTC](https://meta.discourse.org/t/some-weekend-ponderings-on-communication-habits/39607/4 "2016-03-12T01:18:38Z")
> [@mcwumbly](#):
>
> 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?
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.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [3월 12, 2016, 2:05오전 UTC](https://meta.discourse.org/t/some-weekend-ponderings-on-communication-habits/39607/5 "2016-03-12T02:05:14Z")
Or maybe that “terrible” idea could be a plugin on their site, and that is fine.
---
### Author:  [@mcwumbly](https://meta.discourse.org/u/mcwumbly)
#### Post date: [3월 12, 2016, 3:12오전 UTC](https://meta.discourse.org/t/some-weekend-ponderings-on-communication-habits/39607/6 "2016-03-12T03:12:34Z")
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.
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [3월 12, 2016, 5:40오전 UTC](https://meta.discourse.org/t/some-weekend-ponderings-on-communication-habits/39607/7 "2016-03-12T05:40:41Z")
How is that different than #releases category _and_ the existing tag we already use for that purpose #planned, _and_ the [dedicated topic](https://meta.discourse.org/t/upcoming-feature-to-do-list/25368) in the releases category for long term todos?
---
### Author:  [@mcwumbly](https://meta.discourse.org/u/mcwumbly)
#### Post date: [3월 12, 2016, 11:45오전 UTC](https://meta.discourse.org/t/some-weekend-ponderings-on-communication-habits/39607/8 "2016-03-12T11:45:12Z")
1. #releases we plan to build this feature for release n
2. [Upcoming feature to do list](https://meta.discourse.org/t/upcoming-feature-to-do-list/25368) we plan to do _these_, but not sure when
3. #planned we plan to do _this_ sometime
4. Finally #pr-welcome_we_ don’t plan to do this any time soon, but if _you_ want to, that’s totally cool.
I _swear_ the #pr-welcome did not exist when I wrote my earlier comments. With that, it looks like everything is covered.