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
