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 <pauloricard...@gmail.com> 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 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 <ble...@apache.org> > 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. > > >
