Hey all - at the team meeting we had a lot of useful discussion about communications channels in the JupyterHub project. I don’t believe that we had any specific outcome from this, so I wanted to take a stab at a proposal for our communications strategy on the hub side of things to hear what the community thinks.
- Use GitHub repositories for repository-specific questions related to the codebase. Things that should ultimately result in a change to that repository.
- Use Gitter for live conversation that don’t need to be archived/read by anyone not present in the moment
- Use Discourse for general “how do I?” questions, generic suggestions, ideas, etc. If in doubt post here.
- Use Twitter/Blog/Discourse to highlight new activity and updates in the community
What’s the goal
The goal for this proposal is to make it easier to know what kind of information goes in which channel, to help improve the signal to noise of our repository issues, and to use the “right tool for the job” when it comes to communication. It is also a way to signal to the community how they can best-engage with the project.
What process exists around these channels?
GitHub is a platform designed around making changes to code repositories. Issues have a very “ask the core dev team” feel about them, and the notion of “closing” issues suggests that in general they should be actionable (or at least of finite time). This makes GitHub awkward if you want more general conversations and sharing about the use of technology, or if you want to encourage more user-to-user interactions. As such, I propose that we focus GitHub issue conversations around questions/conversations that will lead to changes in the code repository. If people ask other kinds of questions there (“e.g., I’m trying to deploy XXX, can somebody help me?”) then we post a friendly suggestion that they open a thread on the discourse page and close the issue. The goal is that GitHub issues are focused on actionable and specific items for a repository.
Gitter is a great medium for fluid conversation, though it isn’t easily searchable/archivable/discoverable and so we’d like to keep content-full discussion in either GitHub or Discourse. Once conversations on Gitter start to become non-trivial (e.g. will take some thinking to resolve), we recommend that people open a thread on Discourse, or that they open an issue on a relevant GitHub repository if it’s directly related to a particular repository. The goal is that Gitter has unstructured and fluid conversation that leads to more in-depth conversations in the proper Discourse/GitHub channel.
Discourse is a structured and community-focused platform for discussion. It is both discoverable and searchable, and can serve as a resource for past and present conversations around JupyterHub. We’d like all conversations that don’t directly pertain to the underlying codebase of a repository to happen in the Discourse page. This includes “how do I deploy?” questions, “best practices” questions, general discussions about enhancements, etc. The goal is that Discourse conversations result in actionable and specific issues in the repository.
The Blog / Twitter are both great ways to make a one-way connection with the outside community. They can amplify our voice, but at the cost of making it harder to have in-depth two-way communication. We use the blog and twitter for large announcements, and recommend that people go to the Discourse to engage in discussion around those announcements. As a general rule, anything that we broadcast widely via these mediums will also have a corresponding place to talk about it on the Discourse.
What should we do to accomplish this?
I think that the main changes we’d need to make for a strategy like this would be the following things:
- Write up these communications guidelines somewhere in the team compass site, and include a section that links to this page in our repositories. It’d be a brief “how to participate in XXX discussions” kind of thing.
- Try adjusting our issues/channels/etc practices so that we encourage people to move conversation to the right channels for their question, and get a little bit more assertive about closing issues etc that aren’t actionable in the repository.
The main drawback that I can envision is that we come across as confrontational if we asked people to move conversations elsewhere. We run the risk of seeming dismissive if, for example, we close issues that aren’t in-scope in a repository. We should be thoughtful about how we communicate these things to community members so that we don’t rub people the wrong way.
What do folks think about this? I’m happy to iterate on it with people in the discussion below. Would love to hear input from both “core team” members as well as the wider community!