I recently learned of this website, https://www.firsttimersonly.com/ , which has the mantra, “Friendly Open Source projects should reserve specific issues for newbies.” This is an aggregation of resources for motivated individuals that want to contribute to open source but don’t know how to get started. It includes a few resources, such as an example project that teaches newbies the basic workflow of using git and github to submit their first pull request.
From that site, I found https://goodfirstissues.com/ and https://goodfirstissue.dev/ , which aggregate issues on GH repositories that are tagged with ‘Good First Issue’. I want to start a discussion about this idea and whether we could find some opportunities here for new contributors.
First, does anyone have prior experience with an open source project which invited new contributors in this way, and was it a success? What did you learn from it, would you like to see it done here, and what would you do differently about it?
Secondly, what kind of commitment would it take for us to find some issues that are a good fit within the Foreman community? From the top of my head:
Good candidate issues need to be easy enough for a newcomer to tackle without a large amount of prior experience. That could be challenging with Foreman given the inherent complexity in what this software does, but also the large scope and number of projects/repositories within this community means that there could be a high volume of issues to choose from.
Good candidate issues also need to be somewhat low priority, in order to allow time for newcomer to come along and pick it up. So even a simple one-liner fix may not be appropriate if the fix is important enough that it needs to happen right away.
There needs to be a willingness of the maintainers of that repository to gently guide the contributor through the process, which might include coaching them a bit on the git workflow, when and how to amend and force push, conforming to the style guide of the project, proper formatting of the commit message and attaching a Redmine where appropriate.
Speaking of Redmine, it’s usually the single source of truth for issues, while the issue tracker on GH is less commonly used here. In order to make it easy for newbies to find issues using one of the above trackers, that could require a commitment from one or more community members to search Redmine for issues which are difficulty = trivial or easy and priority = low, then create a GH issue in the appropriate project and add the ‘Good First Issue’ tag.
Basically what I want to gauge is whether this is feasible for us to do, is anybody interested in doing it, and do we reasonably expect that some newcomer will get value from the experience?
We could definitely do better in terms of welcoming first time contributors to the community. However, as you mentioned, Foreman is quite a complex project to get set up, unlike most libraries which are more common in such lists.
We have a couple of saved searches on redmine: Easy and Trivial Issues - Foreman - which searches across all projects Good first issues - Foreman core - Foreman - which is specific for foreman core
Granted, they are a bit hidden on the sidebar and aren’t very well publicized, so we could try to link them from a more prominent location.
There is a problem though with these lists and that is it’s difficult to maintain - unfortunately, most developers don’t set the difficulty field, so there may be many other easy issues hidden away, and we do not do a good job of grooming our backlog on redmine, so many of the issues there may already be out of date or irrelevant. Even issues that may seem trivial to a developer familiar with the project, might be very difficult to someone who is a first time contributor and has no domain knowledge.
There is a reason we use redmine and not GH issues for most projects - and that is it allows us much more capabilities that are very difficult with GH, for example, connecting multiple issues and subtasks, setting release targets and actual fixed in versions, assigning issues to people who aren’t committers and much better integration with all of our release automation. I would not want to duplicate issues to GH and make it difficult to understand what is the source of truth, nor add more complex tooling to synchronize between the two.
GH issues are great for a small project that is contained in a single repo and has little integrations with external tools. I do not think it is a good fit for our project, and tbh I’d be happy if the repos that still use gh issues also migrated to redmine.
I am afraid that Foreman is not the type of FOSS project I would like to start with myself. It’s a complex system that is difficult even to plan for deployment. However I get the point that if we are not prepared and don’t advertise the possibility to do first-time contributions, then we are unlikely to get people involved.
A good starting point would be some introduction section to first-timers on our contributions page which would basically say: “Contact us to get you issues you would like to start with.”. I mean, if we have someone asking I am pretty sure that anybody from the core team would be able to find some based on the candidate preference.
We have just missed Google summer of code 2021, I was really trying to squeeze this into my schedule but due to various circumstances I was not able to. Hopefully next year, there are many synergies with GSoC and first-timer contributions because one of the tasks for a project to join GSoC is to create a page with several assignments for students. These must be well defined, easy to understand, isolated and with a dedicated mentor ready to jump in to help. I also think it is better to have a reasonably-sized and isolated task that is not just fixing a typo.
I do think that getting people onboard for Foreman needs more personal approach, maybe we could figure out some good process. Out of my head:
Having some point of contact for people who are interested in. Ths must be easy to use, perhaps a Google Form with couple of questions: what are your current skills, which parts are you interested, do you want to start with small fix or small feature…
List of mentors who are ready to commit to help first-timers. Mentors must be ready to be ask for a list of easy bugs, easy small features, perhaps GSoC-sized tasks if we get to that.
Updating our onboarding documents, if we actually have any. I can thin about Contributing section which is a good start for Foreman core contributions, maybe for plugins it’s something we don’t have.
This was a positive and rewarding experience for the both of us, and resulted in a better patch than either of us might have come up with on our own. I highly recommend to other community members to look for opportunities to share this kind of experience with would-be contributors, whether that involves asynchronous collaboration or live pair programming.
I like the recommendations proposed so far around formalizing this process and making it more scalable, I agree that your ideas are a much better approach than simply tagging some GH issues and throwing them on a 3rd party site, and I’d like to volunteer my time towards building that out.
