I think there are two main hurdles, one is restoring contributor interest in
mentoring, and the other is finding newcomers that actually want to stick
around. These are perhaps two sides of the same coin, though. An ugly truth is
that it isn't very enjoyable or rewarding to help newcomers when they mostly
don't stick around - often even to complete their first patch! The patches are
mostly uninteresting, the work often done to a low standard, and it is easy to
underestimate the amount of time involved in every such failed interaction.
I think making it easier to contribute and demonstrate a lasting interest in
the project without the hand holding of long term contributors may benefit both
sides of the equation, as it is more rewarding to help somebody who's
demonstrated a persistent interest in the community.
On 28/04/2021, 03:24, "Paulo Motta" <pauloricard...@gmail.com> wrote:
> 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.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
