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 <m...@apache.org> 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&d=DwIBaQ&c=adz96Xi0w1RHqtPMowiL2g&r=bL2UpIjL4Mm1mCbqWThJUiPD-CmTXMALsIT2Ta-KfGk&m=q_dsXQ6jX9WOdt0mTaSMswT8YBVJJ3tuHsqmiomJHYc&s=__XC3za3frwYqDZAgqymi4eS1lA6mVMYWt4NSw_8cF4&e= > > 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 > >
