> 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
