Thanks Paulo, that would be great. And thank you Angelo for raising the
problem.
Le jeu. 29 avr. 2021 à 15:13, Paulo Motta a
écrit :
> > Effectively, some people provide patches without assigning the ticket to
> themselves. :-(
>
> I will try to think of an automation in the context of the JIRA
> Effectively, some people provide patches without assigning the ticket to
themselves. :-(
I will try to think of an automation in the context of the JIRA hygiene
effort that detects this and sends an automatic message asking the person
to set themselves as assignees.
Em qui., 29 de abr. de 2021
>
> Might also want to check among the tickets opened by non-committers and
> still awaiting an assignee. E.g.
>
> *assignee is EMPTY AND reporter not in membersOf(Committers)*
>
> There are patches/pull-requests there too.
Effectively, some people provide patches without assigning the ticket to
Might also want to check among the tickets opened by non-committers and
still awaiting an assignee. E.g.
*assignee is EMPTY AND reporter not in membersOf(Committers)*
There are patches/pull-requests there too.
Best,
Angelo
On Thu, Apr 29, 2021 at 1:51 PM Benjamin Lerer wrote:
> >
> >
>
> Berenguer created this board to help to track newcomers contributions:
>
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=463=2088
My apologies, the board was not accessible to most persons. I solved that
and everybody should have access to it now.
Some committers are
Thanks for the feedback Aleksei,
A good way of doing that
> is having some rewards. It might be smth material like a T-Shirt (I
> remember getting a T-Shirt on C* v2 release was nice; obviously not for
> a single commit, but for multiple - depends on the budget; or top 10 the
> most active
Thanks Aleksei,
Some of these are great points, but to respond specifically to the checkstyle
suggestion: I hope to kick off some (minor) discussion around codestyle soon to
modernise our guide, however I would personally prefer that code style
enforcement remains relatively light touch. Some
Hi Benjamin,
I'd like to put in my two cents as well.
There were many great suggestions related to the communication and
process. They make sense to me, however, I'd like to look at the problem
from another perspective.
First of all, let me share my perception on the opensource activities.
>
> Is it possible if a new comer works together with a mentor on an issue?
> This way mentor can gradually introduce the newcomer into the codebase, and
> newcomer would get timely feedback too.
It is complicated unfortunately because most of us have limited bandwidth
and we are spread across
Is it possible if a new comer works together with a mentor on an issue?
This way mentor can gradually introduce the newcomer into the codebase, and
newcomer would get timely feedback too.
On Wed, Apr 28, 2021 at 2:51 PM Benedict Elliott Smith
wrote:
> > I believe that it can be a virtuous
> I believe that it can be a virtuous circle where we produce new committers
> that help mentoring newcomers.
That's the dream, and kudos for keeping it alive! I have become jaded about
this possibility, after years of trying.
On 28/04/2021, 10:18, "Benjamin Lerer" wrote:
>
> I
>
> I think there are two main hurdles, one is restoring contributor interest
> in mentoring, and the other is finding newcomers that actually want to
> stick around.
I am interested in mentoring new committers to help the project grow and
some of the new committers expressed the same interest
I think there are two main hurdles, one is restoring contributor interest in
mentoring, and the other is finding newcomers that actually want to stick
around. These are perhaps two sides of the same coin, though. An ugly truth is
that it isn't very enjoyable or rewarding to help newcomers when
> There is no great hurdle in finding something to work on, it's solely finding
someone with the knowledge that can help you work on something and progress
it to commit.
I agree the primary challenge is to engage existing contributors to mentor
newcomers, but this doesn’t preclude having good
The main problem, as has always been, is that the big players have a
stranglehold on all the committer resources, and bringing in new
contributors is not high on their priorities. All that's really required
here is that existing committers are directed to spend some non-negligible
portion of their
I should chime in and mention that we are in the process of migrating the
Contributing/Development sections of the documentation to the site-wide,
non-versioned "docs" in cassandra-website, rather than in the docs. That
will come into existence when we can get the "new" docs, written in
asciidoc,
> Thanks for bringing this important topic for discussion Benjamin. I think
> it would help to enumerate what issues we face to attract new contributors
> currently and then try to act on those.
>
> 1. Committers have little bandwidth to review low-impact issues (ie. Low
> Hanging Fruit (LHF)),
I have to admit, I like those Duke Nukem levels way more than I should. I
guess when you choose "Damn I'm Good" you get the boss fight to end all
boss fights. "Benedict has been assigned as a reviewer..." o.O
But seriously folks. :D
I would advocate for a simple tiering system.
Entry Level
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
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
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" wrote:
Could always go with Doom difficulty levels:
- I'm Too Young to Die - Easy.
- Hurt Me Plenty - Normal.
- Ultra-Violence
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
wrote:
> Perhaps we could replace both Complexity and Difficulty
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
Hi everyone. Jumping in because I love this topic. Thank you for starting
it, Benjamin.
The thread is about attracting new contributors, but the direction this has
taken seems to be more along the line of how to attract code contributors.
We list a lot of contributions that have nothing to do
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
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
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
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.
On Tue, Apr 27, 2021 at 9:32 AM Paulo Motta wrote:
>
> 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
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
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
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
>
> 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
+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
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
By the way, I would maybe create some kind of a list of people and
Cassandra subsystems they are the most familiar with so if there is
some problem with some area, that person (persons) would be kind of a
primary contact to go to. I know it is maybe silly to ask to
categorise it like that but they
On Tue, 27 Apr 2021 at 14:41, Benedict Elliott Smith
wrote:
>
> I agree, and have said as much in the past. We have limited options for
> improving this, though. I've proposed in the past a rotating role for
> contributors to respond to Jira comments, but even once a committer is
> involved
I agree, and have said as much in the past. We have limited options for
improving this, though. I've proposed in the past a rotating role for
contributors to respond to Jira comments, but even once a committer is involved
their other commitments may make feedback rounds take a long time.
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. That's it. You might have the
best guides and whatever but if a dust settles at it no guide will
make it happen.
On Tue, 27 Apr
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
Contributor bootcamps can really help new people like me.
On Tue, Apr 27, 2021, 5:08 PM Jeremy Hanna
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
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
Your analysis makes a lot of sense to me.
> 1. This is the most important and at the same time the hardest issue to
> solve because committers in fact have limited bandwidth and are generally
> working on larger impact items. Nevertheless we must understand the
> importance of attracting new
Hi,
Thanks for bringing this important topic for discussion Benjamin. I think
it would help to enumerate what issues we face to attract new contributors
currently and then try to act on those.
1. Committers have little bandwidth to review low-impact issues (ie. Low
Hanging Fruit (LHF)), which
43 matches
Mail list logo
