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
