GitHub Discussions: the right tool to communicate with new code contributors?

Community Community Feedback
1

One of the things I would like to improve before I leave is the process for onboarding new contributors. One part of this is when/how to give greater accesses to people (to tag issues and assign people, to review / merge PRs, to get access to the reported security vulnerabilities…): that should be clarified in our governance model. But beyond granting permissions, another thing we don't do very well is reaching out to new contributors to check in with them. I would be really interested to know, for instance:

  • what motivates them to contribute to OpenRefine?
  • if they have encountered any hurdles in their contribution process (be it a difficulty to set up a development environment, a comment that reads unfriendly to them, difficulty finding appropriate issues to work on, lack of permissions to carry out a particular task…)
  • what their plans are, if they plan to continue contributing in the future

This is something that would be worth doing regularly, as situations evolve over time.

What's making it difficult for me to do this outreach work is:

  1. keeping track of who to reach out to. When I see a PR from a vaguely familiar username, it's not so easy to remember if this person arrived in the project last week, or if it's been a few months already. It requires initiative to do this check-in and I always have other things to do.
  2. obviously, doing the outreach itself is time consuming. I wouldn't want to do it with a bot that sends a predefined message based on some criterion as it would be too impersonal. So that means taking a bit of time to write a message (which doesn't need to be super personalized) or potentially even getting on a call.
  3. and crucially: the lack of a communication channel to do this check-in! Because a lot of our code contributors are only identifiable as a GitHub account, with no other contact information. They don't participate on the forum (or at least I'm not able to match the usernames on both sides).

For instance, in the case of elebitzero, it's only after about 100 PRs that I finally took the time to do this outreach. Way too late! Because I couldn't find any contact details, I went for creating a GitHub issue in a dedicated repository to reach out. Obviously that's quite weird and it's also outside of the project's communication channels.

I have been reluctant to use GitHub Discussions in the past (sorry @thadguidry !), because it felt like it duplicated the forum and increased our vendor lock-in with GitHub (I am not aware of other forges offering something comparable). But I recently realized that it would actually be pretty useful to start conversations like that with code contributors.

What do you think? Would it make sense to try it out? Can we think of sensible criteria to determine if a discussion should happen on the forum or on GitHub?

Edit: to get a sense of how those discussions are organized, you can have a look at this very active instance: community · Discussions · GitHub

1 Like
2

Turning Discussions into Issues (or just easily linking them) or Issues back to Discussions... is so useful as well.

3

It sounds like what's driving this is the lack of non-Github means of communication because, other than that, Github Discussions seem like just another web-based forum/bulletin board which is in direct competition with our current web forum. FWIW, the last time the developers were polled, the vote was 2-0 for returning to the dev mailing list as a means of communication (which, of course, is too low a turnout to make a change on).

I would flip the whole premise around to make it more scalable. It's not the development team's job to hunt down new contributors and have them explain themselves. The dev team should make new contributors feel welcome and invite them, IF they want to, to introduce themselves. Many communities encourage new members to introduce themselves -- and software internship programs like GSoC often require it (on a project, not program, basis). If we don't have an explicit invitation to provide an introduction in our onboarding/dev setup instructions, we should add that.

I think it's important to remember that different people have different styles of interaction. Not everyone is all "let's hop on a call," and many software developers probably even less so. Language issues, time zones, living situation, network bandwidth, and a variety of other factors are in play in addition to just personal interaction style.

The things which make it easier for me to contribute to a project are:

  • quick development environment setup
  • clear contribution guidelines
  • quick PR reviews with concrete suggestions as to what needs to be changed
  • optional, but always appreciated, thanks when my fix is incorporated

We should strive to make onboarding as easy and welcoming as possible and to retain as many new contributors for as long as possible, but I think it's also important to recognize that many, many are drive-by contributors of one sort or another -- from the random user who wants to contribute just one bug fix to the uni students who were assigned "create an open source PR" as a class assignment.

Which was a very long winded way of saying that I don't think the communication channel is the important part of the conversation...

Tom

4

Curious that I didn't participate in this poll. Next time we are polling developers let me know, because I see myself as one and would rather not migrate back to Google Groups.
For the issue at hand, having a Google Group instead of Discourse would not help either, for people who are only reachable on GitHub anyway.

I disagree. I think this is indeed the social norm in open source, but I don't think it's healthy. To me, this is the root cause of a lot of issues. With this way of working, tons of maintainers remain in a Benevolent Dictator For Life role because they can only get replaced by someone who is bold enough to take the initiative to ask for more responsibilities on their own. No wonder why people burn out!

This attitude might be the right one for a project where you'll always have enough devs wanting to take responsibilities, because of the prestige or technical challenge - say Airflow or Vue.js. I don't think this can work for OpenRefine.

That's precisely why I think we should get developers to talk on the platform they already are active on, with a communication medium that's comfortable for them.

What sort of team are we hoping to build, if developers stay on GitHub and are not meant to communicate there? Is the understanding that developers are just there to push code, with the minimal amount of words around their commits to make other devs swallow the pill? I think actual communication is a prerequisite for team work and avoiding conflicts.

That's exactly what I would like to identify early on - so I can focus my efforts on people who actually have a chance of meaningfully integrating. Of course I have gut feelings about contributors pretty quickly, but I know making assumptions with so little information is dangerous. If I don't have an occasion to actually ask people what their motivations are, all I can do is rely on stereotypes.
For instance, I then sort most Indian-looking usernames into the category "uni student not here for the long run, don't spend too much effort onboarding them", which is actively racist. No wonder why open source has a diversity problem…

I have to say - I don't expect you to do this outreach work, because I have learned that you have other priorities and I am not going to change that. But I'm hoping this is something that others could do (@thadguidry, @Martin ?), also after I leave. Maybe that would be sufficient to encourage contributors who have a real interest in the project to stick around for longer and gradually get more responsibilities.

Perhaps it's worth asking the question in reverse. If you are expecting that people get commit access (or permission to tag issues, for instance) after taking the initiative to request it, when was the last time you granted such an access in OpenRefine or any other open source project where you are involved?

5

Well, OK, so a few points and opinions from me:

  1. @antonin_d Yes, I do plan to continue outreach of contributors. I do this on other open source software that I sponsor, contribute to, and help their communities maintain - this is public in my GitHub profile and contribution insights.
  2. Just as in the beginning of life of OpenRefine, I simply want OpenRefine to continue to add features that users agree they need, once consensus on designs with developers are solid enough for development. That's always been the priority for me anyways, getting feedback from user groups, meetups, training sessions, etc. just as I always did in pre-retirement. Those EPIC issues I've made in the past? Those come from direct brainstorming ideas with other teams and even designers in other software, where in meetings we'd research how other software typically solve some of those problems. GitHub Discussions (or the Design category in the forum) will continue to be used by me for feedback and high level design (HLD) iteration with users - leaving GitHub Issues where final low level design (LLD) can be reviewed and hopefully picked up by developers to work on.
  3. @tfmorris I feel that developers do indeed embrace GitHub. And it's where developers are typically most comfortable. So, in my opinion, it makes sense to begin using GitHub Discussions especially with that group and specific skillset of developer.
  4. For users and designers (but not exclusively I'd say - they can also provide input using GitHub Discussions), we have the Discourse forum which is quite wonderful for them from what I've seen, even in just the last 2 months (for instance, design screenshots and image pasting/uploads are not as wonky and it does work similarly to an email client for these groups of folks - so bonus), and we now see MUCH more interaction from users on our Discourse forum then we ever did on the mailing list for users.
6

I just wanted to go back on the "drive-by contributors" aspect because I'm not happy with my reply.
I think classifying people as drive-by contributors is a perfect method to ensure they will indeed not stick around. It's a self-fulfilling prophecy.

I am a drive-by contributor. I didn't event want to contribute anything to OpenRefine itself at all, I just wanted to have a reconciliation service for Wikidata. I had no intention of making any sort of meaningful contribution to this project when I approached it. I just stayed because @thadguidry and @Martin (and others!) very proactively welcomed me in the project and encouraged me to take up more responsibilities.

It's hard to know what would have happened if my point of contact to the project had been a BDFL only responding to issues and PRs, just expecting contributors to apply for more rights whenever they feel they have the skills. I think I wouldn't have stuck around.

7

I'm not sure why you asked for feedback if you've already made up your mind what you're going to do.

tfmorris:

FWIW, the last time the developers were polled, the vote was 2-0 for returning to the dev mailing list as a means of communication (which, of course, is too low a turnout to make a change on).

Curious that I didn't participate in this poll. Next time we are polling developers let me know, because I see myself as one and would rather not migrate back to Google Groups.

I misspoke. The final tally was 2-1, including your vote, with many abstentions. Apparently that didn't constitute a "clear majority."
https://forum.openrefine.org/t/making-the-forum-more-welcoming-for-users/1017/18

How do we get more of the developer community to participate in discussions?

Tom

8

Look, at this stage the choice of discussion platform is completely anecdotal to me.

What I find really sad here is that I get the impression that you don't even seem to value the onboarding work others do. You don't like doing that yourself: okay. But discouraging the rest of us to get in touch with new contributors… really?

I mean, I am definitely not a community manager - I clearly don't know how to do this sort of work well. I try various things and most of them fail. But it's frankly depressing to see so little appreciation on your side, or even active resistance, for instance by trying to derail the BarCamp or undermine its legitimacy in multiple ways. It's exhausting.

9

From Tom's messages, I don't see him discouraging active outreach to new contributors. I think we all agree that the core question is how to get more developer engagement in discussions and recurring contributions.

Last year, I interviewed six developers on their experience, the summary of my conversation is here User Interviews Results Part 3: Cultivating a Thriving Developer and Trainer Community. From those conversation they suggested:

  • better visibility on the long-term roadmap
  • continuing to provide individual support when they asked for help on the mailing list and monthly developers' calls.
  • The communication can be harsh and off-putting when there is disagreement (like in the last few messages in this thread). They also believe that to contribute to the project in the long term, one needs to be persistent and tenacious.

From my experience, contributors with less experience with open-source tacit rules need nudges and encouragement to take responsibility. We already have clear guidelines on how one can contribute, what we are missing is continuous outreach and engagement with new contributors. This task usually requires a community manager, which we currently lack, and it isn’t my personal strength. However, I believe that part of it can be automated.

At one point, NumPy posted a welcome message after merging the first pull request from a new contributor. We can also send a similar message when assigning an issue to a contributor for the first time or when they open their pull request. Our welcome message can encourage the contributors to read the relevant documentation and introduce themselves on the forum.

I see no issue with automating this process using a GitHub action (see GitHub - behaviorbot/welcome: A probot app that welcome new users for an example). We can implement it when:

  • A contributor opens their first PR with an invitation to introduce themself on the forum and read contribution guideline
  • We merge their first PR with a congratulation an invitation to look at issues titled "help-wanted" or "Difficulty: Up for grabs."

After a few PRs are merged, contributors need to know how they can gain more responsibility and rights in the repo. This process is currently not transparent and is part of a separate governance discussion.

10

I applaud and encourage ALL efforts to attract, retain, and support contributors of ALL flavors whether they be inbound or outbound focused.

I think improving the inbound side of things, such as Martin's automation suggestions, tends to be more scalable and sustainable but I'm not at all opposed to people who have extra time & energy doing personal outreach.

Tom