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
