An interesting discovery from early onboarding research was that a significant portion of new users signing up for GitHub had strong intention and desire to get involved in open source, but didn’t have an existing project to work on, nor did they know how to go about finding one.
As part of the early efforts to improve the onboarding experience and get more people on a path to becoming active in the open source community, we explored a range of ways to match the massive firehose of new users we were fortunate to have with projects where the maintainers were seeking contributions.
In our early prototypes, we imagined new users being directed to a "help wanted" area (which would ultimately live under the explore umbrella) at the end of the sign up process. Once there, they’d be able to indicate a topic, subject, or technology they might be interested in helping with, in a keyword driven way—e.g. "docs", "ruby", or "design" (note that this was before GitHub had the concept of "topics" at the repo level).
Based on the things they express interest (or from built-in suggestions pulled from trends in OSS activity), they’d be shown a list of issues from projects that were explicitly ready, waiting, and open for contributors. People could browse the list, iterate on the keywords if necessary, and ideally pick up an issue that looked interesting their first foray into contributing to open source.
Rather than building any dedicated functionality into the product to allow maintainers to opt-in, a decision was unfortunately made at a higher level to invest significantly less in this area of the product. Instead, I scaled back the scope of the project and decided to try and leverage an existing part of the product instead—Issue Labels!
When new projects are created, we pre-populate the issue tracker with a number of default labels for bugs, suggestions, questions, and so forth—so we went ahead added a new "help wanted" label to the default set, and flipped it on for people to begin using.
In addition to the label as a way for project maintainers to explicit opt-in, we imagined that a future version of the onboarding flow would eventually also look at other signals—such as a minimum star-count on the project, or considering the number of previous contributors, etc.—to improve the quality of the suggestions and results, and thus boost the chances of new users having a positive experience contributing to open source.
While the onboarding part of this project was unfortunately mothballed and de-emphasised for Other Reasons™, the help wanted label has nonetheless become heavily used, and it’s now easy to use GitHub’s search functionality to quickly literally millions of issues where maintainers want help. Pairing a search for the "help wanted" label with additional labels, yields large numbers of potentially relevant results.
I hope GitHub finds ways to connect the ever-increasing firehose of new sign-ups to the plethora of opportunities offered by the open-source community in the future.