> There is no great hurdle in finding something to work on, it's solely finding someone with the knowledge that can help you work on something and progress it to commit.
I agree the primary challenge is to engage existing contributors to mentor newcomers, but this doesn’t preclude having good documentation and a well maintained task pool to allow newcomers to self-serve as much as possible and reduce the mentoring burden, so these efforts are complimentary. For instance, a few students were interested in picking random tasks to work on in preparation for Google Summer of Code, but it was not straightforward for them to find a task to work on because we don’t consistently label tickets as “Low Hanging Fruit” and the ones that are tagged sometimes don’t have meaningful descriptions making it hard for these students to get started on tasks without unnecessarily taking some time from the mentor (which could have been saved if the tasks were properly described and labeled in the first place). On Tue, 27 Apr 2021 at 22:24 Kane Wilson <k...@raft.so> wrote: > The main problem, as has always been, is that the big players have a > stranglehold on all the committer resources, and bringing in new > contributors is not high on their priorities. All that's really required > here is that existing committers are directed to spend some non-negligible > portion of their time assisting non-committers (especially those not > already employed in their own organisation). That should really be a > starting point, as any other measures you take will not help until the time > is allocated so people can actually receive feedback and help from the > small pool of knowledge available. > > There is no great hurdle in finding something to work on, it's solely > finding someone with the knowledge that can help you work on something and > progress it to commit. > > > > Run a committer incubator program: Take applications for a small number > > of spots(5-10) and mentor these new engineers through learning the code > > base, understanding the contribution process, and eventually making > > substantive code contributions to the project. The eventual goal is that > > those who finish will be added as a committer to the project. This could > be > > as big or small as we want but I can see all sorts of great things that > > could come of this. > > > This is a great idea as a follow up (i.e, after there is evidence that > contributions are being progressed), as it would give a more concrete > process and confidence for existing contributors that they can eventually > become committers, and insight into what work is required. >
