Re: [DISCUSSION] Attracting new contributors

[Benjamin Lerer]

Thanks Paulo, that would be great. And thank you Angelo for raising the
problem.

Le jeu. 29 avr. 2021 à 15:13, Paulo Motta  a
écrit :

> > Effectively, some people provide patches without assigning the ticket to
> themselves. :-(
>
> I will try to think of an automation in the context of the JIRA hygiene
> effort that detects this and sends an automatic message asking the person
> to set themselves as assignees.
>
> Em qui., 29 de abr. de 2021 às 09:52, Benjamin Lerer 
> escreveu:
>
> > >
> > > Might also want to check among the tickets opened by non-committers and
> > > still awaiting an assignee. E.g.
> > >
> > > *assignee is EMPTY AND reporter not in membersOf(Committers)*
> > >
> > > There are patches/pull-requests there too.
> >
> >
> > Effectively, some people provide patches without assigning the ticket to
> > themselves. :-(
> >
> > Le jeu. 29 avr. 2021 à 14:17, Angelo Polo  a
> > écrit :
> >
> > > Might also want to check among the tickets opened by non-committers and
> > > still awaiting an assignee. E.g.
> > >
> > > *assignee is EMPTY AND reporter not in membersOf(Committers)*
> > >
> > > There are patches/pull-requests there too.
> > >
> > > Best,
> > > Angelo
> > >
> > > On Thu, Apr 29, 2021 at 1:51 PM Benjamin Lerer 
> > wrote:
> > >
> > > > >
> > > > > Berenguer created this board to help to track newcomers
> > contributions:
> > > > >
> > > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=463=2088
> > > >
> > > >
> > > > My apologies, the board was not accessible to most persons. I solved
> > that
> > > > and everybody should have access to it now.
> > > >
> > > > Some committers are appearing in the list because they do not belong
> to
> > > the
> > > > correct JIRA groups. I opened a ticket to INFRA to solve that
> problem (
> > > > INFRA-21808 ).
> > > >
> > > > Nevertheless we have obviously a serious issue because even after
> > > removing
> > > > the committers we have more than 80 non committer patches waiting for
> > > > reviews. I will try to go through them in the coming weeks to see
> what
> > > > happened with those patches and what we can do about them.
> > > >
> > > > My hope is that with this new board we can ensure that we provide a
> > > timely
> > > > response to newcomers tickets.
> > > >
> > > > Le jeu. 29 avr. 2021 à 13:42, Benjamin Lerer  a
> > > écrit :
> > > >
> > > > > Thanks for the feedback Aleksei,
> > > > >
> > > > > A good way of doing that
> > > > >> is having some rewards. It might be smth material like a T-Shirt
> (I
> > > > >> remember getting a T-Shirt on C* v2 release was nice; obviously
> not
> > > for
> > > > >> a single commit, but for multiple - depends on the budget; or top
> 10
> > > the
> > > > >> most active external contributors) or smth free like a virtual
> > badge,
> > > > >> being posted in an annual list of contributors or similar.
> > > > >
> > > > >
> > > > > It seems that we will need to find some sponsors for some t-shirt
> ;-)
> > > We
> > > > > definitely need to have some T-shirts for 4.0!!!
> > > > >
> > > > >   If there is a need I can volunteer/kick off any of the above
> > points.
> > > > >>
> > > > >
> > > > > Please do. Feel free to fire some discussions on the dev list to
> > > discuss
> > > > > each of those points. Simply take care to do it for one subject at
> a
> > > time
> > > > > as people might have some trouble to follow all the discussions
> going
> > > on
> > > > > otherwise.
> > > > >
> > > > > Le jeu. 29 avr. 2021 à 13:23, Benedict Elliott Smith <
> > > > bened...@apache.org>
> > > > > a écrit :
> > > > >
> > > > >> Thanks Aleksei,
> > > > >>
> > > > >> Some of these are great points, but to respond specifically to the
> > > > >> checkstyle suggestion: I hope to kick off some (minor) discussion
> > > around
> > > > >> codestyle soon to modernise our guide, however I would personally
> > > prefer
> > > > >> that code style enforcement remains relatively light touch. Some
> > > obvious
> > > > >> things could be enforced by checkstyle (such as the braces), and
> we
> > > > should
> > > > >> investigate that*, but I would hate for the project to get _too_
> > > > mechanical
> > > > >> about the way code is structured.
> > > > >>
> > > > >> I've been fairly opposed to the upheaval caused by changing build
> > > > >> tooling, but you're right that the barrier to booting up your IDE
> > is a
> > > > big
> > > > >> part of the contribution overhead for newbies, so perhaps we
> should
> > > take
> > > > >> another look at it.
> > > > >>
> > > > >> * I hope to utilise checkstyle soon to prohibit certain specific
> > code
> > > > >> patterns too, but that’s for a much later discussion
> > > > >>
> > > > >>
> > > > >> On 29/04/2021, 12:05, "Aleksei Zotov" 
> wrote:
> > > > >>
> > > > >> Hi Benjamin,
> > > > >>
> > > > >> I'd like to put in my two cents as well.
> > > > >>
> > > > >> There were many great suggestions related 

Re: [DISCUSSION] Attracting new contributors

[Paulo Motta]

> Effectively, some people provide patches without assigning the ticket to
themselves. :-(

I will try to think of an automation in the context of the JIRA hygiene
effort that detects this and sends an automatic message asking the person
to set themselves as assignees.

Em qui., 29 de abr. de 2021 às 09:52, Benjamin Lerer 
escreveu:

> >
> > Might also want to check among the tickets opened by non-committers and
> > still awaiting an assignee. E.g.
> >
> > *assignee is EMPTY AND reporter not in membersOf(Committers)*
> >
> > There are patches/pull-requests there too.
>
>
> Effectively, some people provide patches without assigning the ticket to
> themselves. :-(
>
> Le jeu. 29 avr. 2021 à 14:17, Angelo Polo  a
> écrit :
>
> > Might also want to check among the tickets opened by non-committers and
> > still awaiting an assignee. E.g.
> >
> > *assignee is EMPTY AND reporter not in membersOf(Committers)*
> >
> > There are patches/pull-requests there too.
> >
> > Best,
> > Angelo
> >
> > On Thu, Apr 29, 2021 at 1:51 PM Benjamin Lerer 
> wrote:
> >
> > > >
> > > > Berenguer created this board to help to track newcomers
> contributions:
> > > >
> > > >
> > >
> >
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=463=2088
> > >
> > >
> > > My apologies, the board was not accessible to most persons. I solved
> that
> > > and everybody should have access to it now.
> > >
> > > Some committers are appearing in the list because they do not belong to
> > the
> > > correct JIRA groups. I opened a ticket to INFRA to solve that problem (
> > > INFRA-21808 ).
> > >
> > > Nevertheless we have obviously a serious issue because even after
> > removing
> > > the committers we have more than 80 non committer patches waiting for
> > > reviews. I will try to go through them in the coming weeks to see what
> > > happened with those patches and what we can do about them.
> > >
> > > My hope is that with this new board we can ensure that we provide a
> > timely
> > > response to newcomers tickets.
> > >
> > > Le jeu. 29 avr. 2021 à 13:42, Benjamin Lerer  a
> > écrit :
> > >
> > > > Thanks for the feedback Aleksei,
> > > >
> > > > A good way of doing that
> > > >> is having some rewards. It might be smth material like a T-Shirt (I
> > > >> remember getting a T-Shirt on C* v2 release was nice; obviously not
> > for
> > > >> a single commit, but for multiple - depends on the budget; or top 10
> > the
> > > >> most active external contributors) or smth free like a virtual
> badge,
> > > >> being posted in an annual list of contributors or similar.
> > > >
> > > >
> > > > It seems that we will need to find some sponsors for some t-shirt ;-)
> > We
> > > > definitely need to have some T-shirts for 4.0!!!
> > > >
> > > >   If there is a need I can volunteer/kick off any of the above
> points.
> > > >>
> > > >
> > > > Please do. Feel free to fire some discussions on the dev list to
> > discuss
> > > > each of those points. Simply take care to do it for one subject at a
> > time
> > > > as people might have some trouble to follow all the discussions going
> > on
> > > > otherwise.
> > > >
> > > > Le jeu. 29 avr. 2021 à 13:23, Benedict Elliott Smith <
> > > bened...@apache.org>
> > > > a écrit :
> > > >
> > > >> Thanks Aleksei,
> > > >>
> > > >> Some of these are great points, but to respond specifically to the
> > > >> checkstyle suggestion: I hope to kick off some (minor) discussion
> > around
> > > >> codestyle soon to modernise our guide, however I would personally
> > prefer
> > > >> that code style enforcement remains relatively light touch. Some
> > obvious
> > > >> things could be enforced by checkstyle (such as the braces), and we
> > > should
> > > >> investigate that*, but I would hate for the project to get _too_
> > > mechanical
> > > >> about the way code is structured.
> > > >>
> > > >> I've been fairly opposed to the upheaval caused by changing build
> > > >> tooling, but you're right that the barrier to booting up your IDE
> is a
> > > big
> > > >> part of the contribution overhead for newbies, so perhaps we should
> > take
> > > >> another look at it.
> > > >>
> > > >> * I hope to utilise checkstyle soon to prohibit certain specific
> code
> > > >> patterns too, but that’s for a much later discussion
> > > >>
> > > >>
> > > >> On 29/04/2021, 12:05, "Aleksei Zotov"  wrote:
> > > >>
> > > >> Hi Benjamin,
> > > >>
> > > >> I'd like to put in my two cents as well.
> > > >>
> > > >> There were many great suggestions related to the communication
> and
> > > >> process. They make sense to me, however, I'd like to look at the
> > > >> problem
> > > >> from another perspective.
> > > >>
> > > >> First of all, let me share my perception on the opensource
> > > >> activities.
> > > >> There are two main reasons why people may want to contribute: 1)
> > > they
> > > >> experience a problem on the current project 2) any kind of
> > > >> 

Re: [DISCUSSION] Attracting new contributors

[Benjamin Lerer]

>
> Might also want to check among the tickets opened by non-committers and
> still awaiting an assignee. E.g.
>
> *assignee is EMPTY AND reporter not in membersOf(Committers)*
>
> There are patches/pull-requests there too.


Effectively, some people provide patches without assigning the ticket to
themselves. :-(

Le jeu. 29 avr. 2021 à 14:17, Angelo Polo  a
écrit :

> Might also want to check among the tickets opened by non-committers and
> still awaiting an assignee. E.g.
>
> *assignee is EMPTY AND reporter not in membersOf(Committers)*
>
> There are patches/pull-requests there too.
>
> Best,
> Angelo
>
> On Thu, Apr 29, 2021 at 1:51 PM Benjamin Lerer  wrote:
>
> > >
> > > Berenguer created this board to help to track newcomers contributions:
> > >
> > >
> >
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=463=2088
> >
> >
> > My apologies, the board was not accessible to most persons. I solved that
> > and everybody should have access to it now.
> >
> > Some committers are appearing in the list because they do not belong to
> the
> > correct JIRA groups. I opened a ticket to INFRA to solve that problem (
> > INFRA-21808 ).
> >
> > Nevertheless we have obviously a serious issue because even after
> removing
> > the committers we have more than 80 non committer patches waiting for
> > reviews. I will try to go through them in the coming weeks to see what
> > happened with those patches and what we can do about them.
> >
> > My hope is that with this new board we can ensure that we provide a
> timely
> > response to newcomers tickets.
> >
> > Le jeu. 29 avr. 2021 à 13:42, Benjamin Lerer  a
> écrit :
> >
> > > Thanks for the feedback Aleksei,
> > >
> > > A good way of doing that
> > >> is having some rewards. It might be smth material like a T-Shirt (I
> > >> remember getting a T-Shirt on C* v2 release was nice; obviously not
> for
> > >> a single commit, but for multiple - depends on the budget; or top 10
> the
> > >> most active external contributors) or smth free like a virtual badge,
> > >> being posted in an annual list of contributors or similar.
> > >
> > >
> > > It seems that we will need to find some sponsors for some t-shirt ;-)
> We
> > > definitely need to have some T-shirts for 4.0!!!
> > >
> > >   If there is a need I can volunteer/kick off any of the above points.
> > >>
> > >
> > > Please do. Feel free to fire some discussions on the dev list to
> discuss
> > > each of those points. Simply take care to do it for one subject at a
> time
> > > as people might have some trouble to follow all the discussions going
> on
> > > otherwise.
> > >
> > > Le jeu. 29 avr. 2021 à 13:23, Benedict Elliott Smith <
> > bened...@apache.org>
> > > a écrit :
> > >
> > >> Thanks Aleksei,
> > >>
> > >> Some of these are great points, but to respond specifically to the
> > >> checkstyle suggestion: I hope to kick off some (minor) discussion
> around
> > >> codestyle soon to modernise our guide, however I would personally
> prefer
> > >> that code style enforcement remains relatively light touch. Some
> obvious
> > >> things could be enforced by checkstyle (such as the braces), and we
> > should
> > >> investigate that*, but I would hate for the project to get _too_
> > mechanical
> > >> about the way code is structured.
> > >>
> > >> I've been fairly opposed to the upheaval caused by changing build
> > >> tooling, but you're right that the barrier to booting up your IDE is a
> > big
> > >> part of the contribution overhead for newbies, so perhaps we should
> take
> > >> another look at it.
> > >>
> > >> * I hope to utilise checkstyle soon to prohibit certain specific code
> > >> patterns too, but that’s for a much later discussion
> > >>
> > >>
> > >> On 29/04/2021, 12:05, "Aleksei Zotov"  wrote:
> > >>
> > >> Hi Benjamin,
> > >>
> > >> I'd like to put in my two cents as well.
> > >>
> > >> There were many great suggestions related to the communication and
> > >> process. They make sense to me, however, I'd like to look at the
> > >> problem
> > >> from another perspective.
> > >>
> > >> First of all, let me share my perception on the opensource
> > >> activities.
> > >> There are two main reasons why people may want to contribute: 1)
> > they
> > >> experience a problem on the current project 2) any kind of
> > >> volunteering.
> > >> The first reason is clear, those contributors are not going to
> stick
> > >> around because they just need to solve their particular problem.
> > >>
> > >> The second group of people is our target. In fact, there could be
> > >> numerous reasons why people want to contribute (feel bored, get
> new
> > >> experience, improve resume, etc), but despite the particular
> > >> motivation
> > >> point, people should feel positive of what they are doing. For
> that
> > >> we
> > >> should make sure they feel a part of the team/process and their
> work
> > >> 

Re: [DISCUSSION] Attracting new contributors

[Angelo Polo]

Might also want to check among the tickets opened by non-committers and
still awaiting an assignee. E.g.

*assignee is EMPTY AND reporter not in membersOf(Committers)*

There are patches/pull-requests there too.

Best,
Angelo

On Thu, Apr 29, 2021 at 1:51 PM Benjamin Lerer  wrote:

> >
> > Berenguer created this board to help to track newcomers contributions:
> >
> >
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=463=2088
>
>
> My apologies, the board was not accessible to most persons. I solved that
> and everybody should have access to it now.
>
> Some committers are appearing in the list because they do not belong to the
> correct JIRA groups. I opened a ticket to INFRA to solve that problem (
> INFRA-21808 ).
>
> Nevertheless we have obviously a serious issue because even after removing
> the committers we have more than 80 non committer patches waiting for
> reviews. I will try to go through them in the coming weeks to see what
> happened with those patches and what we can do about them.
>
> My hope is that with this new board we can ensure that we provide a timely
> response to newcomers tickets.
>
> Le jeu. 29 avr. 2021 à 13:42, Benjamin Lerer  a écrit :
>
> > Thanks for the feedback Aleksei,
> >
> > A good way of doing that
> >> is having some rewards. It might be smth material like a T-Shirt (I
> >> remember getting a T-Shirt on C* v2 release was nice; obviously not for
> >> a single commit, but for multiple - depends on the budget; or top 10 the
> >> most active external contributors) or smth free like a virtual badge,
> >> being posted in an annual list of contributors or similar.
> >
> >
> > It seems that we will need to find some sponsors for some t-shirt ;-) We
> > definitely need to have some T-shirts for 4.0!!!
> >
> >   If there is a need I can volunteer/kick off any of the above points.
> >>
> >
> > Please do. Feel free to fire some discussions on the dev list to discuss
> > each of those points. Simply take care to do it for one subject at a time
> > as people might have some trouble to follow all the discussions going on
> > otherwise.
> >
> > Le jeu. 29 avr. 2021 à 13:23, Benedict Elliott Smith <
> bened...@apache.org>
> > a écrit :
> >
> >> Thanks Aleksei,
> >>
> >> Some of these are great points, but to respond specifically to the
> >> checkstyle suggestion: I hope to kick off some (minor) discussion around
> >> codestyle soon to modernise our guide, however I would personally prefer
> >> that code style enforcement remains relatively light touch. Some obvious
> >> things could be enforced by checkstyle (such as the braces), and we
> should
> >> investigate that*, but I would hate for the project to get _too_
> mechanical
> >> about the way code is structured.
> >>
> >> I've been fairly opposed to the upheaval caused by changing build
> >> tooling, but you're right that the barrier to booting up your IDE is a
> big
> >> part of the contribution overhead for newbies, so perhaps we should take
> >> another look at it.
> >>
> >> * I hope to utilise checkstyle soon to prohibit certain specific code
> >> patterns too, but that’s for a much later discussion
> >>
> >>
> >> On 29/04/2021, 12:05, "Aleksei Zotov"  wrote:
> >>
> >> Hi Benjamin,
> >>
> >> I'd like to put in my two cents as well.
> >>
> >> There were many great suggestions related to the communication and
> >> process. They make sense to me, however, I'd like to look at the
> >> problem
> >> from another perspective.
> >>
> >> First of all, let me share my perception on the opensource
> >> activities.
> >> There are two main reasons why people may want to contribute: 1)
> they
> >> experience a problem on the current project 2) any kind of
> >> volunteering.
> >> The first reason is clear, those contributors are not going to stick
> >> around because they just need to solve their particular problem.
> >>
> >> The second group of people is our target. In fact, there could be
> >> numerous reasons why people want to contribute (feel bored, get new
> >> experience, improve resume, etc), but despite the particular
> >> motivation
> >> point, people should feel positive of what they are doing. For that
> >> we
> >> should make sure they feel a part of the team/process and their work
> >> appreciated.
> >>
> >> The first point is related to many suggestions that have been
> already
> >> brought. I feel the most important here is timely replies (even
> >> "sorry,
> >> we're busy these days, I'll review/respond in two weeks / after xxx
> >> version is released" is much better than silence). Such "follow up"
> >> responses do not address the original queries, but they help the
> >> external contributors to keep courage and remove uncertainty related
> >> to
> >> the lack of transparency (it might not be clear: a) whether the
> >> request
> >> is still on someone's radar b) 

Re: [DISCUSSION] Attracting new contributors

[Benjamin Lerer]

>
> Berenguer created this board to help to track newcomers contributions:
>
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=463=2088


My apologies, the board was not accessible to most persons. I solved that
and everybody should have access to it now.

Some committers are appearing in the list because they do not belong to the
correct JIRA groups. I opened a ticket to INFRA to solve that problem (
INFRA-21808 ).

Nevertheless we have obviously a serious issue because even after removing
the committers we have more than 80 non committer patches waiting for
reviews. I will try to go through them in the coming weeks to see what
happened with those patches and what we can do about them.

My hope is that with this new board we can ensure that we provide a timely
response to newcomers tickets.

Le jeu. 29 avr. 2021 à 13:42, Benjamin Lerer  a écrit :

> Thanks for the feedback Aleksei,
>
> A good way of doing that
>> is having some rewards. It might be smth material like a T-Shirt (I
>> remember getting a T-Shirt on C* v2 release was nice; obviously not for
>> a single commit, but for multiple - depends on the budget; or top 10 the
>> most active external contributors) or smth free like a virtual badge,
>> being posted in an annual list of contributors or similar.
>
>
> It seems that we will need to find some sponsors for some t-shirt ;-) We
> definitely need to have some T-shirts for 4.0!!!
>
>   If there is a need I can volunteer/kick off any of the above points.
>>
>
> Please do. Feel free to fire some discussions on the dev list to discuss
> each of those points. Simply take care to do it for one subject at a time
> as people might have some trouble to follow all the discussions going on
> otherwise.
>
> Le jeu. 29 avr. 2021 à 13:23, Benedict Elliott Smith 
> a écrit :
>
>> Thanks Aleksei,
>>
>> Some of these are great points, but to respond specifically to the
>> checkstyle suggestion: I hope to kick off some (minor) discussion around
>> codestyle soon to modernise our guide, however I would personally prefer
>> that code style enforcement remains relatively light touch. Some obvious
>> things could be enforced by checkstyle (such as the braces), and we should
>> investigate that*, but I would hate for the project to get _too_ mechanical
>> about the way code is structured.
>>
>> I've been fairly opposed to the upheaval caused by changing build
>> tooling, but you're right that the barrier to booting up your IDE is a big
>> part of the contribution overhead for newbies, so perhaps we should take
>> another look at it.
>>
>> * I hope to utilise checkstyle soon to prohibit certain specific code
>> patterns too, but that’s for a much later discussion
>>
>>
>> On 29/04/2021, 12:05, "Aleksei Zotov"  wrote:
>>
>> Hi Benjamin,
>>
>> I'd like to put in my two cents as well.
>>
>> There were many great suggestions related to the communication and
>> process. They make sense to me, however, I'd like to look at the
>> problem
>> from another perspective.
>>
>> First of all, let me share my perception on the opensource
>> activities.
>> There are two main reasons why people may want to contribute: 1) they
>> experience a problem on the current project 2) any kind of
>> volunteering.
>> The first reason is clear, those contributors are not going to stick
>> around because they just need to solve their particular problem.
>>
>> The second group of people is our target. In fact, there could be
>> numerous reasons why people want to contribute (feel bored, get new
>> experience, improve resume, etc), but despite the particular
>> motivation
>> point, people should feel positive of what they are doing. For that
>> we
>> should make sure they feel a part of the team/process and their work
>> appreciated.
>>
>> The first point is related to many suggestions that have been already
>> brought. I feel the most important here is timely replies (even
>> "sorry,
>> we're busy these days, I'll review/respond in two weeks / after xxx
>> version is released" is much better than silence). Such "follow up"
>> responses do not address the original queries, but they help the
>> external contributors to keep courage and remove uncertainty related
>> to
>> the lack of transparency (it might not be clear: a) whether the
>> request
>> is still on someone's radar b) when to expect a response c) when it
>> is a
>> good time to follow up). And obviously a "real" (or at least another
>> "follow up") response needs to be provided within the ETA. This still
>> does not resolve the problem of committers bandwidth, but allows to
>> handle spikes in requests from the contributors.
>>
>> Appreciation is the second point. Generally people like making
>> achievements, we just need to make every contribution a kind of
>> achievement that a person somehow may 

Re: [DISCUSSION] Attracting new contributors

[Benjamin Lerer]

Thanks for the feedback Aleksei,

A good way of doing that
> is having some rewards. It might be smth material like a T-Shirt (I
> remember getting a T-Shirt on C* v2 release was nice; obviously not for
> a single commit, but for multiple - depends on the budget; or top 10 the
> most active external contributors) or smth free like a virtual badge,
> being posted in an annual list of contributors or similar.


It seems that we will need to find some sponsors for some t-shirt ;-) We
definitely need to have some T-shirts for 4.0!!!

  If there is a need I can volunteer/kick off any of the above points.
>

Please do. Feel free to fire some discussions on the dev list to discuss
each of those points. Simply take care to do it for one subject at a time
as people might have some trouble to follow all the discussions going on
otherwise.

Le jeu. 29 avr. 2021 à 13:23, Benedict Elliott Smith 
a écrit :

> Thanks Aleksei,
>
> Some of these are great points, but to respond specifically to the
> checkstyle suggestion: I hope to kick off some (minor) discussion around
> codestyle soon to modernise our guide, however I would personally prefer
> that code style enforcement remains relatively light touch. Some obvious
> things could be enforced by checkstyle (such as the braces), and we should
> investigate that*, but I would hate for the project to get _too_ mechanical
> about the way code is structured.
>
> I've been fairly opposed to the upheaval caused by changing build tooling,
> but you're right that the barrier to booting up your IDE is a big part of
> the contribution overhead for newbies, so perhaps we should take another
> look at it.
>
> * I hope to utilise checkstyle soon to prohibit certain specific code
> patterns too, but that’s for a much later discussion
>
>
> On 29/04/2021, 12:05, "Aleksei Zotov"  wrote:
>
> Hi Benjamin,
>
> I'd like to put in my two cents as well.
>
> There were many great suggestions related to the communication and
> process. They make sense to me, however, I'd like to look at the
> problem
> from another perspective.
>
> First of all, let me share my perception on the opensource activities.
> There are two main reasons why people may want to contribute: 1) they
> experience a problem on the current project 2) any kind of
> volunteering.
> The first reason is clear, those contributors are not going to stick
> around because they just need to solve their particular problem.
>
> The second group of people is our target. In fact, there could be
> numerous reasons why people want to contribute (feel bored, get new
> experience, improve resume, etc), but despite the particular
> motivation
> point, people should feel positive of what they are doing. For that we
> should make sure they feel a part of the team/process and their work
> appreciated.
>
> The first point is related to many suggestions that have been already
> brought. I feel the most important here is timely replies (even
> "sorry,
> we're busy these days, I'll review/respond in two weeks / after xxx
> version is released" is much better than silence). Such "follow up"
> responses do not address the original queries, but they help the
> external contributors to keep courage and remove uncertainty related
> to
> the lack of transparency (it might not be clear: a) whether the
> request
> is still on someone's radar b) when to expect a response c) when it is
> a
> good time to follow up). And obviously a "real" (or at least another
> "follow up") response needs to be provided within the ETA. This still
> does not resolve the problem of committers bandwidth, but allows to
> handle spikes in requests from the contributors.
>
> Appreciation is the second point. Generally people like making
> achievements, we just need to make every contribution a kind of
> achievement that a person somehow may boast of. A good way of doing
> that
> is having some rewards. It might be smth material like a T-Shirt (I
> remember getting a T-Shirt on C* v2 release was nice; obviously not
> for
> a single commit, but for multiple - depends on the budget; or top 10
> the
> most active external contributors) or smth free like a virtual badge,
> being posted in an annual list of contributors or similar. Even though
> it may sound a bit naive, I believe people like making and counting
> achievements and it might help to attract/retain the contributors.
>
> On a separate note, there is a technical part of the problem of
> attracting (not retaining) the contributors. It is really important to
> make sure that the entry level is low enough and people do not spend
> much time on additional configuration, learning styling guidelines,
> etc
> for making their first contribution. No-one likes boring stuff :)
>
> Based on my experience among many opensource projects, it is really
> 

Re: [DISCUSSION] Attracting new contributors

[Benedict Elliott Smith]

Thanks Aleksei,

Some of these are great points, but to respond specifically to the checkstyle 
suggestion: I hope to kick off some (minor) discussion around codestyle soon to 
modernise our guide, however I would personally prefer that code style 
enforcement remains relatively light touch. Some obvious things could be 
enforced by checkstyle (such as the braces), and we should investigate that*, 
but I would hate for the project to get _too_ mechanical about the way code is 
structured.

I've been fairly opposed to the upheaval caused by changing build tooling, but 
you're right that the barrier to booting up your IDE is a big part of the 
contribution overhead for newbies, so perhaps we should take another look at it.

* I hope to utilise checkstyle soon to prohibit certain specific code patterns 
too, but that’s for a much later discussion


On 29/04/2021, 12:05, "Aleksei Zotov"  wrote:

Hi Benjamin,

I'd like to put in my two cents as well.

There were many great suggestions related to the communication and 
process. They make sense to me, however, I'd like to look at the problem 
from another perspective.

First of all, let me share my perception on the opensource activities. 
There are two main reasons why people may want to contribute: 1) they 
experience a problem on the current project 2) any kind of volunteering. 
The first reason is clear, those contributors are not going to stick 
around because they just need to solve their particular problem.

The second group of people is our target. In fact, there could be 
numerous reasons why people want to contribute (feel bored, get new 
experience, improve resume, etc), but despite the particular motivation 
point, people should feel positive of what they are doing. For that we 
should make sure they feel a part of the team/process and their work 
appreciated.

The first point is related to many suggestions that have been already 
brought. I feel the most important here is timely replies (even "sorry, 
we're busy these days, I'll review/respond in two weeks / after xxx 
version is released" is much better than silence). Such "follow up" 
responses do not address the original queries, but they help the 
external contributors to keep courage and remove uncertainty related to 
the lack of transparency (it might not be clear: a) whether the request 
is still on someone's radar b) when to expect a response c) when it is a 
good time to follow up). And obviously a "real" (or at least another 
"follow up") response needs to be provided within the ETA. This still 
does not resolve the problem of committers bandwidth, but allows to 
handle spikes in requests from the contributors.

Appreciation is the second point. Generally people like making 
achievements, we just need to make every contribution a kind of 
achievement that a person somehow may boast of. A good way of doing that 
is having some rewards. It might be smth material like a T-Shirt (I 
remember getting a T-Shirt on C* v2 release was nice; obviously not for 
a single commit, but for multiple - depends on the budget; or top 10 the 
most active external contributors) or smth free like a virtual badge, 
being posted in an annual list of contributors or similar. Even though 
it may sound a bit naive, I believe people like making and counting 
achievements and it might help to attract/retain the contributors.

On a separate note, there is a technical part of the problem of 
attracting (not retaining) the contributors. It is really important to 
make sure that the entry level is low enough and people do not spend 
much time on additional configuration, learning styling guidelines, etc 
for making their first contribution. No-one likes boring stuff :)

Based on my experience among many opensource projects, it is really 
frustrating to spend hours of personal time on getting the build working 
locally, configuring IDE or similar problems that should not ever exist 
(or at least be well documented). I believe that many people loose their 
courage and give up on this stage (it is a kind of uncomfortable to ask 
for help in running tests in a group chat with 600+ people). For 
example, Intellij configuration (/ant generate-idea-files/) did not work 
for me (test classpath was missing 

,
 
imports and formatter configs were not picked up properly) - I fixed it 
myself. Netbeans configuration 


 
was also broken. All such minor issues are really major if they can 
potentially scare away the new contributors.

Even though it might sound too 

Re: [DISCUSSION] Attracting new contributors

[Aleksei Zotov]

Hi Benjamin,

I'd like to put in my two cents as well.

There were many great suggestions related to the communication and 
process. They make sense to me, however, I'd like to look at the problem 
from another perspective.


First of all, let me share my perception on the opensource activities. 
There are two main reasons why people may want to contribute: 1) they 
experience a problem on the current project 2) any kind of volunteering. 
The first reason is clear, those contributors are not going to stick 
around because they just need to solve their particular problem.


The second group of people is our target. In fact, there could be 
numerous reasons why people want to contribute (feel bored, get new 
experience, improve resume, etc), but despite the particular motivation 
point, people should feel positive of what they are doing. For that we 
should make sure they feel a part of the team/process and their work 
appreciated.


The first point is related to many suggestions that have been already 
brought. I feel the most important here is timely replies (even "sorry, 
we're busy these days, I'll review/respond in two weeks / after xxx 
version is released" is much better than silence). Such "follow up" 
responses do not address the original queries, but they help the 
external contributors to keep courage and remove uncertainty related to 
the lack of transparency (it might not be clear: a) whether the request 
is still on someone's radar b) when to expect a response c) when it is a 
good time to follow up). And obviously a "real" (or at least another 
"follow up") response needs to be provided within the ETA. This still 
does not resolve the problem of committers bandwidth, but allows to 
handle spikes in requests from the contributors.


Appreciation is the second point. Generally people like making 
achievements, we just need to make every contribution a kind of 
achievement that a person somehow may boast of. A good way of doing that 
is having some rewards. It might be smth material like a T-Shirt (I 
remember getting a T-Shirt on C* v2 release was nice; obviously not for 
a single commit, but for multiple - depends on the budget; or top 10 the 
most active external contributors) or smth free like a virtual badge, 
being posted in an annual list of contributors or similar. Even though 
it may sound a bit naive, I believe people like making and counting 
achievements and it might help to attract/retain the contributors.


On a separate note, there is a technical part of the problem of 
attracting (not retaining) the contributors. It is really important to 
make sure that the entry level is low enough and people do not spend 
much time on additional configuration, learning styling guidelines, etc 
for making their first contribution. No-one likes boring stuff :)


Based on my experience among many opensource projects, it is really 
frustrating to spend hours of personal time on getting the build working 
locally, configuring IDE or similar problems that should not ever exist 
(or at least be well documented). I believe that many people loose their 
courage and give up on this stage (it is a kind of uncomfortable to ask 
for help in running tests in a group chat with 600+ people). For 
example, Intellij configuration (/ant generate-idea-files/) did not work 
for me (test classpath was missing 
, 
imports and formatter configs were not picked up properly) - I fixed it 
myself. Netbeans configuration 
 
was also broken. All such minor issues are really major if they can 
potentially scare away the new contributors.


Even though it might sound too technical, I feel we may greatly benefit 
(in term of attracting the new contributors) from the below changes:


 - use a generic code style config (https://editorconfig.org/ 
), it is supported by Intellij, Eclipse and 
NetBeans.


 - migrate to /maven/, all modern IDEs support it pretty well (/gradle/ 
might be an option, but I believe it has slightly worse out of the box 
integration with IDEs - arguable point). In a combination with the 
previous point, there won't be a need to maintain separate IDE-specific 
configs. As a result, there are more chances that the IDE configuration 
will be kept valid and up-to-date. I understand it is a major effort, 
but /ant/ is almost died and this change is anyway inevitable.


 - introduce checkstyle (https://checkstyle.sourceforge.io/anttask.html 
, 
https://maven.apache.org/plugins/maven-checkstyle-plugin/ 
) that would 
fail the local build if smth is not-well formatted. Almost every project 
has its own style preferences (especially C* with 

Re: [DISCUSSION] Attracting new contributors

[Benjamin Lerer]

>
> Is it possible if a new comer works together with a mentor on an issue?
> This way mentor can gradually introduce the newcomer into the codebase, and
> newcomer would get timely feedback too.


It is complicated unfortunately because most of us have limited bandwidth
and we are spread across different time zones. Mentors can provide some
plans on how to address a specific issue and answer questions in an
asynchronous way but more than that will be difficult in my opinion.

Le mer. 28 avr. 2021 à 13:28, Manish G  a
écrit :

> Is it possible if a new comer works together with a mentor on an issue?
> This way mentor can gradually introduce the newcomer into the codebase, and
> newcomer would get timely feedback too.
>
>
> On Wed, Apr 28, 2021 at 2:51 PM Benedict Elliott Smith <
> bened...@apache.org>
> wrote:
>
> > > I believe that it can be a virtuous circle where we produce new
> > committers that help mentoring newcomers.
> >
> > That's the dream, and kudos for keeping it alive! I have become jaded
> > about this possibility, after years of trying.
> >
> >
> > On 28/04/2021, 10:18, "Benjamin Lerer"  wrote:
> >
> > >
> > > 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.
> >
> >
> > I am interested in mentoring new committers to help the project grow
> > and
> > some of the new committers expressed the same interest to me. I
> believe
> > that it can be a virtuous circle where we produce new committers that
> > help
> > mentoring newcomers.
> >
> > What we need is to be well organized and make sure that we have a
> > reasonable response time to newcomers.
> >
> > Berenguer created this board to help to track newcomers
> contributions:
> >
> >
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=463=2088
> > Apparently Brandon is cheating to appear as a newcomer but we will
> > solve
> > that. He should be at the Nightmare level  ;-)
> >
> > Le mer. 28 avr. 2021 à 10:54, Benedict Elliott Smith <
> > bened...@apache.org>
> > a écrit :
> >
> > > 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" 
> > 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  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 

Re: [DISCUSSION] Attracting new contributors

[Manish G]

Is it possible if a new comer works together with a mentor on an issue?
This way mentor can gradually introduce the newcomer into the codebase, and
newcomer would get timely feedback too.


On Wed, Apr 28, 2021 at 2:51 PM Benedict Elliott Smith 
wrote:

> > I believe that it can be a virtuous circle where we produce new
> committers that help mentoring newcomers.
>
> That's the dream, and kudos for keeping it alive! I have become jaded
> about this possibility, after years of trying.
>
>
> On 28/04/2021, 10:18, "Benjamin Lerer"  wrote:
>
> >
> > 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.
>
>
> I am interested in mentoring new committers to help the project grow
> and
> some of the new committers expressed the same interest to me. I believe
> that it can be a virtuous circle where we produce new committers that
> help
> mentoring newcomers.
>
> What we need is to be well organized and make sure that we have a
> reasonable response time to newcomers.
>
> Berenguer created this board to help to track newcomers contributions:
>
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=463=2088
> Apparently Brandon is cheating to appear as a newcomer but we will
> solve
> that. He should be at the Nightmare level  ;-)
>
> Le mer. 28 avr. 2021 à 10:54, Benedict Elliott Smith <
> bened...@apache.org>
> a écrit :
>
> > 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" 
> 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  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
> 

Re: [DISCUSSION] Attracting new contributors

[Benedict Elliott Smith]

> I believe that it can be a virtuous circle where we produce new committers 
> that help mentoring newcomers.

That's the dream, and kudos for keeping it alive! I have become jaded about 
this possibility, after years of trying.


On 28/04/2021, 10:18, "Benjamin Lerer"  wrote:

>
> 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.


I am interested in mentoring new committers to help the project grow and
some of the new committers expressed the same interest to me. I believe
that it can be a virtuous circle where we produce new committers that help
mentoring newcomers.

What we need is to be well organized and make sure that we have a
reasonable response time to newcomers.

Berenguer created this board to help to track newcomers contributions:

https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=463=2088
Apparently Brandon is cheating to appear as a newcomer but we will solve
that. He should be at the Nightmare level  ;-)

Le mer. 28 avr. 2021 à 10:54, Benedict Elliott Smith 
a écrit :

> 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"  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  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 

Re: [DISCUSSION] Attracting new contributors

[Benjamin Lerer]

>
> 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.


I am interested in mentoring new committers to help the project grow and
some of the new committers expressed the same interest to me. I believe
that it can be a virtuous circle where we produce new committers that help
mentoring newcomers.

What we need is to be well organized and make sure that we have a
reasonable response time to newcomers.

Berenguer created this board to help to track newcomers contributions:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=463=2088
Apparently Brandon is cheating to appear as a newcomer but we will solve
that. He should be at the Nightmare level  ;-)

Le mer. 28 avr. 2021 à 10:54, Benedict Elliott Smith 
a écrit :

> 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"  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  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
>
>

Re: [DISCUSSION] Attracting new contributors

[Benedict Elliott Smith]

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"  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  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

Re: [DISCUSSION] Attracting new contributors

[Paulo Motta]

> 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  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.
>

Re: [DISCUSSION] Attracting new contributors

[Kane Wilson]

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.

Re: [DISCUSSION] Attracting new contributors

[Lorina Poland]

I should chime in and mention that we are in the process of migrating the
Contributing/Development sections of the documentation to the site-wide,
non-versioned "docs" in cassandra-website, rather than in the docs. That
will come into existence when we can get the "new" docs, written in
asciidoc, in place. Soon.

Lorina
Lorina Poland
e. lor...@datastax.com
w. www.datastax.com



On Tue, Apr 27, 2021 at 11:32 AM Mick Semb Wever  wrote:

> > Thanks for bringing this important topic for discussion Benjamin. I think
> > it would help to enumerate what issues we face to attract new
> contributors
> > currently and then try to act on those.
> >
> > 1. Committers have little bandwidth to review low-impact issues (ie. Low
> > Hanging Fruit (LHF)), which are generally the entry-point for new
> > contributors. Lack of feedback on these initial contributions discourage
> > new contributions, creating a barrier for new contributors to join the
> > community (this point was raised by Stefan on this thread[1]).
> >
> > 2. Lack of consistency when labeling tickets as LHF. Some tickets are
> easy
> > but not tagged as LHF, some tickets are tagged as LHF but are not easy
> > enough for new contributors.
> >
> > 3. Lack of consistency when filling JIRA tickets. Some tickets have a
> clear
> > scope and definition, making it easier for new contributors to self serve
> > and figure out what needs to be done, while others have bad descriptions
> or
> > ill-defined scopes making it hard for beginners to work on these tickets.
> >
> > 4. Out of date or invalid JIRA tickets, making it harder for beginners to
> > figure out if a given ticket is valid or not to work on.
>
>
> I agree with this list Paulo. And I can see the hygiene of jira
> tickets, individually and overall, being one of the key points that we
> can immediately address (and you are!)
>
> This article was recently shared with me and I think it is a good
> starting point:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__opensource.com_article_19_12_open-2Dsource-2Dcontributors=DwIBaQ=adz96Xi0w1RHqtPMowiL2g=bL2UpIjL4Mm1mCbqWThJUiPD-CmTXMALsIT2Ta-KfGk=q_dsXQ6jX9WOdt0mTaSMswT8YBVJJ3tuHsqmiomJHYc=__XC3za3frwYqDZAgqymi4eS1lA6mVMYWt4NSw_8cF4=
>
> We do definitely have a blocker on reviewers' bandwidth, and I think
> this overlaps with how we can better front-load patch requirements,
> code style, testing, and access to CI.
>
> CI is an interesting one. CircleCI is for those (in a company) with a
> premium account. CI-cassandra for committers (reviewers). Often what a
> new contributor thinks is a simple patch won't pass CI, and it's a
> waste to have to rely on a reviewer getting involved to provide this
> feedback. I don't have any great answer to this. Though I am still
> keen to see a script that uses the jenkins k8s operator to set up our
> jenkins DSL on anyone's own k8s cluster and run the full pipeline. On
> a much simpler front, maybe hooking up GH actions to generate the
> documentation and website would help attract (and keep around) the doc
> and website contributors.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [DISCUSSION] Attracting new contributors

[Mick Semb Wever]

> Thanks for bringing this important topic for discussion Benjamin. I think
> it would help to enumerate what issues we face to attract new contributors
> currently and then try to act on those.
>
> 1. Committers have little bandwidth to review low-impact issues (ie. Low
> Hanging Fruit (LHF)), which are generally the entry-point for new
> contributors. Lack of feedback on these initial contributions discourage
> new contributions, creating a barrier for new contributors to join the
> community (this point was raised by Stefan on this thread[1]).
>
> 2. Lack of consistency when labeling tickets as LHF. Some tickets are easy
> but not tagged as LHF, some tickets are tagged as LHF but are not easy
> enough for new contributors.
>
> 3. Lack of consistency when filling JIRA tickets. Some tickets have a clear
> scope and definition, making it easier for new contributors to self serve
> and figure out what needs to be done, while others have bad descriptions or
> ill-defined scopes making it hard for beginners to work on these tickets.
>
> 4. Out of date or invalid JIRA tickets, making it harder for beginners to
> figure out if a given ticket is valid or not to work on.


I agree with this list Paulo. And I can see the hygiene of jira
tickets, individually and overall, being one of the key points that we
can immediately address (and you are!)

This article was recently shared with me and I think it is a good
starting point:
https://opensource.com/article/19/12/open-source-contributors

We do definitely have a blocker on reviewers' bandwidth, and I think
this overlaps with how we can better front-load patch requirements,
code style, testing, and access to CI.

CI is an interesting one. CircleCI is for those (in a company) with a
premium account. CI-cassandra for committers (reviewers). Often what a
new contributor thinks is a simple patch won't pass CI, and it's a
waste to have to rely on a reviewer getting involved to provide this
feedback. I don't have any great answer to this. Though I am still
keen to see a script that uses the jenkins k8s operator to set up our
jenkins DSL on anyone's own k8s cluster and run the full pipeline. On
a much simpler front, maybe hooking up GH actions to generate the
documentation and website would help attract (and keep around) the doc
and website contributors.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSSION] Attracting new contributors

[Patrick McFadin]

I have to admit, I like those Duke Nukem levels way more than I should. I
guess when you choose "Damn I'm Good" you get the boss fight to end all
boss fights. "Benedict has been assigned as a reviewer..." o.O

But seriously folks. :D

I would advocate for a simple tiering system.

Entry Level
Intermediate
Advanced

Clearly defined buckets which not only make it easier for the person
looking at the Jiras, it also makes it easier for whoever is creating or
triaging the issue. Also, 3 is a magic number.

Patrick

On Tue, Apr 27, 2021 at 10:16 AM Stefan Miklosovic <
stefan.mikloso...@instaclustr.com> wrote:

> Quake has it like
>
> - I Can Win
> - Bring It On
> - Hurt Me Plenty
> - Hardcore
> - Nightmare!
>
> On Tue, 27 Apr 2021 at 19:02, Benedict Elliott Smith
>  wrote:
> >
> > I think Duke Nuke'em would be more apt
> >
> > - Piece of Cake
> > - Let's Rock
> > - Come Get Some
> > - Damn I'm Good
> >
> > On 27/04/2021, 17:57, "Patrick McFadin"  wrote:
> >
> > Could always go with Doom difficulty levels:
> >
> >
> >- I'm Too Young to Die - Easy.
> >- Hurt Me Plenty - Normal.
> >- Ultra-Violence - Hard.
> >- Nightmare - Very Hard.
> >-
> >
> >
> > On Tue, Apr 27, 2021 at 9:50 AM Benedict Elliott Smith <
> bened...@apache.org>
> > wrote:
> >
> > > Perhaps we could replace both Complexity and Difficulty with e.g.
> > > Experience?
> > >
> > > Newcomer
> > > Learner
> > > Contributor
> > > Experienced
> > > Veteran
> > >
> > > I'm not sure I like it. I don't really like segregating the
> community into
> > > buckets like this. But it is perhaps more intuitive than
> complexity, while
> > > encoding a more objective concept of difficulty.
> > >
> > >
> > > On 27/04/2021, 17:33, "Paulo Motta" 
> wrote:
> > >
> > > I (wrongly) assumed this proposal would be fairly
> uncontroversial so I
> > > brought up within this related thread but given there is some
> > > divergence, I
> > > retract the suggestion for now and will bring it on its own
> thread
> > > later so
> > > we don't go too far away from the original, and more
> important, topic
> > > which
> > > is how to attract and retain new contributors to the project.
> > >
> > > Em ter., 27 de abr. de 2021 às 13:08, Benedict Elliott Smith <
> > > bened...@apache.org> escreveu:
> > >
> > > > What you are describing to me are difficulty levels, whereas
> this
> > > field
> > > > tries to measure complexity. The difference is that while
> both are
> > > > subjective, difficulty is relatively more so. This may lead
> people to
> > > > assign difficulty based on their own perception (which is
> very
> > > subjective),
> > > > rather than the scope of the problem (which is still
> subjective, but
> > > less
> > > > so).
> > > >
> > > > We can bike-shed the names or the definitions all we like,
> but we
> > > need
> > > > some separate text to elaborate the intended meaning, else
> we'll all
> > > mean
> > > > and encode different things.
> > > >
> > > > I also don't personally think Hard or Very Hard are
> descriptive. By
> > > > comparison, Byzantine is a word that not only crops up in
> distributed
> > > > systems to mean involving many parties (i.e. in this case
> many
> > > subsystems),
> > > > but is widely used in English to mean "intricately involved"
> with
> > > > connotations of labyrinthine, i.e. easy to get lost doing,
> or easy to
> > > > misunderstand.
> > > >
> > > > I'm definitely open to improving the terminology, but we did
> bike
> > > shed
> > > > this all only a year or so ago I think?
> > > >
> > > >
> > > >
> > > > On 27/04/2021, 16:20, "Paulo Motta" <
> pauloricard...@gmail.com>
> > > wrote:
> > > >
> > > > Thanks for bringing the definitions and historical
> context
> > > Benedict.
> > > > Agreed
> > > > to not attach difficulties to time to complete a task.
> > > >
> > > > The fact that the complexity types need explanation or
> reading
> > > > documentation is precisely the issue I’m trying to solve
> by
> > > using more
> > > > straightforward and unambiguous terms (as much as
> possible).
> > > >
> > > > So I propose the following levels instead.
> > > > - Beginner (current LHF for people who have never
> submitted a
> > > patch
> > > > (ie.
> > > > trivial doc changes or minor test fixes))
> > > > - Easy (current LHF for people who have submitted at
> least a
> > > couple of
> > > > patches (ie. add parameter to existing tool))
> > > > - 

Re: [DISCUSSION] Attracting new contributors

[Stefan Miklosovic]

Quake has it like

- I Can Win
- Bring It On
- Hurt Me Plenty
- Hardcore
- Nightmare!

On Tue, 27 Apr 2021 at 19:02, Benedict Elliott Smith
 wrote:
>
> I think Duke Nuke'em would be more apt
>
> - Piece of Cake
> - Let's Rock
> - Come Get Some
> - Damn I'm Good
>
> On 27/04/2021, 17:57, "Patrick McFadin"  wrote:
>
> Could always go with Doom difficulty levels:
>
>
>- I'm Too Young to Die - Easy.
>- Hurt Me Plenty - Normal.
>- Ultra-Violence - Hard.
>- Nightmare - Very Hard.
>-
>
>
> On Tue, Apr 27, 2021 at 9:50 AM Benedict Elliott Smith 
> 
> wrote:
>
> > Perhaps we could replace both Complexity and Difficulty with e.g.
> > Experience?
> >
> > Newcomer
> > Learner
> > Contributor
> > Experienced
> > Veteran
> >
> > I'm not sure I like it. I don't really like segregating the community 
> into
> > buckets like this. But it is perhaps more intuitive than complexity, 
> while
> > encoding a more objective concept of difficulty.
> >
> >
> > On 27/04/2021, 17:33, "Paulo Motta"  wrote:
> >
> > I (wrongly) assumed this proposal would be fairly uncontroversial 
> so I
> > brought up within this related thread but given there is some
> > divergence, I
> > retract the suggestion for now and will bring it on its own thread
> > later so
> > we don't go too far away from the original, and more important, 
> topic
> > which
> > is how to attract and retain new contributors to the project.
> >
> > Em ter., 27 de abr. de 2021 às 13:08, Benedict Elliott Smith <
> > bened...@apache.org> escreveu:
> >
> > > What you are describing to me are difficulty levels, whereas this
> > field
> > > tries to measure complexity. The difference is that while both are
> > > subjective, difficulty is relatively more so. This may lead 
> people to
> > > assign difficulty based on their own perception (which is very
> > subjective),
> > > rather than the scope of the problem (which is still subjective, 
> but
> > less
> > > so).
> > >
> > > We can bike-shed the names or the definitions all we like, but we
> > need
> > > some separate text to elaborate the intended meaning, else we'll 
> all
> > mean
> > > and encode different things.
> > >
> > > I also don't personally think Hard or Very Hard are descriptive. 
> By
> > > comparison, Byzantine is a word that not only crops up in 
> distributed
> > > systems to mean involving many parties (i.e. in this case many
> > subsystems),
> > > but is widely used in English to mean "intricately involved" with
> > > connotations of labyrinthine, i.e. easy to get lost doing, or 
> easy to
> > > misunderstand.
> > >
> > > I'm definitely open to improving the terminology, but we did bike
> > shed
> > > this all only a year or so ago I think?
> > >
> > >
> > >
> > > On 27/04/2021, 16:20, "Paulo Motta" 
> > wrote:
> > >
> > > Thanks for bringing the definitions and historical context
> > Benedict.
> > > Agreed
> > > to not attach difficulties to time to complete a task.
> > >
> > > The fact that the complexity types need explanation or reading
> > > documentation is precisely the issue I’m trying to solve by
> > using more
> > > straightforward and unambiguous terms (as much as possible).
> > >
> > > So I propose the following levels instead.
> > > - Beginner (current LHF for people who have never submitted a
> > patch
> > > (ie.
> > > trivial doc changes or minor test fixes))
> > > - Easy (current LHF for people who have submitted at least a
> > couple of
> > > patches (ie. add parameter to existing tool))
> > > - Intermediate (current normal)
> > > - Hard (current Challenging)
> > > - Very Hard (current Byzantine)
> > >
> > > Please let me know what you think.
> > >
> > > Em ter., 27 de abr. de 2021 às 11:44, Benedict Elliott Smith <
> > > bened...@apache.org> escreveu:
> > >
> > > > If you're wondering, they're documented:
> > > >
> > >
> > 
> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
> > > >
> > > > Impossible was introduced to take the place of "pony" - 
> which
> > was
> > > > genuinely deployed on occasion, but I agree it's redundant 
> as
> > nobody
> > > > proposes things like that anymore.
> > > >
> > > > Challenging and Byzantine are useful distinctions IMO, but 
> I'm
>   

Re: [DISCUSSION] Attracting new contributors

[Benedict Elliott Smith]

I think Duke Nuke'em would be more apt

- Piece of Cake
- Let's Rock
- Come Get Some
- Damn I'm Good

On 27/04/2021, 17:57, "Patrick McFadin"  wrote:

Could always go with Doom difficulty levels:


   - I'm Too Young to Die - Easy.
   - Hurt Me Plenty - Normal.
   - Ultra-Violence - Hard.
   - Nightmare - Very Hard.
   -


On Tue, Apr 27, 2021 at 9:50 AM Benedict Elliott Smith 
wrote:

> Perhaps we could replace both Complexity and Difficulty with e.g.
> Experience?
>
> Newcomer
> Learner
> Contributor
> Experienced
> Veteran
>
> I'm not sure I like it. I don't really like segregating the community into
> buckets like this. But it is perhaps more intuitive than complexity, while
> encoding a more objective concept of difficulty.
>
>
> On 27/04/2021, 17:33, "Paulo Motta"  wrote:
>
> I (wrongly) assumed this proposal would be fairly uncontroversial so I
> brought up within this related thread but given there is some
> divergence, I
> retract the suggestion for now and will bring it on its own thread
> later so
> we don't go too far away from the original, and more important, topic
> which
> is how to attract and retain new contributors to the project.
>
> Em ter., 27 de abr. de 2021 às 13:08, Benedict Elliott Smith <
> bened...@apache.org> escreveu:
>
> > What you are describing to me are difficulty levels, whereas this
> field
> > tries to measure complexity. The difference is that while both are
> > subjective, difficulty is relatively more so. This may lead people 
to
> > assign difficulty based on their own perception (which is very
> subjective),
> > rather than the scope of the problem (which is still subjective, but
> less
> > so).
> >
> > We can bike-shed the names or the definitions all we like, but we
> need
> > some separate text to elaborate the intended meaning, else we'll all
> mean
> > and encode different things.
> >
> > I also don't personally think Hard or Very Hard are descriptive. By
> > comparison, Byzantine is a word that not only crops up in 
distributed
> > systems to mean involving many parties (i.e. in this case many
> subsystems),
> > but is widely used in English to mean "intricately involved" with
> > connotations of labyrinthine, i.e. easy to get lost doing, or easy 
to
> > misunderstand.
> >
> > I'm definitely open to improving the terminology, but we did bike
> shed
> > this all only a year or so ago I think?
> >
> >
> >
> > On 27/04/2021, 16:20, "Paulo Motta" 
> wrote:
> >
> > Thanks for bringing the definitions and historical context
> Benedict.
> > Agreed
> > to not attach difficulties to time to complete a task.
> >
> > The fact that the complexity types need explanation or reading
> > documentation is precisely the issue I’m trying to solve by
> using more
> > straightforward and unambiguous terms (as much as possible).
> >
> > So I propose the following levels instead.
> > - Beginner (current LHF for people who have never submitted a
> patch
> > (ie.
> > trivial doc changes or minor test fixes))
> > - Easy (current LHF for people who have submitted at least a
> couple of
> > patches (ie. add parameter to existing tool))
> > - Intermediate (current normal)
> > - Hard (current Challenging)
> > - Very Hard (current Byzantine)
> >
> > Please let me know what you think.
> >
> > Em ter., 27 de abr. de 2021 às 11:44, Benedict Elliott Smith <
> > bened...@apache.org> escreveu:
> >
> > > If you're wondering, they're documented:
> > >
> >
> 
https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
> > >
> > > Impossible was introduced to take the place of "pony" - which
> was
> > > genuinely deployed on occasion, but I agree it's redundant as
> nobody
> > > proposes things like that anymore.
> > >
> > > Challenging and Byzantine are useful distinctions IMO, but I'm
> open
> > to
> > > relabelling them. Levels of difficulty do not cleanly map to
> time
> > involved,
> > > however.
> > >
> > > The project literally never used Easy in the past, but perhaps
> you
> > can
> > > bring about the necessary change to do so.
> > >
> > >
> > > On 27/04/2021, 15:32, 

Re: [DISCUSSION] Attracting new contributors

[Patrick McFadin]

Could always go with Doom difficulty levels:


   - I'm Too Young to Die - Easy.
   - Hurt Me Plenty - Normal.
   - Ultra-Violence - Hard.
   - Nightmare - Very Hard.
   -


On Tue, Apr 27, 2021 at 9:50 AM Benedict Elliott Smith 
wrote:

> Perhaps we could replace both Complexity and Difficulty with e.g.
> Experience?
>
> Newcomer
> Learner
> Contributor
> Experienced
> Veteran
>
> I'm not sure I like it. I don't really like segregating the community into
> buckets like this. But it is perhaps more intuitive than complexity, while
> encoding a more objective concept of difficulty.
>
>
> On 27/04/2021, 17:33, "Paulo Motta"  wrote:
>
> I (wrongly) assumed this proposal would be fairly uncontroversial so I
> brought up within this related thread but given there is some
> divergence, I
> retract the suggestion for now and will bring it on its own thread
> later so
> we don't go too far away from the original, and more important, topic
> which
> is how to attract and retain new contributors to the project.
>
> Em ter., 27 de abr. de 2021 às 13:08, Benedict Elliott Smith <
> bened...@apache.org> escreveu:
>
> > What you are describing to me are difficulty levels, whereas this
> field
> > tries to measure complexity. The difference is that while both are
> > subjective, difficulty is relatively more so. This may lead people to
> > assign difficulty based on their own perception (which is very
> subjective),
> > rather than the scope of the problem (which is still subjective, but
> less
> > so).
> >
> > We can bike-shed the names or the definitions all we like, but we
> need
> > some separate text to elaborate the intended meaning, else we'll all
> mean
> > and encode different things.
> >
> > I also don't personally think Hard or Very Hard are descriptive. By
> > comparison, Byzantine is a word that not only crops up in distributed
> > systems to mean involving many parties (i.e. in this case many
> subsystems),
> > but is widely used in English to mean "intricately involved" with
> > connotations of labyrinthine, i.e. easy to get lost doing, or easy to
> > misunderstand.
> >
> > I'm definitely open to improving the terminology, but we did bike
> shed
> > this all only a year or so ago I think?
> >
> >
> >
> > On 27/04/2021, 16:20, "Paulo Motta" 
> wrote:
> >
> > Thanks for bringing the definitions and historical context
> Benedict.
> > Agreed
> > to not attach difficulties to time to complete a task.
> >
> > The fact that the complexity types need explanation or reading
> > documentation is precisely the issue I’m trying to solve by
> using more
> > straightforward and unambiguous terms (as much as possible).
> >
> > So I propose the following levels instead.
> > - Beginner (current LHF for people who have never submitted a
> patch
> > (ie.
> > trivial doc changes or minor test fixes))
> > - Easy (current LHF for people who have submitted at least a
> couple of
> > patches (ie. add parameter to existing tool))
> > - Intermediate (current normal)
> > - Hard (current Challenging)
> > - Very Hard (current Byzantine)
> >
> > Please let me know what you think.
> >
> > Em ter., 27 de abr. de 2021 às 11:44, Benedict Elliott Smith <
> > bened...@apache.org> escreveu:
> >
> > > If you're wondering, they're documented:
> > >
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
> > >
> > > Impossible was introduced to take the place of "pony" - which
> was
> > > genuinely deployed on occasion, but I agree it's redundant as
> nobody
> > > proposes things like that anymore.
> > >
> > > Challenging and Byzantine are useful distinctions IMO, but I'm
> open
> > to
> > > relabelling them. Levels of difficulty do not cleanly map to
> time
> > involved,
> > > however.
> > >
> > > The project literally never used Easy in the past, but perhaps
> you
> > can
> > > bring about the necessary change to do so.
> > >
> > >
> > > On 27/04/2021, 15:32, "Paulo Motta"  >
> > wrote:
> > >
> > > Since this is a related topic, I'd like to open a small
> > parenthesis to
> > > throw out a proposal for improving the semantics of our
> JIRA
> > > "complexity"
> > > field, which currently has the following levels:
> > > * Low Hanging Fruit (overall easy tasks for new or existing
> > > contributors)
> > > * Normal (? this is the most misleading one since it
> currently
> > ranges
> > > from
> > > very simple tasks to nearly complex tasks)
> > > * Challenging
> > 

Re: [DISCUSSION] Attracting new contributors

[Benedict Elliott Smith]

Perhaps we could replace both Complexity and Difficulty with e.g. Experience?

Newcomer
Learner
Contributor
Experienced
Veteran

I'm not sure I like it. I don't really like segregating the community into 
buckets like this. But it is perhaps more intuitive than complexity, while 
encoding a more objective concept of difficulty.


On 27/04/2021, 17:33, "Paulo Motta"  wrote:

I (wrongly) assumed this proposal would be fairly uncontroversial so I
brought up within this related thread but given there is some divergence, I
retract the suggestion for now and will bring it on its own thread later so
we don't go too far away from the original, and more important, topic which
is how to attract and retain new contributors to the project.

Em ter., 27 de abr. de 2021 às 13:08, Benedict Elliott Smith <
bened...@apache.org> escreveu:

> What you are describing to me are difficulty levels, whereas this field
> tries to measure complexity. The difference is that while both are
> subjective, difficulty is relatively more so. This may lead people to
> assign difficulty based on their own perception (which is very 
subjective),
> rather than the scope of the problem (which is still subjective, but less
> so).
>
> We can bike-shed the names or the definitions all we like, but we need
> some separate text to elaborate the intended meaning, else we'll all mean
> and encode different things.
>
> I also don't personally think Hard or Very Hard are descriptive. By
> comparison, Byzantine is a word that not only crops up in distributed
> systems to mean involving many parties (i.e. in this case many 
subsystems),
> but is widely used in English to mean "intricately involved" with
> connotations of labyrinthine, i.e. easy to get lost doing, or easy to
> misunderstand.
>
> I'm definitely open to improving the terminology, but we did bike shed
> this all only a year or so ago I think?
>
>
>
> On 27/04/2021, 16:20, "Paulo Motta"  wrote:
>
> Thanks for bringing the definitions and historical context Benedict.
> Agreed
> to not attach difficulties to time to complete a task.
>
> The fact that the complexity types need explanation or reading
> documentation is precisely the issue I’m trying to solve by using more
> straightforward and unambiguous terms (as much as possible).
>
> So I propose the following levels instead.
> - Beginner (current LHF for people who have never submitted a patch
> (ie.
> trivial doc changes or minor test fixes))
> - Easy (current LHF for people who have submitted at least a couple of
> patches (ie. add parameter to existing tool))
> - Intermediate (current normal)
> - Hard (current Challenging)
> - Very Hard (current Byzantine)
>
> Please let me know what you think.
>
> Em ter., 27 de abr. de 2021 às 11:44, Benedict Elliott Smith <
> bened...@apache.org> escreveu:
>
> > If you're wondering, they're documented:
> >
> 
https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
> >
> > Impossible was introduced to take the place of "pony" - which was
> > genuinely deployed on occasion, but I agree it's redundant as nobody
> > proposes things like that anymore.
> >
> > Challenging and Byzantine are useful distinctions IMO, but I'm open
> to
> > relabelling them. Levels of difficulty do not cleanly map to time
> involved,
> > however.
> >
> > The project literally never used Easy in the past, but perhaps you
> can
> > bring about the necessary change to do so.
> >
> >
> > On 27/04/2021, 15:32, "Paulo Motta" 
> wrote:
> >
> > Since this is a related topic, I'd like to open a small
> parenthesis to
> > throw out a proposal for improving the semantics of our JIRA
> > "complexity"
> > field, which currently has the following levels:
> > * Low Hanging Fruit (overall easy tasks for new or existing
> > contributors)
> > * Normal (? this is the most misleading one since it currently
> ranges
> > from
> > very simple tasks to nearly complex tasks)
> > * Challenging
> > * Byzantine (the difference between challenging, byzantine and
> > impossible
> > tasks is blurry/unclear to me)
> > * Impossible (not clear to me what's the purpose of filling a
> task
> > that is
> > impossible to do? I think we can just close the ticket as 
invalid
> > during
> > triage without setting complexity.)
> >
> > I propose the following levels instead:
> > * 

Re: [DISCUSSION] Attracting new contributors

[Patrick McFadin]

Hi everyone. Jumping in because I love this topic. Thank you for starting
it, Benjamin.

The thread is about attracting new contributors, but the direction this has
taken seems to be more along the line of how to attract code contributors.
We list a lot of contributions that have nothing to do with code:
https://cassandra.apache.org/doc/latest/development/gettingstarted.html#initial-contributions
That being said, I think focusing on attracting more code contributors is
an awesome topic.

I've run a lot of code contributor boot camps and while I loved doing them,
they didn't really get the outcome we were looking for with actual
contributions. Most times it was engineers looking for the Marianas trench
deep dive into Cassandra. Looking back, I feel they were overly broad and
mostly overwhelming for someone new. After the second hour of compaction
topics, many started questioning life choices.

The established path for OSS projects to nurture new contributors is the
"well-lighted path" All the discussion about better Jira tags is 100%
required in that case. Those types of activities lower the barrier for
anyone self-starting.

A few different ideas I have based on prior experience:
 - 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.

 - Sponsor a code bounty program: Designate some Jiras for a bounty. Maybe
things that have been lingering too long that haven't been prioritized?
Again with this, having mentors available. There are a lot of methods of
accomplishing something like this but what do you think of the concept?

 - Expand the tent and find ways of acknowledging ecosystem contributors.
As a project, we acknowledge people contributing code that is committed to
Cassandra but I think in 2021, the ecosystem counts almost as much.
Building a plugin for a streaming tool or and IDE integration. Those are
all very important for the Cassandra project as they make it easier to use
everywhere. I feel strongly we need to have a way to recognize those
contributions.

Great discussion!
Patrick

On Tue, Apr 27, 2021 at 7:45 AM Benedict Elliott Smith 
wrote:

> If you're wondering, they're documented:
> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
>
> Impossible was introduced to take the place of "pony" - which was
> genuinely deployed on occasion, but I agree it's redundant as nobody
> proposes things like that anymore.
>
> Challenging and Byzantine are useful distinctions IMO, but I'm open to
> relabelling them. Levels of difficulty do not cleanly map to time involved,
> however.
>
> The project literally never used Easy in the past, but perhaps you can
> bring about the necessary change to do so.
>
>
> On 27/04/2021, 15:32, "Paulo Motta"  wrote:
>
> Since this is a related topic, I'd like to open a small parenthesis to
> throw out a proposal for improving the semantics of our JIRA
> "complexity"
> field, which currently has the following levels:
> * Low Hanging Fruit (overall easy tasks for new or existing
> contributors)
> * Normal (? this is the most misleading one since it currently ranges
> from
> very simple tasks to nearly complex tasks)
> * Challenging
> * Byzantine (the difference between challenging, byzantine and
> impossible
> tasks is blurry/unclear to me)
> * Impossible (not clear to me what's the purpose of filling a task
> that is
> impossible to do? I think we can just close the ticket as invalid
> during
> triage without setting complexity.)
>
> I propose the following levels instead:
> * Low Hanging Fruit (I think we should even rename this to "Beginner",
> since the LHF term is not very well known by outsiders and non-native
> English speakers) : easy tasks for who never contributed to the
> project.
> * Easy : easy tasks for those who have some basic familiarity with the
> project (contributed at least 2-5 LHF).
> * Intermediate : tasks with intermediate complexity, can be done in
> under a
> month.
> * Challenging : multi-month effort task.
> (no need for byzantine and impossible complexity levels since they
> don't
> add any value)
>
> If you prefer I can open a new thread with this proposal so we can
> focus on
> initiatives to attract contributors - but I think having clear
> guidelines
> on the meaning of task's complexities will help to better delineate
> what
> tasks are suitable for new contributors.
>
> Em ter., 27 de abr. de 2021 às 11:25, Joshua McKenzie <
> jmcken...@apache.org>
> escreveu:
>
> > Updating the boot camp material for 

Re: [DISCUSSION] Attracting new contributors

[Paulo Motta]

I (wrongly) assumed this proposal would be fairly uncontroversial so I
brought up within this related thread but given there is some divergence, I
retract the suggestion for now and will bring it on its own thread later so
we don't go too far away from the original, and more important, topic which
is how to attract and retain new contributors to the project.

Em ter., 27 de abr. de 2021 às 13:08, Benedict Elliott Smith <
bened...@apache.org> escreveu:

> What you are describing to me are difficulty levels, whereas this field
> tries to measure complexity. The difference is that while both are
> subjective, difficulty is relatively more so. This may lead people to
> assign difficulty based on their own perception (which is very subjective),
> rather than the scope of the problem (which is still subjective, but less
> so).
>
> We can bike-shed the names or the definitions all we like, but we need
> some separate text to elaborate the intended meaning, else we'll all mean
> and encode different things.
>
> I also don't personally think Hard or Very Hard are descriptive. By
> comparison, Byzantine is a word that not only crops up in distributed
> systems to mean involving many parties (i.e. in this case many subsystems),
> but is widely used in English to mean "intricately involved" with
> connotations of labyrinthine, i.e. easy to get lost doing, or easy to
> misunderstand.
>
> I'm definitely open to improving the terminology, but we did bike shed
> this all only a year or so ago I think?
>
>
>
> On 27/04/2021, 16:20, "Paulo Motta"  wrote:
>
> Thanks for bringing the definitions and historical context Benedict.
> Agreed
> to not attach difficulties to time to complete a task.
>
> The fact that the complexity types need explanation or reading
> documentation is precisely the issue I’m trying to solve by using more
> straightforward and unambiguous terms (as much as possible).
>
> So I propose the following levels instead.
> - Beginner (current LHF for people who have never submitted a patch
> (ie.
> trivial doc changes or minor test fixes))
> - Easy (current LHF for people who have submitted at least a couple of
> patches (ie. add parameter to existing tool))
> - Intermediate (current normal)
> - Hard (current Challenging)
> - Very Hard (current Byzantine)
>
> Please let me know what you think.
>
> Em ter., 27 de abr. de 2021 às 11:44, Benedict Elliott Smith <
> bened...@apache.org> escreveu:
>
> > If you're wondering, they're documented:
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
> >
> > Impossible was introduced to take the place of "pony" - which was
> > genuinely deployed on occasion, but I agree it's redundant as nobody
> > proposes things like that anymore.
> >
> > Challenging and Byzantine are useful distinctions IMO, but I'm open
> to
> > relabelling them. Levels of difficulty do not cleanly map to time
> involved,
> > however.
> >
> > The project literally never used Easy in the past, but perhaps you
> can
> > bring about the necessary change to do so.
> >
> >
> > On 27/04/2021, 15:32, "Paulo Motta" 
> wrote:
> >
> > Since this is a related topic, I'd like to open a small
> parenthesis to
> > throw out a proposal for improving the semantics of our JIRA
> > "complexity"
> > field, which currently has the following levels:
> > * Low Hanging Fruit (overall easy tasks for new or existing
> > contributors)
> > * Normal (? this is the most misleading one since it currently
> ranges
> > from
> > very simple tasks to nearly complex tasks)
> > * Challenging
> > * Byzantine (the difference between challenging, byzantine and
> > impossible
> > tasks is blurry/unclear to me)
> > * Impossible (not clear to me what's the purpose of filling a
> task
> > that is
> > impossible to do? I think we can just close the ticket as invalid
> > during
> > triage without setting complexity.)
> >
> > I propose the following levels instead:
> > * Low Hanging Fruit (I think we should even rename this to
> "Beginner",
> > since the LHF term is not very well known by outsiders and
> non-native
> > English speakers) : easy tasks for who never contributed to the
> > project.
> > * Easy : easy tasks for those who have some basic familiarity
> with the
> > project (contributed at least 2-5 LHF).
> > * Intermediate : tasks with intermediate complexity, can be done
> in
> > under a
> > month.
> > * Challenging : multi-month effort task.
> > (no need for byzantine and impossible complexity levels since
> they
> > don't
> > add any value)
> >
> > If you prefer I can open a new thread with this proposal so we
> can
> > focus on
> 

Re: [DISCUSSION] Attracting new contributors

[Benedict Elliott Smith]

What you are describing to me are difficulty levels, whereas this field tries 
to measure complexity. The difference is that while both are subjective, 
difficulty is relatively more so. This may lead people to assign difficulty 
based on their own perception (which is very subjective), rather than the scope 
of the problem (which is still subjective, but less so).

We can bike-shed the names or the definitions all we like, but we need some 
separate text to elaborate the intended meaning, else we'll all mean and encode 
different things. 

I also don't personally think Hard or Very Hard are descriptive. By comparison, 
Byzantine is a word that not only crops up in distributed systems to mean 
involving many parties (i.e. in this case many subsystems), but is widely used 
in English to mean "intricately involved" with connotations of labyrinthine, 
i.e. easy to get lost doing, or easy to misunderstand.

I'm definitely open to improving the terminology, but we did bike shed this all 
only a year or so ago I think?



On 27/04/2021, 16:20, "Paulo Motta"  wrote:

Thanks for bringing the definitions and historical context Benedict. Agreed
to not attach difficulties to time to complete a task.

The fact that the complexity types need explanation or reading
documentation is precisely the issue I’m trying to solve by using more
straightforward and unambiguous terms (as much as possible).

So I propose the following levels instead.
- Beginner (current LHF for people who have never submitted a patch (ie.
trivial doc changes or minor test fixes))
- Easy (current LHF for people who have submitted at least a couple of
patches (ie. add parameter to existing tool))
- Intermediate (current normal)
- Hard (current Challenging)
- Very Hard (current Byzantine)

Please let me know what you think.

Em ter., 27 de abr. de 2021 às 11:44, Benedict Elliott Smith <
bened...@apache.org> escreveu:

> If you're wondering, they're documented:
> 
https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
>
> Impossible was introduced to take the place of "pony" - which was
> genuinely deployed on occasion, but I agree it's redundant as nobody
> proposes things like that anymore.
>
> Challenging and Byzantine are useful distinctions IMO, but I'm open to
> relabelling them. Levels of difficulty do not cleanly map to time 
involved,
> however.
>
> The project literally never used Easy in the past, but perhaps you can
> bring about the necessary change to do so.
>
>
> On 27/04/2021, 15:32, "Paulo Motta"  wrote:
>
> Since this is a related topic, I'd like to open a small parenthesis to
> throw out a proposal for improving the semantics of our JIRA
> "complexity"
> field, which currently has the following levels:
> * Low Hanging Fruit (overall easy tasks for new or existing
> contributors)
> * Normal (? this is the most misleading one since it currently ranges
> from
> very simple tasks to nearly complex tasks)
> * Challenging
> * Byzantine (the difference between challenging, byzantine and
> impossible
> tasks is blurry/unclear to me)
> * Impossible (not clear to me what's the purpose of filling a task
> that is
> impossible to do? I think we can just close the ticket as invalid
> during
> triage without setting complexity.)
>
> I propose the following levels instead:
> * Low Hanging Fruit (I think we should even rename this to "Beginner",
> since the LHF term is not very well known by outsiders and non-native
> English speakers) : easy tasks for who never contributed to the
> project.
> * Easy : easy tasks for those who have some basic familiarity with the
> project (contributed at least 2-5 LHF).
> * Intermediate : tasks with intermediate complexity, can be done in
> under a
> month.
> * Challenging : multi-month effort task.
> (no need for byzantine and impossible complexity levels since they
> don't
> add any value)
>
> If you prefer I can open a new thread with this proposal so we can
> focus on
> initiatives to attract contributors - but I think having clear
> guidelines
> on the meaning of task's complexities will help to better delineate
> what
> tasks are suitable for new contributors.
>
> Em ter., 27 de abr. de 2021 às 11:25, Joshua McKenzie <
> jmcken...@apache.org>
> escreveu:
>
> > Updating the boot camp material for 4.0 and having it integrated in
> with
> > the official docs (
> https://cassandra.apache.org/doc/latest/development/)
> > would likely be a valuable, if expensive, exercise.
> >
> > Think this is the slideshare link from 

Re: [DISCUSSION] Attracting new contributors

[Paulo Motta]

Thanks for bringing the definitions and historical context Benedict. Agreed
to not attach difficulties to time to complete a task.

The fact that the complexity types need explanation or reading
documentation is precisely the issue I’m trying to solve by using more
straightforward and unambiguous terms (as much as possible).

So I propose the following levels instead.
- Beginner (current LHF for people who have never submitted a patch (ie.
trivial doc changes or minor test fixes))
- Easy (current LHF for people who have submitted at least a couple of
patches (ie. add parameter to existing tool))
- Intermediate (current normal)
- Hard (current Challenging)
- Very Hard (current Byzantine)

Please let me know what you think.

Em ter., 27 de abr. de 2021 às 11:44, Benedict Elliott Smith <
bened...@apache.org> escreveu:

> If you're wondering, they're documented:
> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
>
> Impossible was introduced to take the place of "pony" - which was
> genuinely deployed on occasion, but I agree it's redundant as nobody
> proposes things like that anymore.
>
> Challenging and Byzantine are useful distinctions IMO, but I'm open to
> relabelling them. Levels of difficulty do not cleanly map to time involved,
> however.
>
> The project literally never used Easy in the past, but perhaps you can
> bring about the necessary change to do so.
>
>
> On 27/04/2021, 15:32, "Paulo Motta"  wrote:
>
> Since this is a related topic, I'd like to open a small parenthesis to
> throw out a proposal for improving the semantics of our JIRA
> "complexity"
> field, which currently has the following levels:
> * Low Hanging Fruit (overall easy tasks for new or existing
> contributors)
> * Normal (? this is the most misleading one since it currently ranges
> from
> very simple tasks to nearly complex tasks)
> * Challenging
> * Byzantine (the difference between challenging, byzantine and
> impossible
> tasks is blurry/unclear to me)
> * Impossible (not clear to me what's the purpose of filling a task
> that is
> impossible to do? I think we can just close the ticket as invalid
> during
> triage without setting complexity.)
>
> I propose the following levels instead:
> * Low Hanging Fruit (I think we should even rename this to "Beginner",
> since the LHF term is not very well known by outsiders and non-native
> English speakers) : easy tasks for who never contributed to the
> project.
> * Easy : easy tasks for those who have some basic familiarity with the
> project (contributed at least 2-5 LHF).
> * Intermediate : tasks with intermediate complexity, can be done in
> under a
> month.
> * Challenging : multi-month effort task.
> (no need for byzantine and impossible complexity levels since they
> don't
> add any value)
>
> If you prefer I can open a new thread with this proposal so we can
> focus on
> initiatives to attract contributors - but I think having clear
> guidelines
> on the meaning of task's complexities will help to better delineate
> what
> tasks are suitable for new contributors.
>
> Em ter., 27 de abr. de 2021 às 11:25, Joshua McKenzie <
> jmcken...@apache.org>
> escreveu:
>
> > Updating the boot camp material for 4.0 and having it integrated in
> with
> > the official docs (
> https://cassandra.apache.org/doc/latest/development/)
> > would likely be a valuable, if expensive, exercise.
> >
> > Think this is the slideshare link from the 2014 boot camp; could
> build off
> > this as the bones are still the same.
> > https://www.slideshare.net/joshmckenzie/
> >
> > On Tue, Apr 27, 2021 at 10:08 AM Paulo Motta <
> pauloricard...@gmail.com>
> > wrote:
> >
> > > Bootcamp is a great effort, but I think in terms of priority
> ensuring
> > that
> > > LHF tickets are properly described (well scoped, good ticket
> description
> > > etc) and given proper attention and mentorship to ensure it goes
> through
> > > the finish line is a great first step and will significantly
> reduce the
> > > barrier to contribution. Once we have this initial pipeline working
> > > smoothly, I think promoting a bootcamp would be a great second
> step,
> > since
> > > the bootcamp can be much more efficient if the participants have
> already
> > > some basic level of familiarity with the project and can start
> working
> > on a
> > > bit more involved tasks ("Easy" complexity) tasks.
> > >
> > > Em ter., 27 de abr. de 2021 às 10:50, Benjamin Lerer <
> b.le...@gmail.com>
> > > escreveu:
> > >
> > > > >
> > > > > It really boils down just to a simple "problem" to have enough
> > > > > committers to look at it over a (preferably) shorter period of
> time
> > > > > and make that feedback loop shorter.
> > > > >
> > > >
> > > > The review delay is a 

Re: [DISCUSSION] Attracting new contributors

[Benedict Elliott Smith]

If you're wondering, they're documented: 
https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals

Impossible was introduced to take the place of "pony" - which was genuinely 
deployed on occasion, but I agree it's redundant as nobody proposes things like 
that anymore.

Challenging and Byzantine are useful distinctions IMO, but I'm open to 
relabelling them. Levels of difficulty do not cleanly map to time involved, 
however.

The project literally never used Easy in the past, but perhaps you can bring 
about the necessary change to do so.


On 27/04/2021, 15:32, "Paulo Motta"  wrote:

Since this is a related topic, I'd like to open a small parenthesis to
throw out a proposal for improving the semantics of our JIRA "complexity"
field, which currently has the following levels:
* Low Hanging Fruit (overall easy tasks for new or existing contributors)
* Normal (? this is the most misleading one since it currently ranges from
very simple tasks to nearly complex tasks)
* Challenging
* Byzantine (the difference between challenging, byzantine and impossible
tasks is blurry/unclear to me)
* Impossible (not clear to me what's the purpose of filling a task that is
impossible to do? I think we can just close the ticket as invalid during
triage without setting complexity.)

I propose the following levels instead:
* Low Hanging Fruit (I think we should even rename this to "Beginner",
since the LHF term is not very well known by outsiders and non-native
English speakers) : easy tasks for who never contributed to the project.
* Easy : easy tasks for those who have some basic familiarity with the
project (contributed at least 2-5 LHF).
* Intermediate : tasks with intermediate complexity, can be done in under a
month.
* Challenging : multi-month effort task.
(no need for byzantine and impossible complexity levels since they don't
add any value)

If you prefer I can open a new thread with this proposal so we can focus on
initiatives to attract contributors - but I think having clear guidelines
on the meaning of task's complexities will help to better delineate what
tasks are suitable for new contributors.

Em ter., 27 de abr. de 2021 às 11:25, Joshua McKenzie 
escreveu:

> Updating the boot camp material for 4.0 and having it integrated in with
> the official docs (https://cassandra.apache.org/doc/latest/development/)
> would likely be a valuable, if expensive, exercise.
>
> Think this is the slideshare link from the 2014 boot camp; could build off
> this as the bones are still the same.
> https://www.slideshare.net/joshmckenzie/
>
> On Tue, Apr 27, 2021 at 10:08 AM Paulo Motta 
> wrote:
>
> > Bootcamp is a great effort, but I think in terms of priority ensuring
> that
> > LHF tickets are properly described (well scoped, good ticket description
> > etc) and given proper attention and mentorship to ensure it goes through
> > the finish line is a great first step and will significantly reduce the
> > barrier to contribution. Once we have this initial pipeline working
> > smoothly, I think promoting a bootcamp would be a great second step,
> since
> > the bootcamp can be much more efficient if the participants have already
> > some basic level of familiarity with the project and can start working
> on a
> > bit more involved tasks ("Easy" complexity) tasks.
> >
> > Em ter., 27 de abr. de 2021 às 10:50, Benjamin Lerer 
> > escreveu:
> >
> > > >
> > > > It really boils down just to a simple "problem" to have enough
> > > > committers to look at it over a (preferably) shorter period of time
> > > > and make that feedback loop shorter.
> > > >
> > >
> > > The review delay is a clear issue. A part of the problem is that most
> > > committers are pretty busy (or that there are not enough committers,
> > > depending how you look at it) but another part of the problem is that
> we
> > do
> > > not have a good visibility on what is currently going on with new
> > > contributors. By having a clear view of which newcomers' tickets are
> > stuck
> > > we could also act in a more efficient way. We are currently doing some
> > > experimentations with Berenguer to have a way of tracking those 
things.
> > >
> > > Once 4.0 is out of the door, I believe that some of us should also
> have a
> > > bit more time to help out with newcomers' reviews/mentoring.
> > >
> > > +1, I had a few minor patches before but the bootcamp definitely 
helped
> > me
> > > > ramp up on the project faster and I found the recorded material very
> > > useful
> > > > during project onboarding (some of it is still available on 
Youtube).
> > > >
> > >
> > > People have different levels of experience and they will 

Re: [DISCUSSION] Attracting new contributors

[Brandon Williams]

On Tue, Apr 27, 2021 at 9:32 AM Paulo Motta  wrote:
>
> I propose the following levels instead:
> * Low Hanging Fruit (I think we should even rename this to "Beginner",
> since the LHF term is not very well known by outsiders and non-native
> English speakers) : easy tasks for who never contributed to the project.
> * Easy : easy tasks for those who have some basic familiarity with the
> project (contributed at least 2-5 LHF).
> * Intermediate : tasks with intermediate complexity, can be done in under a
> month.
> * Challenging : multi-month effort task.
> (no need for byzantine and impossible complexity levels since they don't
> add any value)

I find these levels more useful, +1 and thanks.  I only take small
issue with delineating tasks based on time to accomplish them, there
are certainly challenging tasks that don't take multiple months, and
there are easy/intermediate but time consuming tasks as well.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSSION] Attracting new contributors

[Paulo Motta]

Since this is a related topic, I'd like to open a small parenthesis to
throw out a proposal for improving the semantics of our JIRA "complexity"
field, which currently has the following levels:
* Low Hanging Fruit (overall easy tasks for new or existing contributors)
* Normal (? this is the most misleading one since it currently ranges from
very simple tasks to nearly complex tasks)
* Challenging
* Byzantine (the difference between challenging, byzantine and impossible
tasks is blurry/unclear to me)
* Impossible (not clear to me what's the purpose of filling a task that is
impossible to do? I think we can just close the ticket as invalid during
triage without setting complexity.)

I propose the following levels instead:
* Low Hanging Fruit (I think we should even rename this to "Beginner",
since the LHF term is not very well known by outsiders and non-native
English speakers) : easy tasks for who never contributed to the project.
* Easy : easy tasks for those who have some basic familiarity with the
project (contributed at least 2-5 LHF).
* Intermediate : tasks with intermediate complexity, can be done in under a
month.
* Challenging : multi-month effort task.
(no need for byzantine and impossible complexity levels since they don't
add any value)

If you prefer I can open a new thread with this proposal so we can focus on
initiatives to attract contributors - but I think having clear guidelines
on the meaning of task's complexities will help to better delineate what
tasks are suitable for new contributors.

Em ter., 27 de abr. de 2021 às 11:25, Joshua McKenzie 
escreveu:

> Updating the boot camp material for 4.0 and having it integrated in with
> the official docs (https://cassandra.apache.org/doc/latest/development/)
> would likely be a valuable, if expensive, exercise.
>
> Think this is the slideshare link from the 2014 boot camp; could build off
> this as the bones are still the same.
> https://www.slideshare.net/joshmckenzie/
>
> On Tue, Apr 27, 2021 at 10:08 AM Paulo Motta 
> wrote:
>
> > Bootcamp is a great effort, but I think in terms of priority ensuring
> that
> > LHF tickets are properly described (well scoped, good ticket description
> > etc) and given proper attention and mentorship to ensure it goes through
> > the finish line is a great first step and will significantly reduce the
> > barrier to contribution. Once we have this initial pipeline working
> > smoothly, I think promoting a bootcamp would be a great second step,
> since
> > the bootcamp can be much more efficient if the participants have already
> > some basic level of familiarity with the project and can start working
> on a
> > bit more involved tasks ("Easy" complexity) tasks.
> >
> > Em ter., 27 de abr. de 2021 às 10:50, Benjamin Lerer 
> > escreveu:
> >
> > > >
> > > > It really boils down just to a simple "problem" to have enough
> > > > committers to look at it over a (preferably) shorter period of time
> > > > and make that feedback loop shorter.
> > > >
> > >
> > > The review delay is a clear issue. A part of the problem is that most
> > > committers are pretty busy (or that there are not enough committers,
> > > depending how you look at it) but another part of the problem is that
> we
> > do
> > > not have a good visibility on what is currently going on with new
> > > contributors. By having a clear view of which newcomers' tickets are
> > stuck
> > > we could also act in a more efficient way. We are currently doing some
> > > experimentations with Berenguer to have a way of tracking those things.
> > >
> > > Once 4.0 is out of the door, I believe that some of us should also
> have a
> > > bit more time to help out with newcomers' reviews/mentoring.
> > >
> > > +1, I had a few minor patches before but the bootcamp definitely helped
> > me
> > > > ramp up on the project faster and I found the recorded material very
> > > useful
> > > > during project onboarding (some of it is still available on Youtube).
> > > >
> > >
> > > People have different levels of experience and they will probably
> > approach
> > > the project in a different way but if a bootcamp can help to have
> another
> > > Paulo, I am willing to do it. ;-)
> > > Of course in this pandemic world the best we can probably offer for the
> > > moment is some virtual bootcamp.
> > >
> > > Le mar. 27 avr. 2021 à 15:34, Paulo Motta  a
> > > écrit :
> > >
> > > > +1, I had a few minor patches before but the bootcamp definitely
> helped
> > > me
> > > > ramp up on the project faster and I found the recorded material very
> > > useful
> > > > during project onboarding (some of it is still available on Youtube).
> > > >
> > > > I think it would be beneficial to collocate a bootcamp for new
> > > contributors
> > > > together with an annual event such as NGCC or Apachecon/Cassandra
> > Summit
> > > > and also record some of the sessions so they're available for a wider
> > > > audience after the fact.
> > > >
> > > > Em ter., 27 de abr. de 2021 às 10:20, Jeremy Hanna 

Re: [DISCUSSION] Attracting new contributors

[Joshua McKenzie]

Updating the boot camp material for 4.0 and having it integrated in with
the official docs (https://cassandra.apache.org/doc/latest/development/)
would likely be a valuable, if expensive, exercise.

Think this is the slideshare link from the 2014 boot camp; could build off
this as the bones are still the same.
https://www.slideshare.net/joshmckenzie/

On Tue, Apr 27, 2021 at 10:08 AM Paulo Motta 
wrote:

> Bootcamp is a great effort, but I think in terms of priority ensuring that
> LHF tickets are properly described (well scoped, good ticket description
> etc) and given proper attention and mentorship to ensure it goes through
> the finish line is a great first step and will significantly reduce the
> barrier to contribution. Once we have this initial pipeline working
> smoothly, I think promoting a bootcamp would be a great second step, since
> the bootcamp can be much more efficient if the participants have already
> some basic level of familiarity with the project and can start working on a
> bit more involved tasks ("Easy" complexity) tasks.
>
> Em ter., 27 de abr. de 2021 às 10:50, Benjamin Lerer 
> escreveu:
>
> > >
> > > It really boils down just to a simple "problem" to have enough
> > > committers to look at it over a (preferably) shorter period of time
> > > and make that feedback loop shorter.
> > >
> >
> > The review delay is a clear issue. A part of the problem is that most
> > committers are pretty busy (or that there are not enough committers,
> > depending how you look at it) but another part of the problem is that we
> do
> > not have a good visibility on what is currently going on with new
> > contributors. By having a clear view of which newcomers' tickets are
> stuck
> > we could also act in a more efficient way. We are currently doing some
> > experimentations with Berenguer to have a way of tracking those things.
> >
> > Once 4.0 is out of the door, I believe that some of us should also have a
> > bit more time to help out with newcomers' reviews/mentoring.
> >
> > +1, I had a few minor patches before but the bootcamp definitely helped
> me
> > > ramp up on the project faster and I found the recorded material very
> > useful
> > > during project onboarding (some of it is still available on Youtube).
> > >
> >
> > People have different levels of experience and they will probably
> approach
> > the project in a different way but if a bootcamp can help to have another
> > Paulo, I am willing to do it. ;-)
> > Of course in this pandemic world the best we can probably offer for the
> > moment is some virtual bootcamp.
> >
> > Le mar. 27 avr. 2021 à 15:34, Paulo Motta  a
> > écrit :
> >
> > > +1, I had a few minor patches before but the bootcamp definitely helped
> > me
> > > ramp up on the project faster and I found the recorded material very
> > useful
> > > during project onboarding (some of it is still available on Youtube).
> > >
> > > I think it would be beneficial to collocate a bootcamp for new
> > contributors
> > > together with an annual event such as NGCC or Apachecon/Cassandra
> Summit
> > > and also record some of the sessions so they're available for a wider
> > > audience after the fact.
> > >
> > > Em ter., 27 de abr. de 2021 às 10:20, Jeremy Hanna <
> > > jeremy.hanna1...@gmail.com> escreveu:
> > >
> > > > I believe Paolo started with the project through a contributor boot
> > camp.
> > > > Also if I remember correctly some of the ones that were done were
> > > internal
> > > > at DataStax and it helped some people get familiar with the project
> who
> > > > still contribute today.
> > > >
> > > > Also this would be short recorded introductions so they could be
> around
> > > > for viewing and with auto translate on Google for different languages
> > > such
> > > > as Japanese and Mandarin.
> > > >
> > > > I do like the idea of a periodic chat. I just thought some recorded
> > > > introductions would help with some of the more common things like
> “this
> > > is
> > > > how the read path works from end to end”.
> > > >
> > > > > On Apr 27, 2021, at 10:14 PM, Benedict Elliott Smith <
> > > > bened...@apache.org> wrote:
> > > > >
> > > > > I think that all of the bootcamps we ran in the past produced
> > > precisely
> > > > zero new contributors.
> > > > >
> > > > > I wonder if it would be more impactful to produce slightly more
> > > > permanent content, such as step-by-step guides to producing a simple
> > > patch
> > > > for some subsystem. Perhaps if people want to, a recording could be
> > > created
> > > > of going through that guide as well.
> > > > >
> > > > > That said, if there are new contributors actively trying to
> > > participate,
> > > > organising a periodic group chat to talk through one of the issues
> that
> > > > they may be working on together as a group with an active contributor
> > > might
> > > > make sense, and be more targeted in focus?
> > > > >
> > > > >
> > > > > On 27/04/2021, 12:45, "Manish G" 
> > > wrote:
> > > > >
> > > > >

Re: [DISCUSSION] Attracting new contributors

[Paulo Motta]

Bootcamp is a great effort, but I think in terms of priority ensuring that
LHF tickets are properly described (well scoped, good ticket description
etc) and given proper attention and mentorship to ensure it goes through
the finish line is a great first step and will significantly reduce the
barrier to contribution. Once we have this initial pipeline working
smoothly, I think promoting a bootcamp would be a great second step, since
the bootcamp can be much more efficient if the participants have already
some basic level of familiarity with the project and can start working on a
bit more involved tasks ("Easy" complexity) tasks.

Em ter., 27 de abr. de 2021 às 10:50, Benjamin Lerer 
escreveu:

> >
> > It really boils down just to a simple "problem" to have enough
> > committers to look at it over a (preferably) shorter period of time
> > and make that feedback loop shorter.
> >
>
> The review delay is a clear issue. A part of the problem is that most
> committers are pretty busy (or that there are not enough committers,
> depending how you look at it) but another part of the problem is that we do
> not have a good visibility on what is currently going on with new
> contributors. By having a clear view of which newcomers' tickets are stuck
> we could also act in a more efficient way. We are currently doing some
> experimentations with Berenguer to have a way of tracking those things.
>
> Once 4.0 is out of the door, I believe that some of us should also have a
> bit more time to help out with newcomers' reviews/mentoring.
>
> +1, I had a few minor patches before but the bootcamp definitely helped me
> > ramp up on the project faster and I found the recorded material very
> useful
> > during project onboarding (some of it is still available on Youtube).
> >
>
> People have different levels of experience and they will probably approach
> the project in a different way but if a bootcamp can help to have another
> Paulo, I am willing to do it. ;-)
> Of course in this pandemic world the best we can probably offer for the
> moment is some virtual bootcamp.
>
> Le mar. 27 avr. 2021 à 15:34, Paulo Motta  a
> écrit :
>
> > +1, I had a few minor patches before but the bootcamp definitely helped
> me
> > ramp up on the project faster and I found the recorded material very
> useful
> > during project onboarding (some of it is still available on Youtube).
> >
> > I think it would be beneficial to collocate a bootcamp for new
> contributors
> > together with an annual event such as NGCC or Apachecon/Cassandra Summit
> > and also record some of the sessions so they're available for a wider
> > audience after the fact.
> >
> > Em ter., 27 de abr. de 2021 às 10:20, Jeremy Hanna <
> > jeremy.hanna1...@gmail.com> escreveu:
> >
> > > I believe Paolo started with the project through a contributor boot
> camp.
> > > Also if I remember correctly some of the ones that were done were
> > internal
> > > at DataStax and it helped some people get familiar with the project who
> > > still contribute today.
> > >
> > > Also this would be short recorded introductions so they could be around
> > > for viewing and with auto translate on Google for different languages
> > such
> > > as Japanese and Mandarin.
> > >
> > > I do like the idea of a periodic chat. I just thought some recorded
> > > introductions would help with some of the more common things like “this
> > is
> > > how the read path works from end to end”.
> > >
> > > > On Apr 27, 2021, at 10:14 PM, Benedict Elliott Smith <
> > > bened...@apache.org> wrote:
> > > >
> > > > I think that all of the bootcamps we ran in the past produced
> > precisely
> > > zero new contributors.
> > > >
> > > > I wonder if it would be more impactful to produce slightly more
> > > permanent content, such as step-by-step guides to producing a simple
> > patch
> > > for some subsystem. Perhaps if people want to, a recording could be
> > created
> > > of going through that guide as well.
> > > >
> > > > That said, if there are new contributors actively trying to
> > participate,
> > > organising a periodic group chat to talk through one of the issues that
> > > they may be working on together as a group with an active contributor
> > might
> > > make sense, and be more targeted in focus?
> > > >
> > > >
> > > > On 27/04/2021, 12:45, "Manish G" 
> > wrote:
> > > >
> > > >Contributor bootcamps can really help new people like me.
> > > >
> > > >>On Tue, Apr 27, 2021, 5:08 PM Jeremy Hanna <
> > > jeremy.hanna1...@gmail.com>
> > > >>wrote:
> > > >>
> > > >> One thing we've done in the past is contributor bootcamps along with
> > the
> > > >> the new contributor guide and the LHF complexity tickets.
> > > Unfortunately, I
> > > >> don't know that the contributor bootcamps were ever recorded.
> > > >> Presentations were done to introduce people to the codebase
> generally
> > (I
> > > >> think Gary did this at one point) as well as specific parts of the
> > > >> codebase, such as compaction.  

Re: [DISCUSSION] Attracting new contributors

[Benjamin Lerer]

>
> It really boils down just to a simple "problem" to have enough
> committers to look at it over a (preferably) shorter period of time
> and make that feedback loop shorter.
>

The review delay is a clear issue. A part of the problem is that most
committers are pretty busy (or that there are not enough committers,
depending how you look at it) but another part of the problem is that we do
not have a good visibility on what is currently going on with new
contributors. By having a clear view of which newcomers' tickets are stuck
we could also act in a more efficient way. We are currently doing some
experimentations with Berenguer to have a way of tracking those things.

Once 4.0 is out of the door, I believe that some of us should also have a
bit more time to help out with newcomers' reviews/mentoring.

+1, I had a few minor patches before but the bootcamp definitely helped me
> ramp up on the project faster and I found the recorded material very useful
> during project onboarding (some of it is still available on Youtube).
>

People have different levels of experience and they will probably approach
the project in a different way but if a bootcamp can help to have another
Paulo, I am willing to do it. ;-)
Of course in this pandemic world the best we can probably offer for the
moment is some virtual bootcamp.

Le mar. 27 avr. 2021 à 15:34, Paulo Motta  a
écrit :

> +1, I had a few minor patches before but the bootcamp definitely helped me
> ramp up on the project faster and I found the recorded material very useful
> during project onboarding (some of it is still available on Youtube).
>
> I think it would be beneficial to collocate a bootcamp for new contributors
> together with an annual event such as NGCC or Apachecon/Cassandra Summit
> and also record some of the sessions so they're available for a wider
> audience after the fact.
>
> Em ter., 27 de abr. de 2021 às 10:20, Jeremy Hanna <
> jeremy.hanna1...@gmail.com> escreveu:
>
> > I believe Paolo started with the project through a contributor boot camp.
> > Also if I remember correctly some of the ones that were done were
> internal
> > at DataStax and it helped some people get familiar with the project who
> > still contribute today.
> >
> > Also this would be short recorded introductions so they could be around
> > for viewing and with auto translate on Google for different languages
> such
> > as Japanese and Mandarin.
> >
> > I do like the idea of a periodic chat. I just thought some recorded
> > introductions would help with some of the more common things like “this
> is
> > how the read path works from end to end”.
> >
> > > On Apr 27, 2021, at 10:14 PM, Benedict Elliott Smith <
> > bened...@apache.org> wrote:
> > >
> > > I think that all of the bootcamps we ran in the past produced
> precisely
> > zero new contributors.
> > >
> > > I wonder if it would be more impactful to produce slightly more
> > permanent content, such as step-by-step guides to producing a simple
> patch
> > for some subsystem. Perhaps if people want to, a recording could be
> created
> > of going through that guide as well.
> > >
> > > That said, if there are new contributors actively trying to
> participate,
> > organising a periodic group chat to talk through one of the issues that
> > they may be working on together as a group with an active contributor
> might
> > make sense, and be more targeted in focus?
> > >
> > >
> > > On 27/04/2021, 12:45, "Manish G" 
> wrote:
> > >
> > >Contributor bootcamps can really help new people like me.
> > >
> > >>On Tue, Apr 27, 2021, 5:08 PM Jeremy Hanna <
> > jeremy.hanna1...@gmail.com>
> > >>wrote:
> > >>
> > >> One thing we've done in the past is contributor bootcamps along with
> the
> > >> the new contributor guide and the LHF complexity tickets.
> > Unfortunately, I
> > >> don't know that the contributor bootcamps were ever recorded.
> > >> Presentations were done to introduce people to the codebase generally
> (I
> > >> think Gary did this at one point) as well as specific parts of the
> > >> codebase, such as compaction.  What if we broke up the codebase into
> > >> categories and people could volunteer to do a short introduction to
> that
> > >> part of the codebase in the form of a video screenshare.  I don't
> think
> > >> this would take the place of mentoring someone, but if we had
> > introductions
> > >> to different parts of the codebase, I think it would lower the bar for
> > >> interested contributors and scale the existing group more easily.
> > Besides
> > >> the codebase itself, we could also introduce things like CI practices
> or
> > >> testing or documentation.
> > >>
> >  On Apr 24, 2021, at 12:49 AM, Benjamin Lerer 
> > wrote:
> > >>>
> > >>> Hi Everybody,The Apache Cassandra project always had some issues to
> > >>> attract and retain new contributors. I think it would be great to
> > change
> > >>> this.According to the "How to Attract New Contributors" blog post (
> > >>> 

Re: [DISCUSSION] Attracting new contributors

[Paulo Motta]

+1, I had a few minor patches before but the bootcamp definitely helped me
ramp up on the project faster and I found the recorded material very useful
during project onboarding (some of it is still available on Youtube).

I think it would be beneficial to collocate a bootcamp for new contributors
together with an annual event such as NGCC or Apachecon/Cassandra Summit
and also record some of the sessions so they're available for a wider
audience after the fact.

Em ter., 27 de abr. de 2021 às 10:20, Jeremy Hanna <
jeremy.hanna1...@gmail.com> escreveu:

> I believe Paolo started with the project through a contributor boot camp.
> Also if I remember correctly some of the ones that were done were internal
> at DataStax and it helped some people get familiar with the project who
> still contribute today.
>
> Also this would be short recorded introductions so they could be around
> for viewing and with auto translate on Google for different languages such
> as Japanese and Mandarin.
>
> I do like the idea of a periodic chat. I just thought some recorded
> introductions would help with some of the more common things like “this is
> how the read path works from end to end”.
>
> > On Apr 27, 2021, at 10:14 PM, Benedict Elliott Smith <
> bened...@apache.org> wrote:
> >
> > I think that all of the bootcamps we ran in the past produced precisely
> zero new contributors.
> >
> > I wonder if it would be more impactful to produce slightly more
> permanent content, such as step-by-step guides to producing a simple patch
> for some subsystem. Perhaps if people want to, a recording could be created
> of going through that guide as well.
> >
> > That said, if there are new contributors actively trying to participate,
> organising a periodic group chat to talk through one of the issues that
> they may be working on together as a group with an active contributor might
> make sense, and be more targeted in focus?
> >
> >
> > On 27/04/2021, 12:45, "Manish G"  wrote:
> >
> >Contributor bootcamps can really help new people like me.
> >
> >>On Tue, Apr 27, 2021, 5:08 PM Jeremy Hanna <
> jeremy.hanna1...@gmail.com>
> >>wrote:
> >>
> >> One thing we've done in the past is contributor bootcamps along with the
> >> the new contributor guide and the LHF complexity tickets.
> Unfortunately, I
> >> don't know that the contributor bootcamps were ever recorded.
> >> Presentations were done to introduce people to the codebase generally (I
> >> think Gary did this at one point) as well as specific parts of the
> >> codebase, such as compaction.  What if we broke up the codebase into
> >> categories and people could volunteer to do a short introduction to that
> >> part of the codebase in the form of a video screenshare.  I don't think
> >> this would take the place of mentoring someone, but if we had
> introductions
> >> to different parts of the codebase, I think it would lower the bar for
> >> interested contributors and scale the existing group more easily.
> Besides
> >> the codebase itself, we could also introduce things like CI practices or
> >> testing or documentation.
> >>
>  On Apr 24, 2021, at 12:49 AM, Benjamin Lerer 
> wrote:
> >>>
> >>> Hi Everybody,The Apache Cassandra project always had some issues to
> >>> attract and retain new contributors. I think it would be great to
> change
> >>> this.According to the "How to Attract New Contributors" blog post (
> >>> https://www.redhat.com/en/blog/how-attract-new-contributors) having a
> >> good
> >>> onboarding process is a critical part. How to contribute should be
> >> obvious
> >>> and contributing should be as easy as possible for all the different
> >> types
> >>> of contributions: code, documentation, web-site or help with our CI
> >>> infrastructure.I would love to hear about your ideas on how we can
> >> improve
> >>> things.If you are new in the community, do not hesitate to share your
> >>> experience and your suggestions on what we can do to make it easier for
> >> you
> >>> to contribute.
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>
> >>
> >
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [DISCUSSION] Attracting new contributors

[Jeremy Hanna]

I believe Paolo started with the project through a contributor boot camp. Also 
if I remember correctly some of the ones that were done were internal at 
DataStax and it helped some people get familiar with the project who still 
contribute today. 

Also this would be short recorded introductions so they could be around for 
viewing and with auto translate on Google for different languages such as 
Japanese and Mandarin. 

I do like the idea of a periodic chat. I just thought some recorded 
introductions would help with some of the more common things like “this is how 
the read path works from end to end”. 

> On Apr 27, 2021, at 10:14 PM, Benedict Elliott Smith  
> wrote:
> 
> I think that all of the bootcamps we ran in the past produced precisely zero 
> new contributors.
> 
> I wonder if it would be more impactful to produce slightly more permanent 
> content, such as step-by-step guides to producing a simple patch for some 
> subsystem. Perhaps if people want to, a recording could be created of going 
> through that guide as well.
> 
> That said, if there are new contributors actively trying to participate, 
> organising a periodic group chat to talk through one of the issues that they 
> may be working on together as a group with an active contributor might make 
> sense, and be more targeted in focus?
> 
> 
> On 27/04/2021, 12:45, "Manish G"  wrote:
> 
>Contributor bootcamps can really help new people like me.
> 
>>On Tue, Apr 27, 2021, 5:08 PM Jeremy Hanna 
>>wrote:
>> 
>> One thing we've done in the past is contributor bootcamps along with the
>> the new contributor guide and the LHF complexity tickets.  Unfortunately, I
>> don't know that the contributor bootcamps were ever recorded.
>> Presentations were done to introduce people to the codebase generally (I
>> think Gary did this at one point) as well as specific parts of the
>> codebase, such as compaction.  What if we broke up the codebase into
>> categories and people could volunteer to do a short introduction to that
>> part of the codebase in the form of a video screenshare.  I don't think
>> this would take the place of mentoring someone, but if we had introductions
>> to different parts of the codebase, I think it would lower the bar for
>> interested contributors and scale the existing group more easily.  Besides
>> the codebase itself, we could also introduce things like CI practices or
>> testing or documentation.
>> 
 On Apr 24, 2021, at 12:49 AM, Benjamin Lerer  wrote:
>>> 
>>> Hi Everybody,The Apache Cassandra project always had some issues to
>>> attract and retain new contributors. I think it would be great to change
>>> this.According to the "How to Attract New Contributors" blog post (
>>> https://www.redhat.com/en/blog/how-attract-new-contributors) having a
>> good
>>> onboarding process is a critical part. How to contribute should be
>> obvious
>>> and contributing should be as easy as possible for all the different
>> types
>>> of contributions: code, documentation, web-site or help with our CI
>>> infrastructure.I would love to hear about your ideas on how we can
>> improve
>>> things.If you are new in the community, do not hesitate to share your
>>> experience and your suggestions on what we can do to make it easier for
>> you
>>> to contribute.
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
>> 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSSION] Attracting new contributors

[Stefan Miklosovic]

By the way, I would maybe create some kind of a list of people and
Cassandra subsystems they are the most familiar with so if there is
some problem with some area, that person (persons) would be kind of a
primary contact to go to. I know it is maybe silly to ask to
categorise it like that but they have maintainers of subsystems in
Linux kernel I think so why not to do similar thing here? It does not
need to be anything formal. It would be just up to everybody to write
down what areas of the code they feel they are strong in - that would
also shorten the communication ping-pong and respective contributors
might go directly to the right person.

On the other hand it is not too good if there is a lot of knowledge of
some subsystem in the hands of few people only, but I still think that
might be valuable to do anyway.

On Tue, 27 Apr 2021 at 14:47, Stefan Miklosovic
 wrote:
>
> On Tue, 27 Apr 2021 at 14:41, Benedict Elliott Smith
>  wrote:
> >
> > I agree, and have said as much in the past. We have limited options for 
> > improving this, though. I've proposed in the past a rotating role for 
> > contributors to respond to Jira comments, but even once a committer is 
> > involved their other commitments may make feedback rounds take a long time.
> >
> > However, even this is likely to have at most a modest impact. Most 
> > contributors don't stick around after making a patch, even if given tight 
> > feedback loops (which does happen). They just want their bug fixed - which 
> > is great, but we should set ourselves realistic expectations.
>
> This is a very good point, actually. I think it stems from the fact
> that Cassandra is in a lot of cases used by companies which just have
> an itch to scratch or a problem to solve and as long as it does not
> otherwise interfere with the business they are involved it, they just
> do not have any need to contribute more, which is quite understandable
> if they just do 9-to-5 thing and so on. So yes, definitely, realistic
> expectations are needed. I do not blame anybody in particular, it is
> just how it is, I can say only good happened to me whoever I was
> talking with over some tickets knowing they have a heap of work in the
> background to deal with.
>
> > The community needs to do better specifically with new active contributors 
> > who stick around for a few tickets, and to produce better (passive) 
> > incentives for people to stick around for a few tickets.
> >
> > On 27/04/2021, 13:22, "Stefan Miklosovic" 
> >  wrote:
> >
> > It really boils down just to a simple "problem" to have enough
> > committers to look at it over a (preferably) shorter period of time
> > and make that feedback loop shorter. That's it. You might have the
> > best guides and whatever but if a dust settles at it no guide will
> > make it happen.
> >
> > On Tue, 27 Apr 2021 at 14:14, Benedict Elliott Smith
> >  wrote:
> > >
> > > I think that all of the bootcamps we ran in the past produced 
> > precisely zero new contributors.
> > >
> > > I wonder if it would be more impactful to produce slightly more 
> > permanent content, such as step-by-step guides to producing a simple patch 
> > for some subsystem. Perhaps if people want to, a recording could be created 
> > of going through that guide as well.
> > >
> > > That said, if there are new contributors actively trying to 
> > participate, organising a periodic group chat to talk through one of the 
> > issues that they may be working on together as a group with an active 
> > contributor might make sense, and be more targeted in focus?
> > >
> > >
> > > On 27/04/2021, 12:45, "Manish G"  
> > wrote:
> > >
> > > Contributor bootcamps can really help new people like me.
> > >
> > > On Tue, Apr 27, 2021, 5:08 PM Jeremy Hanna 
> > 
> > > wrote:
> > >
> > > > One thing we've done in the past is contributor bootcamps along 
> > with the
> > > > the new contributor guide and the LHF complexity tickets.  
> > Unfortunately, I
> > > > don't know that the contributor bootcamps were ever recorded.
> > > > Presentations were done to introduce people to the codebase 
> > generally (I
> > > > think Gary did this at one point) as well as specific parts of 
> > the
> > > > codebase, such as compaction.  What if we broke up the codebase 
> > into
> > > > categories and people could volunteer to do a short 
> > introduction to that
> > > > part of the codebase in the form of a video screenshare.  I 
> > don't think
> > > > this would take the place of mentoring someone, but if we had 
> > introductions
> > > > to different parts of the codebase, I think it would lower the 
> > bar for
> > > > interested contributors and scale the existing group more 
> > easily.  Besides
> > > > the codebase itself, we could also introduce things like CI 
> > practices or
> >  

Re: [DISCUSSION] Attracting new contributors

[Stefan Miklosovic]

On Tue, 27 Apr 2021 at 14:41, Benedict Elliott Smith
 wrote:
>
> I agree, and have said as much in the past. We have limited options for 
> improving this, though. I've proposed in the past a rotating role for 
> contributors to respond to Jira comments, but even once a committer is 
> involved their other commitments may make feedback rounds take a long time.
>
> However, even this is likely to have at most a modest impact. Most 
> contributors don't stick around after making a patch, even if given tight 
> feedback loops (which does happen). They just want their bug fixed - which is 
> great, but we should set ourselves realistic expectations.

This is a very good point, actually. I think it stems from the fact
that Cassandra is in a lot of cases used by companies which just have
an itch to scratch or a problem to solve and as long as it does not
otherwise interfere with the business they are involved it, they just
do not have any need to contribute more, which is quite understandable
if they just do 9-to-5 thing and so on. So yes, definitely, realistic
expectations are needed. I do not blame anybody in particular, it is
just how it is, I can say only good happened to me whoever I was
talking with over some tickets knowing they have a heap of work in the
background to deal with.

> The community needs to do better specifically with new active contributors 
> who stick around for a few tickets, and to produce better (passive) 
> incentives for people to stick around for a few tickets.
>
> On 27/04/2021, 13:22, "Stefan Miklosovic" 
>  wrote:
>
> It really boils down just to a simple "problem" to have enough
> committers to look at it over a (preferably) shorter period of time
> and make that feedback loop shorter. That's it. You might have the
> best guides and whatever but if a dust settles at it no guide will
> make it happen.
>
> On Tue, 27 Apr 2021 at 14:14, Benedict Elliott Smith
>  wrote:
> >
> > I think that all of the bootcamps we ran in the past produced precisely 
> zero new contributors.
> >
> > I wonder if it would be more impactful to produce slightly more 
> permanent content, such as step-by-step guides to producing a simple patch 
> for some subsystem. Perhaps if people want to, a recording could be created 
> of going through that guide as well.
> >
> > That said, if there are new contributors actively trying to 
> participate, organising a periodic group chat to talk through one of the 
> issues that they may be working on together as a group with an active 
> contributor might make sense, and be more targeted in focus?
> >
> >
> > On 27/04/2021, 12:45, "Manish G"  wrote:
> >
> > Contributor bootcamps can really help new people like me.
> >
> > On Tue, Apr 27, 2021, 5:08 PM Jeremy Hanna 
> 
> > wrote:
> >
> > > One thing we've done in the past is contributor bootcamps along 
> with the
> > > the new contributor guide and the LHF complexity tickets.  
> Unfortunately, I
> > > don't know that the contributor bootcamps were ever recorded.
> > > Presentations were done to introduce people to the codebase 
> generally (I
> > > think Gary did this at one point) as well as specific parts of the
> > > codebase, such as compaction.  What if we broke up the codebase 
> into
> > > categories and people could volunteer to do a short introduction 
> to that
> > > part of the codebase in the form of a video screenshare.  I don't 
> think
> > > this would take the place of mentoring someone, but if we had 
> introductions
> > > to different parts of the codebase, I think it would lower the 
> bar for
> > > interested contributors and scale the existing group more easily. 
>  Besides
> > > the codebase itself, we could also introduce things like CI 
> practices or
> > > testing or documentation.
> > >
> > > > On Apr 24, 2021, at 12:49 AM, Benjamin Lerer 
>  wrote:
> > > >
> > > > Hi Everybody,The Apache Cassandra project always had some 
> issues to
> > > > attract and retain new contributors. I think it would be great 
> to change
> > > > this.According to the "How to Attract New Contributors" blog 
> post (
> > > > https://www.redhat.com/en/blog/how-attract-new-contributors) 
> having a
> > > good
> > > > onboarding process is a critical part. How to contribute should 
> be
> > > obvious
> > > > and contributing should be as easy as possible for all the 
> different
> > > types
> > > > of contributions: code, documentation, web-site or help with 
> our CI
> > > > infrastructure.I would love to hear about your ideas on how we 
> can
> > > improve
> > > > things.If you are new in the community, do not hesitate to 
> share your
> > > > experience and your suggestions 

Re: [DISCUSSION] Attracting new contributors

[Benedict Elliott Smith]

I agree, and have said as much in the past. We have limited options for 
improving this, though. I've proposed in the past a rotating role for 
contributors to respond to Jira comments, but even once a committer is involved 
their other commitments may make feedback rounds take a long time.

However, even this is likely to have at most a modest impact. Most contributors 
don't stick around after making a patch, even if given tight feedback loops 
(which does happen). They just want their bug fixed - which is great, but we 
should set ourselves realistic expectations.

The community needs to do better specifically with new active contributors who 
stick around for a few tickets, and to produce better (passive) incentives for 
people to stick around for a few tickets.

On 27/04/2021, 13:22, "Stefan Miklosovic"  
wrote:

It really boils down just to a simple "problem" to have enough
committers to look at it over a (preferably) shorter period of time
and make that feedback loop shorter. That's it. You might have the
best guides and whatever but if a dust settles at it no guide will
make it happen.

On Tue, 27 Apr 2021 at 14:14, Benedict Elliott Smith
 wrote:
>
> I think that all of the bootcamps we ran in the past produced precisely 
zero new contributors.
>
> I wonder if it would be more impactful to produce slightly more permanent 
content, such as step-by-step guides to producing a simple patch for some 
subsystem. Perhaps if people want to, a recording could be created of going 
through that guide as well.
>
> That said, if there are new contributors actively trying to participate, 
organising a periodic group chat to talk through one of the issues that they 
may be working on together as a group with an active contributor might make 
sense, and be more targeted in focus?
>
>
> On 27/04/2021, 12:45, "Manish G"  wrote:
>
> Contributor bootcamps can really help new people like me.
>
> On Tue, Apr 27, 2021, 5:08 PM Jeremy Hanna 

> wrote:
>
> > One thing we've done in the past is contributor bootcamps along 
with the
> > the new contributor guide and the LHF complexity tickets.  
Unfortunately, I
> > don't know that the contributor bootcamps were ever recorded.
> > Presentations were done to introduce people to the codebase 
generally (I
> > think Gary did this at one point) as well as specific parts of the
> > codebase, such as compaction.  What if we broke up the codebase into
> > categories and people could volunteer to do a short introduction to 
that
> > part of the codebase in the form of a video screenshare.  I don't 
think
> > this would take the place of mentoring someone, but if we had 
introductions
> > to different parts of the codebase, I think it would lower the bar 
for
> > interested contributors and scale the existing group more easily.  
Besides
> > the codebase itself, we could also introduce things like CI 
practices or
> > testing or documentation.
> >
> > > On Apr 24, 2021, at 12:49 AM, Benjamin Lerer  
wrote:
> > >
> > > Hi Everybody,The Apache Cassandra project always had some issues 
to
> > > attract and retain new contributors. I think it would be great to 
change
> > > this.According to the "How to Attract New Contributors" blog post 
(
> > > https://www.redhat.com/en/blog/how-attract-new-contributors) 
having a
> > good
> > > onboarding process is a critical part. How to contribute should be
> > obvious
> > > and contributing should be as easy as possible for all the 
different
> > types
> > > of contributions: code, documentation, web-site or help with our 
CI
> > > infrastructure.I would love to hear about your ideas on how we can
> > improve
> > > things.If you are new in the community, do not hesitate to share 
your
> > > experience and your suggestions on what we can do to make it 
easier for
> > you
> > > to contribute.
> >
> >
> > 
-
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org




-
To unsubscribe, e-mail: 

Re: [DISCUSSION] Attracting new contributors

[Stefan Miklosovic]

It really boils down just to a simple "problem" to have enough
committers to look at it over a (preferably) shorter period of time
and make that feedback loop shorter. That's it. You might have the
best guides and whatever but if a dust settles at it no guide will
make it happen.

On Tue, 27 Apr 2021 at 14:14, Benedict Elliott Smith
 wrote:
>
> I think that all of the bootcamps we ran in the past produced precisely zero 
> new contributors.
>
> I wonder if it would be more impactful to produce slightly more permanent 
> content, such as step-by-step guides to producing a simple patch for some 
> subsystem. Perhaps if people want to, a recording could be created of going 
> through that guide as well.
>
> That said, if there are new contributors actively trying to participate, 
> organising a periodic group chat to talk through one of the issues that they 
> may be working on together as a group with an active contributor might make 
> sense, and be more targeted in focus?
>
>
> On 27/04/2021, 12:45, "Manish G"  wrote:
>
> Contributor bootcamps can really help new people like me.
>
> On Tue, Apr 27, 2021, 5:08 PM Jeremy Hanna 
> wrote:
>
> > One thing we've done in the past is contributor bootcamps along with the
> > the new contributor guide and the LHF complexity tickets.  
> Unfortunately, I
> > don't know that the contributor bootcamps were ever recorded.
> > Presentations were done to introduce people to the codebase generally (I
> > think Gary did this at one point) as well as specific parts of the
> > codebase, such as compaction.  What if we broke up the codebase into
> > categories and people could volunteer to do a short introduction to that
> > part of the codebase in the form of a video screenshare.  I don't think
> > this would take the place of mentoring someone, but if we had 
> introductions
> > to different parts of the codebase, I think it would lower the bar for
> > interested contributors and scale the existing group more easily.  
> Besides
> > the codebase itself, we could also introduce things like CI practices or
> > testing or documentation.
> >
> > > On Apr 24, 2021, at 12:49 AM, Benjamin Lerer  
> wrote:
> > >
> > > Hi Everybody,The Apache Cassandra project always had some issues to
> > > attract and retain new contributors. I think it would be great to 
> change
> > > this.According to the "How to Attract New Contributors" blog post (
> > > https://www.redhat.com/en/blog/how-attract-new-contributors) having a
> > good
> > > onboarding process is a critical part. How to contribute should be
> > obvious
> > > and contributing should be as easy as possible for all the different
> > types
> > > of contributions: code, documentation, web-site or help with our CI
> > > infrastructure.I would love to hear about your ideas on how we can
> > improve
> > > things.If you are new in the community, do not hesitate to share your
> > > experience and your suggestions on what we can do to make it easier 
> for
> > you
> > > to contribute.
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSSION] Attracting new contributors

[Benedict Elliott Smith]

I think that all of the bootcamps we ran in the past produced precisely zero 
new contributors.

I wonder if it would be more impactful to produce slightly more permanent 
content, such as step-by-step guides to producing a simple patch for some 
subsystem. Perhaps if people want to, a recording could be created of going 
through that guide as well.

That said, if there are new contributors actively trying to participate, 
organising a periodic group chat to talk through one of the issues that they 
may be working on together as a group with an active contributor might make 
sense, and be more targeted in focus?


On 27/04/2021, 12:45, "Manish G"  wrote:

Contributor bootcamps can really help new people like me.

On Tue, Apr 27, 2021, 5:08 PM Jeremy Hanna 
wrote:

> One thing we've done in the past is contributor bootcamps along with the
> the new contributor guide and the LHF complexity tickets.  Unfortunately, 
I
> don't know that the contributor bootcamps were ever recorded.
> Presentations were done to introduce people to the codebase generally (I
> think Gary did this at one point) as well as specific parts of the
> codebase, such as compaction.  What if we broke up the codebase into
> categories and people could volunteer to do a short introduction to that
> part of the codebase in the form of a video screenshare.  I don't think
> this would take the place of mentoring someone, but if we had 
introductions
> to different parts of the codebase, I think it would lower the bar for
> interested contributors and scale the existing group more easily.  Besides
> the codebase itself, we could also introduce things like CI practices or
> testing or documentation.
>
> > On Apr 24, 2021, at 12:49 AM, Benjamin Lerer  wrote:
> >
> > Hi Everybody,The Apache Cassandra project always had some issues to
> > attract and retain new contributors. I think it would be great to change
> > this.According to the "How to Attract New Contributors" blog post (
> > https://www.redhat.com/en/blog/how-attract-new-contributors) having a
> good
> > onboarding process is a critical part. How to contribute should be
> obvious
> > and contributing should be as easy as possible for all the different
> types
> > of contributions: code, documentation, web-site or help with our CI
> > infrastructure.I would love to hear about your ideas on how we can
> improve
> > things.If you are new in the community, do not hesitate to share your
> > experience and your suggestions on what we can do to make it easier for
> you
> > to contribute.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>



-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSSION] Attracting new contributors

[Manish G]

Contributor bootcamps can really help new people like me.

On Tue, Apr 27, 2021, 5:08 PM Jeremy Hanna 
wrote:

> One thing we've done in the past is contributor bootcamps along with the
> the new contributor guide and the LHF complexity tickets.  Unfortunately, I
> don't know that the contributor bootcamps were ever recorded.
> Presentations were done to introduce people to the codebase generally (I
> think Gary did this at one point) as well as specific parts of the
> codebase, such as compaction.  What if we broke up the codebase into
> categories and people could volunteer to do a short introduction to that
> part of the codebase in the form of a video screenshare.  I don't think
> this would take the place of mentoring someone, but if we had introductions
> to different parts of the codebase, I think it would lower the bar for
> interested contributors and scale the existing group more easily.  Besides
> the codebase itself, we could also introduce things like CI practices or
> testing or documentation.
>
> > On Apr 24, 2021, at 12:49 AM, Benjamin Lerer  wrote:
> >
> > Hi Everybody,The Apache Cassandra project always had some issues to
> > attract and retain new contributors. I think it would be great to change
> > this.According to the "How to Attract New Contributors" blog post (
> > https://www.redhat.com/en/blog/how-attract-new-contributors) having a
> good
> > onboarding process is a critical part. How to contribute should be
> obvious
> > and contributing should be as easy as possible for all the different
> types
> > of contributions: code, documentation, web-site or help with our CI
> > infrastructure.I would love to hear about your ideas on how we can
> improve
> > things.If you are new in the community, do not hesitate to share your
> > experience and your suggestions on what we can do to make it easier for
> you
> > to contribute.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [DISCUSSION] Attracting new contributors

[Jeremy Hanna]

One thing we've done in the past is contributor bootcamps along with the the 
new contributor guide and the LHF complexity tickets.  Unfortunately, I don't 
know that the contributor bootcamps were ever recorded.  Presentations were 
done to introduce people to the codebase generally (I think Gary did this at 
one point) as well as specific parts of the codebase, such as compaction.  What 
if we broke up the codebase into categories and people could volunteer to do a 
short introduction to that part of the codebase in the form of a video 
screenshare.  I don't think this would take the place of mentoring someone, but 
if we had introductions to different parts of the codebase, I think it would 
lower the bar for interested contributors and scale the existing group more 
easily.  Besides the codebase itself, we could also introduce things like CI 
practices or testing or documentation.

> On Apr 24, 2021, at 12:49 AM, Benjamin Lerer  wrote:
> 
> Hi Everybody,The Apache Cassandra project always had some issues to
> attract and retain new contributors. I think it would be great to change
> this.According to the "How to Attract New Contributors" blog post (
> https://www.redhat.com/en/blog/how-attract-new-contributors) having a good
> onboarding process is a critical part. How to contribute should be obvious
> and contributing should be as easy as possible for all the different types
> of contributions: code, documentation, web-site or help with our CI
> infrastructure.I would love to hear about your ideas on how we can improve
> things.If you are new in the community, do not hesitate to share your
> experience and your suggestions on what we can do to make it easier for you
> to contribute.


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [DISCUSSION] Attracting new contributors

[Benjamin Lerer]

Your analysis makes a lot of sense to me.


> 1. This is the most important and at the same time the hardest issue to
> solve because committers in fact have limited bandwidth and are generally
> working on larger impact items. Nevertheless we must understand the
> importance of attracting new contributors to the project in order to
> increase the contributor pool and diversity. So I think committers and
> organizations must spare some of their bandwidth to ensure tickets from new
> contributors are reviewed and given feedback in a timely manner. I also
> think that we could set up a slack bot to alert #cassandra-dev periodically
> when there are patch available tickets without reviewers to bring attention
> to those.


Should we have a JIRA board to track the patch available and in review LHF
fruit tickets? We could monitor it and make sure that reviews are addressed
in a reasonable time frame.

  2. I think we need to define clear guidelines of what is a low hanging
> fruit ticket and document it, since the interpretation can vary wildly
> depending on who files the ticket. I also think we need to add one
> additional complexity type "Easy" in between "LHF" and "Normal" tickets, to
> avoid people tagging easy tickets as LHF tickets, since "LHF" tickets are
> easy ticket for new contributors, while "Easy" tickets would be easy
> tickets for existing contributors.
>

 Using an "Easy" sound like a good idea. My feeling regarding "LHF" tickets
is similar to yours. I was wondering if we should not go through our LHF
tickets and enhance the description with some overall plan of how the
problem can be addressed (I volunteer for that). If we have trouble coming
up with a simple plan, it might mean that it is not a true LHF.
We could also add a mentor on the ticket that the person can reach out if
it needs to. I believe that Ekaterina and Berenguer would be happy to help
there.
What do you think?

3. I think we need better guidelines and documentation on how to file
> tickets with well defined descriptions and scope (or explicitly mention
> when scope is unclear), to ensure we have better consistency between
> different ticket definitions.
>

+1

4. For this I think the workflow proposed on the JIRA Ticket Hygiene thread
> [1] will be helpful.
>

Thanks for taking care of that :-)


Le lun. 26 avr. 2021 à 01:57, Paulo Motta  a
écrit :

> Hi,
>
> Thanks for bringing this important topic for discussion Benjamin. I think
> it would help to enumerate what issues we face to attract new contributors
> currently and then try to act on those.
>
> 1. Committers have little bandwidth to review low-impact issues (ie. Low
> Hanging Fruit (LHF)), which are generally the entry-point for new
> contributors. Lack of feedback on these initial contributions discourage
> new contributions, creating a barrier for new contributors to join the
> community (this point was raised by Stefan on this thread[1]).
>
> 2. Lack of consistency when labeling tickets as LHF. Some tickets are easy
> but not tagged as LHF, some tickets are tagged as LHF but are not easy
> enough for new contributors.
>
> 3. Lack of consistency when filling JIRA tickets. Some tickets have a clear
> scope and definition, making it easier for new contributors to self serve
> and figure out what needs to be done, while others have bad descriptions or
> ill-defined scopes making it hard for beginners to work on these tickets.
>
> 4. Out of date or invalid JIRA tickets, making it harder for beginners to
> figure out if a given ticket is valid or not to work on.
>
> In order to improve each of these items I propose the following action
> items:
>
> 1. This is the most important and at the same time the hardest issue to
> solve because committers in fact have limited bandwidth and are generally
> working on larger impact items. Nevertheless we must understand the
> importance of attracting new contributors to the project in order to
> increase the contributor pool and diversity. So I think committers and
> organizations must spare some of their bandwidth to ensure tickets from new
> contributors are reviewed and given feedback in a timely manner. I also
> think that we could set up a slack bot to alert #cassandra-dev periodically
> when there are patch available tickets without reviewers to bring attention
> to those.
>
> 2. I think we need to define clear guidelines of what is a low hanging
> fruit ticket and document it, since the interpretation can vary wildly
> depending on who files the ticket. I also think we need to add one
> additional complexity type "Easy" in between "LHF" and "Normal" tickets, to
> avoid people tagging easy tickets as LHF tickets, since "LHF" tickets are
> easy ticket for new contributors, while "Easy" tickets would be easy
> tickets for existing contributors.
>
> 3. I think we need better guidelines and documentation on how to file
> tickets with well defined descriptions and scope (or explicitly mention
> when scope is unclear), to ensure we 

Re: [DISCUSSION] Attracting new contributors

[Paulo Motta]

Hi,

Thanks for bringing this important topic for discussion Benjamin. I think
it would help to enumerate what issues we face to attract new contributors
currently and then try to act on those.

1. Committers have little bandwidth to review low-impact issues (ie. Low
Hanging Fruit (LHF)), which are generally the entry-point for new
contributors. Lack of feedback on these initial contributions discourage
new contributions, creating a barrier for new contributors to join the
community (this point was raised by Stefan on this thread[1]).

2. Lack of consistency when labeling tickets as LHF. Some tickets are easy
but not tagged as LHF, some tickets are tagged as LHF but are not easy
enough for new contributors.

3. Lack of consistency when filling JIRA tickets. Some tickets have a clear
scope and definition, making it easier for new contributors to self serve
and figure out what needs to be done, while others have bad descriptions or
ill-defined scopes making it hard for beginners to work on these tickets.

4. Out of date or invalid JIRA tickets, making it harder for beginners to
figure out if a given ticket is valid or not to work on.

In order to improve each of these items I propose the following action
items:

1. This is the most important and at the same time the hardest issue to
solve because committers in fact have limited bandwidth and are generally
working on larger impact items. Nevertheless we must understand the
importance of attracting new contributors to the project in order to
increase the contributor pool and diversity. So I think committers and
organizations must spare some of their bandwidth to ensure tickets from new
contributors are reviewed and given feedback in a timely manner. I also
think that we could set up a slack bot to alert #cassandra-dev periodically
when there are patch available tickets without reviewers to bring attention
to those.

2. I think we need to define clear guidelines of what is a low hanging
fruit ticket and document it, since the interpretation can vary wildly
depending on who files the ticket. I also think we need to add one
additional complexity type "Easy" in between "LHF" and "Normal" tickets, to
avoid people tagging easy tickets as LHF tickets, since "LHF" tickets are
easy ticket for new contributors, while "Easy" tickets would be easy
tickets for existing contributors.

3. I think we need better guidelines and documentation on how to file
tickets with well defined descriptions and scope (or explicitly mention
when scope is unclear), to ensure we have better consistency between
different ticket definitions.

4. For this I think the workflow proposed on the JIRA Ticket Hygiene thread
[1] will be helpful.

This list is non-exhaustive so feel free to add more points as well as
discuss these points I raised.

Regards,

Paulo

[1] - https://www.mail-archive.com/dev@cassandra.apache.org/msg16384.html

Em sex., 23 de abr. de 2021 às 11:50, Benjamin Lerer 
escreveu:

>  Hi Everybody,The Apache Cassandra project always had some issues to
> attract and retain new contributors. I think it would be great to change
> this.According to the "How to Attract New Contributors" blog post (
> https://www.redhat.com/en/blog/how-attract-new-contributors) having a good
> onboarding process is a critical part. How to contribute should be obvious
> and contributing should be as easy as possible for all the different types
> of contributions: code, documentation, web-site or help with our CI
> infrastructure.I would love to hear about your ideas on how we can improve
> things.If you are new in the community, do not hesitate to share your
> experience and your suggestions on what we can do to make it easier for you
> to contribute.
>

[DISCUSSION] Attracting new contributors

[Benjamin Lerer]

 Hi Everybody,The Apache Cassandra project always had some issues to
attract and retain new contributors. I think it would be great to change
this.According to the "How to Attract New Contributors" blog post (
https://www.redhat.com/en/blog/how-attract-new-contributors) having a good
onboarding process is a critical part. How to contribute should be obvious
and contributing should be as easy as possible for all the different types
of contributions: code, documentation, web-site or help with our CI
infrastructure.I would love to hear about your ideas on how we can improve
things.If you are new in the community, do not hesitate to share your
experience and your suggestions on what we can do to make it easier for you
to contribute.