Quake has it like - I Can Win - Bring It On - Hurt Me Plenty - Hardcore - Nightmare!
On Tue, 27 Apr 2021 at 19:02, Benedict Elliott Smith <bened...@apache.org> wrote: > > I think Duke Nuke'em would be more apt > > - Piece of Cake > - Let's Rock > - Come Get Some > - Damn I'm Good > > On 27/04/2021, 17:57, "Patrick McFadin" <pmcfa...@gmail.com> wrote: > > 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 > > > > > > > > --------------------------------------------------------------------- > 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
