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 <stefan.mikloso...@instaclustr.com> wrote: > > On Tue, 27 Apr 2021 at 14:41, Benedict Elliott Smith > <bened...@apache.org> 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" > > <stefan.mikloso...@instaclustr.com> 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 > > <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" <manish.c.ghildi...@gmail.com> > > 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 > > <ble...@apache.org> 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: 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
