> 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 docu
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, i
FWIW, the goal of this field was to help project planning (both going forwards,
and in looking at how we've fared to help project going forwards) more than
contributor assignment. There wasn't any expectation that the correct
complexity would be provided on triage.
I'm not sure how much Jira
+1 as well.
One thing to note, many times when i create a ticket i don't know the
complexity as I just found a bug (most of the time in a system i do not
know); so i tend to default to w/e is in the middle. Leaving the field for
someone else to classify feels iffy as we need then someone triaging
Branching out the discussion on the complexity levels from the "Attracting
new contributors" thread so we don't mix up the topics in the same thread.
I personally think that the "complexity" field is more an indicator/hint
for inexperienced contributors on whether he will be able to work on a
part
> 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)), whi
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
Inter
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 M
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 wit
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 ob
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 with
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 than
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 t
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.
Chall
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 contributed
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 mi
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 sti
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
barrie
>
> 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
t
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 s
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 the
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.
Howeve
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 20
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 co
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 b
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
31 matches
Mail list logo
