How to handle a pattern of GitHub volunteers wanting to work on an issue then disappearing

Question

Since I registered my project on Up For Grabs, I get a lot of novice volunteers, which is great as I like both the ideas of 1) improving the app 2) introducing novices to open source collaboration.

But I have a management+social+technical problem, illustrated by this example today:

As you can see, one after the other, 3 volunteers have taken the issue under their responsibility then become silent, with a month's interval between each.

• They are volunteer novices, so the problem is not them. I fully expect that they might give up, and hold no grudge against them.
• On the technical side, GitHub is not helping, as I can not assign an issue to someone who is not a member of the project. And I don't think making them a GitHub project member is a good idea at this step (or is it?). I created the "assigned" label to work around this problem, but it is not optimal as it does not say to whom the issue is assigned. I want to continue to use GitHub for issue tracking, though, as it has become a de facto standard.
• I hesitate between spending more time spoonfeeding newcomers, or spending less time so that I dedicate my time to other aspects of the project.
• Before we had a policy of "First pull request wins", that lead to frustration as we had some real cases of novices posting nearly the same pull request at the same time for something non-trivial that they that obviously had dedicated a lot of time to. Not a pleasant situation, and a very traumatic first experience for some of them, which is something I really want to avoid.

How can I improve my handling of the situation? Be it via behavior, project guidelines, technical solutions, or anything else.

Answer 1

On the technical side, Github is not helping, as I can not assign an issue to someone who is not a member of the project. And I don't think making them a Github project member is a good idea at this step (or is it?). I created the "assigned" label to work around this problem, but it is not optimal as it does not say to whom the issue is assigned. I want to continue to use Github for issue tracking, though, as it has become a de facto standard.

While agreeing completely with Philippe's answer, I will try to answer to the technical sub-question here: indeed GitHub does not make it easy to assign issues to new contributors but there are workarounds.

If your project is part of an organization (and only in this case), you may create a team in your organization (call it "External" or "New contributors" for instance) and give it "Read access" to your repository (see this screenshot of the repository settings). When your repository is already public, giving read access basically amounts to giving no privileges, but it will allow you assigning issues to people in the team (they have first to accept the invitation though).

If you use this to assign issues to newcomers, you should have a clear rule in your contributing guidelines that not communicating for a week (or any other predefined period) amounts to losing the issue.

---

The rest of this answer is drifting away from the original question but it might still be of interest to you: you can use "Write access" as the next level of privileges for people who have already contributed usefully a few times. If, at the same time, you protect your branches and activate the "Review requested" feature and restrict merging to a subset of contributors (possibly only administrators), then "Write access" will mean privilege to label / milestone / close / reopen / assign issues (and edit / delete comments), to mark a pull request as approved, but not to commit anything directly to a branch nor to merge pull requests. Then the next level of privilege can be permission to merge approved pull requests (leaving pushing on branches directly or merging unapproved pull requests to repo admins only).

Answer 2

Congratulations! The problem you face is a common one for a popular open source project.

IMHO, beginners should above all learn to communicate!

So you could explain in your CONTRIBUTING file what a simple process would be when someone wants to work on a ticket.

When there are multiple aspiring contributors I make sure that each is aware that others may be working on this too and that they should coordinate on the ticket to avoid duplicate work if they feel like it...

Or agree or understand that they might submit competing patches if they want or are ignoring the discussion.

IMHO, as a rule if someone is committed to provide a patch and does not provide anything within a few days or a week, and does not discuss nor communicate on progress, then this can and should be ignored by others.

Also, I cannot arbitrate anything seriously until there is actual code posted: so coordination though the discussions is as good as it gets... and there is no real alternative that to let the best PR win (and IMHO not the first PR).

GitHub and most similar issue trackers would be weak to provide proper tooling to help you with this...

This is a complicated human coordination problem where appropriate tooling would be hard to get right beside a proper discussion.