Write out guidelines for teams of people that want to get involved

[choldgraf]

In a recent tweet, @betatim brought up the case that a team of people is interested in using, or being involved with, the JupyterHub community/development/etc.

This can bring challenging dynamics when one group of people are co-located and high-bandwidth in their communication, while the rest of the community tends to speak asynchronously in github issues.

Can we provide any best-practices or guidelines in order to both be more inviting to teams of people that wish to be involved, as well as to ensure that we don't fall into any anti-patterns of team management or communication? I suspect there is not "a single answer" here, but it would be good to get some thoughts down to chew on...

[betatim]

I noticed in an issue that it looked like people had out-of-band communication or were part of a team/group. That combined with fairly bare GitHub profiles made it feel like this was a little group that arrived at a party together, chatted to each other all night and left again.

In this case I posted a link to the forum where people have said Hi.

With a bit of distance I think it isn't just limited to teams/groups. I like knowing who people are, what they do, etc. I find it helps understand why people do what they do. However it is also a source of stereotyping. And for yet another group of people it isn't possible/they don't want to reveal much about who they are.

If there was a "if first post" function in the issue/PR template so that we could post an additional sentence like "Say hi in the forum" if it was someone's first contribution that would be cool.

[sgibson91]

There's this GitHub Probot app that will post a customisable message on issues/PRs from new contributors and also congratulate them when their PR is merged: https://github.com/behaviorbot/welcome

Further thoughts: If it's something we end up trying and liking, I think we'll be able to configure it from the jupyterhub/.github repo so it's applied across the org. Tagging @GeorgianaElena to confirm.

[betatim]

(are there things for which there isn't a pro bot? :D )

[sgibson91]

Short of actually fixing the bug and adding the features, I don't think so 😄

[GeorgianaElena]

The welcome bot is really awesome ❤️

Further thoughts: If it's something we end up trying and liking, I think we'll be able to configure it from the jupyterhub/.github repo so it's applied across the org. Tagging @GeorgianaElena to confirm.

In theory yes, every configuration file we put in jupyterhub/.github repo should have an org wide effect. However, the bot we added recently (request-info bot) seems to only be working for the
.github repo (where it has the config, ref: jupyterhub/.github#5) but not for
jupyterhub for example (ref: jupyterhub/jupyterhub#3034).

My guess is that this has something to do with the version of the probot platform the apps are using (see this issue for more context and this section of the docs). An app that uses probot >= 9.3.0 seems to be ok with having its configuration in .github repo (like the support bot for example). The welcome bot also uses probot 9.3.0, so I think it will also work.

I opened behaviorbot/request-info#49 to bump the probot version for the request-info bot too.

[manics]

In general I'm against anything that increases the barrier to contributing. If a prerequisite of contributing is to make a forum post I think that would deter some people. Usually if I need to create a new account to report a bug I usually don't bother if it's only a one-off.

I do think we could improve the GitHub templates though. For instance for PRs we could add something like:

- Type of PR: Bugfix, new feature, documentation

- Describe this change.

# Optional questions: these are not required, but if you fill them out it will
be easier for maintainers to review your contribution.
- Is this part of a greater body of work? This may include other external
projects or motivations. If it's relevant please link to other issues, forum discussions,
external sites, etc.
- How can this change be tested?
- Are there any areas that reviewers should concentrate on or beware of?
- Is this a breaking change?

Are you aware of the Jupyter Discourse forum? If you're not and you'd like to
meet other contributors and users please say hello there.

[sgibson91]

If a prerequisite of contributing is to make a forum post I think that would deter some people.

So I felt that posting in the introduce yourself thread has always been a prerequisite (in a broad sense) - we've just never had anything that explicitly pointed new people there. It always came via someone like @betatim or @choldgraf saying something like "thanks for dropping by, it'd be great if you could tell us more about yourself over here"

[betatim]

I agree with Simon that we shouldn't make it a hard requirement. One reason being that it will put people off, another being that some people are "well known" but have never contributed to that particular repository before in which case they don't have to re-introduce themselves.

So maybe the thing to do is have a template that we can all use as a personal "nudge" as part of the "first contribution" process that says "Congratulations on your first contribution to Jupyter! You can find out more about the community in our forum (we also have a intro thread there). If you have any questions about contributing more...." or something like that. Then you can use it when you feel it is appropriate (and not when it isn't).