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" <pauloricard...@gmail.com> 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)) > > - 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" <pauloricard...@gmail.com > > > > 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 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 < > > > pauloricard...@gmail.com> 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" < > > > 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 > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
