Good suggestions. The "good-first-issues" work great when people are actively searching what to do though, for example in Airflow we usually have someone signing up to do "good first issue" usually within an hour or two after the label is set. We don't have up-for-grabs, but we have instead "projects" in GitHub where we have opened "bigger" work (such as Airflow Improvement Proposals) split into smaller tasks - and those are usually indeed more "substantial" and attract more experienced contributors.
100% agree that actual human, quick communication with newcomers is vital. You should optimize for time of response - even if that response is "yeah we are aware of that" - however we rarely provide estimates - we try to continuously educate our newcomers that in open-source, things happen when people have time and rather try to explain and set their expectations rather than give promises that we might not be able to fulfill. We are trying to be fully transparent like "when this will be released? When we are ready". etc. One other thing I found is that it's usually quite efficient to turn users and generally people who are reporting issues into contributors, and it should be done very proactively. When someone reports an issue - even if they are not checking the "I want to submit a fix" box - is to give some hints and ask the user if they would like to contribute a fix - with some hint on how to start (link to quick-start contributing guide - which should be really quick - we recently decreased the size of it to 150 lines or so). Also this is particularly effective when you help the user and the result of that "documentation does not explain it well". This is a perfect opportunity to turn such a user who reported an issue and got helped into a contributor - and you can easily tap on "give back" vibe. I have a prepared message (I always do it from memory to not do it always as identical copy-paste) to explain that "As a user who just got helped and search for a solution, you are probably best to pin-point the right place in the docs and to explain it in your words, to help people like you, because we - maintainers - have too many assumptions in our heads to explain it in simple words, so you are probably currently the best person in the world to know how to update the docs". This does not only provide a strong social pressure to give back, but is also actually 100% true. What **really** help in this case is a quick path from the docs to contributing fixes to it -> in the case of Airflow we have this sphinx plugin that adds "Suggest a change on this page" button at the bottom right of the page. Users can click it and GitHub will ask the user to create a fork and open a PR with the source of the page (.rst) that they can edit - actually even without leaving GitHub UI. See https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/overview.html#airflow-components for example. Reducing friction on such "absolutely small first contribution that you can do without leaving GitHub UI" is a key to success of Airflow when it comes to a number of contributors. This works wonderfully - we have plenty of such small contributions from our users to the docs as a result. And the truth is that it's on the lower side of single percent digit to convert such a "single doc fix" contributor into a more regular one. And it's hard to increase that single-percent-digit - so you have to do everything to have a bigger number to get the percent applied to. As "bad" as it might sound - this is a classing "sales" funnel - you have leads -> prospects -> interested -> engaged -> sold funnel and usually the funnel should be very big at the beginning to get single success at the end. In this case you are "selling" a contribution opportunity - and the best way to have more contributors is to have a very big funnel at the beginning, i.e. as little friction as possible, and using every opportunity you can to increase the funnel "entry" to begin with. Proactively. J. On Mon, Nov 10, 2025 at 5:23 PM Daniel B. Widdis <[email protected]> wrote: > > Great suggestions by Justin. > > In addition to the "good first issues" tag, I'd also suggest the "up for > grabs" tag. > > "Good first issues" may sometimes be viewed as too simple for more > experienced contributors (elsewhere) while "up for grabs" gives a clear > signal to the community that community participation is desired for more > substantive contributions. > > Quickly acknowledging and communicating with newcomers is vital, even if > it's a quick note of thanks and an estimate of when there will be time for > further review. > > > > On Sat, Nov 8, 2025 at 5:34 PM <[email protected]> wrote: > > > Hi. > > > > Here’s how I’ve handled this in my experience. > > > > One of the best ways I’ve found to help new contributors is to turn real > > project needs into clear, accessible opportunities. For instance, if > > someone notices a missing test, a documentation gap, or an unreviewed PR, > > mentors can ask the PPMC to label these as “good first issues” and include > > a short note about what’s needed and how to get started. > > > > Creating “good first issues” by hand, with code quality tools, or even > > with AI can help attract new contributors. Some websites gather and share > > these beginner-friendly issues, allowing people who might not have > > otherwise found the project to get involved. > > > > It’s also important to reply quickly and acknowledge newcomers’ work. > > Responding early helps them feel confident and makes them more likely to > > contribute again. > > I’ve found it challenging to turn casual contributors into long-term ones > > or to encourage them to take on more substantial tasks. Still, I don’t > > think this is a significant problem, since some people will always prefer > > to contribute occasionally. The most important thing is that the work gets > > done and the community remains open to everyone, regardless of their level > > of contribution. > > > > One thing that has worked for me is to set up a larger task that’s > > important but not urgent, allowing the timeline to be flexible. Breaking it > > down into smaller, clear steps enables different people to take on parts at > > their own pace. This way, casual contributors can join in on something > > meaningful without feeling rushed, and sometimes a few will stick around to > > finish later steps. > > > > One other challenge is convincing people who work full-time on the project > > that this approach is valuable. Some developers view “good first issues” as > > a lowering of code quality or as time they could better spend writing new > > features. It can take some effort to demonstrate that mentoring new > > contributors is an investment in community health and long-term > > sustainability, rather than a distraction from progress. > > > > Another challenge is getting non-code contributions accepted. Sometimes > > things like documentation, website updates, or community outreach aren’t > > valued as much as technical work, even though they’re key for growth and > > sustainability. Mentors can help by reminding everyone that these > > contributions matter and by encouraging the PPMC to review and recognise > > them quickly. > > > > Kind Regards, > > Justin > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > -- > Dan Widdis --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
