Repository navigation
Managing Signal to Noise #15
Description
Discussions about the module implementation can be quite contentious and lead to very long threads that mix both implementation and philosophy. Personally I have found the amount of content churning out to be quite overwhelming in the past, and already see this beginning to happen in this repo.
How can we focus the conversation so as to not drive away potential collaborators and minimize the investment of time necessary to get started.
One suggestion to kick this off. Moving general discussion about concepts to a chat room and keep the issue tracker focused on implementation discussion? The line on this could be quite blurry, which is a concern
To be explicit, I in no way want to discourage people from having an open discourse, I just want to figure out the balance that can keep people engaged and avoid the pattern of "whoever talks the longest wins"
Activity
bmeck commentedon Feb 6, 2018
We should use something that isn't IRC that actually keeps a history.
benjamn commentedon Feb 6, 2018
https://gitter.im works great for real-time chats connected to GitHub repositories, in my experience.
benjamn commentedon Feb 6, 2018
@yjoyos Thanks for the idea, but I'm not sure I have time to debate with folks who are not members of this working group. You just signed up for GitHub, and have no history whatsoever. How do we know you're not just astroturfing for this Zulip product?
@MylesBorins Should we lock this repo down to the invited members? Signal vs. noise, and all…
benjamn commentedon Feb 6, 2018
No need to be sorry. We're trying to get a specific kind of work done, and this issue is all about the risks of losing focus. I'm glad to know that Zulip exists.
MylesBorins commentedon Feb 7, 2018
weswigham commentedon Feb 7, 2018
discourse isn't really a chat service, is it? More of a forum, very similar in functionality to github issues. If we're just looking to separate actual issues or tasks with discussion, we could use github team discussions, since it's already integrated into the team.
devsnek commentedon Feb 7, 2018
we really need a more instant sort of chat to prevent against the enormous books of text we all tend to write on more forum based solutions like github
TimothyGu commentedon Feb 7, 2018
I think @MylesBorins might have meant Discord?
Discord or Slack for me. Slack has a slight advantage in its threads support. I’ve used Gitter a long time ago and wasn’t a great fan but am willing to try it again.
TimothyGu commentedon Feb 7, 2018
Or IRC, which has been very effective in my discussions with @devsnek and @bmeck.
MylesBorins commentedon Feb 7, 2018
I did indeed mean Discord 🤦♂️
@Fishrock123 was mentioning the ability to do video chat on discord, and potentially being able to do the youtube streaming video from it, or perhaps trying another service like twitch. As this group is much larger than the average working group it may be worth exploring a new stack for doing live streamed meetings
/cc @Amorelandra has some advice on this
devsnek commentedon Feb 7, 2018
@MylesBorins video chat in discord is group dm only and limited to 10 people, but its a definite +1 for text chat from me, having full history is a must have for our discussions, plus we can get multiple channels for various topics.
MylesBorins commentedon Feb 7, 2018
targos commentedon Feb 7, 2018
I would very much like to try Discord! I don't think video chat is a must have.
ljharb commentedon Feb 7, 2018
I strongly dislike Discord's UI; I'd prefer IRC and to have a logging bot in the channel for those without a bouncer.
evanplaice commentedon Feb 7, 2018
It may be useful if we could establish a format for consensus issues
Title: Consensus: [issue]
Body
Status: blocking | confirmedReferencessection that points to other issues related to the consensusComments
Consensus: agree | disagree | abstainIf this sounds beneficial, I can quickly make up a PR with a template.
MylesBorins commentedon Feb 7, 2018
@evanplaice I think it is a good idea, but I'm not entirely sure we need that level of process.
One thing to keep in mind about node's consensus model is that while we require explicit sign off on the implementation we don't require people to explicitly agree, rather we give people an opportunity to dissent. I'd imagine that most times where we are trying to reach explicit consensus on something moving forward would happen in a PR.
MylesBorins commentedon Feb 15, 2018
I feel like we had a good discussion about this today. Closing for now. Feel free to reopen or start a new conversation on this topic.