cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anuj Wadehra <>
Subject Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)
Date Sat, 12 Nov 2016 07:23:58 GMT
Thanks for the information Jeremy. 

My main concern is around making JIRAs easy to understand. I am not sure how community feels
about it. But, I have personally observed that long discussion thread on JIRAs is not user
friendly for someone trying to understand the ticket or may be trying to contribute to the
discussion/fix . I strongly feel that there should be a better way e.g. a summary field in
JIRA which filters out the discussions, arguments, solutions etc.and just crisply summarizes
the problem, solution under discussion and the current status. Sometimes description of the
defect is not sufficient.   For a new comer trying to understand a JIRA, this summary would
be a good start to understand the problem upfront and then if you want to go into details,
you can understand the long JIRA thread.
Also, some JIRAs are in dead state and you don't get a clue what's the current status after
so much discussion over the ticket? Some JIRAs are neither rejected nor validated, so even
if its a bug, some people would be reluctant to pick JIRAs which have not been validated yet.



    On Friday, 11 November 2016 1:40 AM, Jeremy Hanna <> wrote:

 Regarding low hanging fruit, on the How To Contribute page [1] we’ve tried to keep a list
of lhf tickets [2] linked to help people get started.  They are usually good starting points
and don’t require much context.  I rarely see duplicates from lhf tickets.

Regarding duplicates, in my experience those who resolve tickets as duplicates are generally
pretty good.

I think the safest bet to start is to look at How To Contribute page and the lhf labeled tickets.

[1] <>

> On Nov 10, 2016, at 12:06 PM, Anuj Wadehra <> wrote:
> Hi,
> We need to understand that time is precious for all of us. Even if a developer has intentions
to contribute, he may take months to contribute his first patch or may be longer. Some common
entry barriers are:
> 1. Difficult to identify low hanging fruits. 30 JIRA comments on a ticket and a new comer
is LOST, even though the exact fix may be much simpler.
> 2. Dead JIRA discussions with no clue on the current status of the ticket.
> 3. No response on new JIRAs raised. Response time  to validate/reject the problem is
important. Should I pick? Is it really a bug? Maybe some expert can confirm it first and then
I can pick it..
> 4.Ping Pong JIRAs: Your read 10 comments of a ticket then see duplicates and related
ones..then read 30 more comments and then so on till you land up on same JIRA which is not
concluded yet.
> Possible Solution for above 4 points:
> A. Add a new JIRA field to crisply summarize what conclusive discussion has taken place
till now ,what's the status of current JIRA, proposed/feasible solution etc.
> B. Mark low hanging fruits regularly.
> C. Validate/Reject newly reported JIRAs on priority. Using dev list to validate/reject
the issue before logging the JIRA??
> D. Make sure that duplicates are real proven duplicates.
> 5. Insufficient code comments. 
> Solution: Coding comments should be a mandatory part of code review checklist. It makes
reviews faster and encourage people to understand the flow and fix things on their own.
> 6. Insufficient Design documentation.
> Solution:Detailed documentation for at least new features so that people are comfortable
with the design. Reading English and understanding diagrams/flows is much simpler than just
jumping into the code upfront.
> 7. No/Little formal communication on active development and way forward.
> Solution: What about a monthly summary of New/Hot/critical JIRAs and new feature development
(with JIRA links so that topics of interest are accessible)? 
> ThanksAnuj
>  On Thu, 10 Nov, 2016 at 7:09 AM, Nate McCall<> wrote:  I like
the idea of a goal-based approach. I think that would make
> coming to a consensus a bit easier particularly if a larger number of
> people are involved.
> On Tue, Nov 8, 2016 at 8:04 PM, Dikang Gu <> wrote:
>> My 2 cents. I'm wondering is it a good idea to have some high level goals
>> for the major release? For example, the goals could be something like:
>> 1. Improve the scalability/reliability/performance by X%.
>> 2. Add Y new features (feature A, B, C, D...).
>> 3. Fix Z known issues  (issue A, B, C, D...).
>> I feel If we can have the high level goals, it would be easy to pick the
>> jiras to be included in the release.
>> Does it make sense?
>> Thanks
>> Dikang.
>> On Mon, Nov 7, 2016 at 11:22 AM, Oleksandr Petrov <
>>> wrote:
>>> Recently there was another discussion on documentation and comments [1]
>>> On one hand, documentation and comments will help newcomers to familiarise
>>> themselves with the codebase. On the other - one may get up to speed by
>>> reading the code and adding some docs. Such things may require less
>>> oversight and can play some role in improving diversity / increasing an
>>> amount of involved people.
>>> Same thing with tests. There are some areas where tests need some
>>> refactoring / improvements, or even just splitting them from one file to
>>> multiple. It's a good way to experience the process and get involved into
>>> discussion.
>>> For that, we could add some issues with subtasks (just a few for starters)
>>> or even just a wiki page with a doc/test wishlist where everyone could add
>>> a couple of points.
>>> Docs and tests could be used in addition to lhf issues, helping people,
>>> having comprehensive and quick process and everything else that was
>>> mentioned in this thread.
>>> Thank you.
>>> [1]
>>> On Mon, Nov 7, 2016 at 5:38 PM Aleksey Yeschenko <>
>>> wrote:
>>>> Agreed.
>>>> --
>>>> AY
>>>> On 7 November 2016 at 16:38:07, Jeff Jirsa (
>>>> wrote:
>>>> ‘Accepted’ JIRA status seems useful, but would encourage something more
>>>> explicit like ‘Concept Accepted’ or similar to denote that the concept
>>>> agreed upon, but the actual patch itself may not be accepted yet.
>>>> /bikeshed.
>>>> On 11/7/16, 2:56 AM, "Ben Slater" <> wrote:
>>>>> Thanks Dave. The shepherd concept sounds a lot like I had in mind (and
>>>>> better name).
>>>>> One other thing I noted from the Mesos process - they have an “Accepted”
>>>>> jira status that comes after open and means “at least one Mesos
>>> developer
>>>>> thought that the ideas proposed in the issue are worth pursuing
>>> further”.
>>>>> Might also be something to consider as part of a process like this?
>>>>> Cheers
>>>>> Ben
>>>>> On Mon, 7 Nov 2016 at 09:37 Dave Lester <> wrote:
>>>>>> Hi Ben,
>>>>>> A few ideas to add to your suggestions [inline]:
>>>>>> On 2016-11-06 13:51 (-0800), Ben Slater <
>>> hAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=
>>> 0Ynrto5MaNdgc2fOUtxv50ouikBU_P7VEv6KNub9Bhk&s=
>>> MAZTdq4wfrTiqh7nImEMcFWtTrsixRFOX7Pi0SKqQv0&e=
>>>>>> wrote:
>>>>>>> Hi All,
>>>>>>> I thought I would add a couple of observations and suggestions
>>>> someone
>>>>>>> who has both personally made my first contributions to the project
>>> in
>>>> the
>>>>>>> last few months and someone in a leadership role in an organisation
>>>>>>> (Instaclustr) that is feeling it’s way through increasing our
>>>>>> contributions
>>>>>>> as an organisation.
>>>>>>> Firstly - an observation on contribution experience and what
I think
>>>> is
>>>>>>> likely to make people want to contribute again:
>>>>>>> 1) The worst thing that can happen is for your contribution to
>>>>>>> completely ignored.
>>>>>>> 2) The second worst thing is for it to be rejected without a
>>>>>>> explanation (that you can learn from) or with hostility.
>>>>>>> 3) Having it rejected with a good reason is not a bad thing (you
>>>> learn)
>>>>>>> 4) Having it accepted is, of course, the best!
>>>>>>> With this as a background I would suggest a couple of thing that
>>> help
>>>>>> make
>>>>>>> sure (3) and (4) are always more common that (1) and (2) (good
>>>> outcomes
>>>>>> are
>>>>>>> probably more common than bad at the moment but we’ve experienced
>>> all
>>>>>> four
>>>>>>> scenarios in the last few months):
>>>>>>> 1) I think some process of assigning a committer of a “sponsor”
of a
>>>>>> change
>>>>>>> (which would probably mean committers volunteering) before it
>>>> commences
>>>>>>> would be useful. You can kind of do this at the moment by creating
>>>> JIRA
>>>>>>> and asking for comment but I think the process is a bit unclear
>>> a
>>>> bit
>>>>>>> intimidating for people starting off and it would be nice to
>>> who
>>>> was
>>>>>>> your primary reviewer for a piece of work. (Or maybe this process
>>> does
>>>>>>> exist and I don’t know about.)
>>>>>> I've seen this approach before and it that can reduce ambiguity on
>>>>>> state of contributions; the Apache Mesos project has a shepherding
>>>> system
>>>>>> similar to this. I would shy away from the term "sponsor" since it
>>> could
>>>>>> infer a non-voluntary relationship between contributors and volunteer
>>>>>> committers.
>>>>>> From the Mesos docs: "Find a shepherd to collaborate on your patch.
>>>>>> shepherd is a Mesos committer that will work with you to give you
>>>> feedback
>>>>>> on your proposed design, and to eventually commit your change into
>>>>>> Mesos source tree." More info on how they approach this is in both
>>> their
>>>>>> newbie guide:
>>> apache.org_documentation_newbie-2Dguide_&d=DgIFaQ&c=
>>> 08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=
>>> yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=
>>> 0Ynrto5MaNdgc2fOUtxv50ouikBU_P7VEv6KNub9Bhk&s=
>>> MB2cGSGm5RHMnWWRGLZ4h8P7Mo0Rvm6k5mW2yhQVZ7U&e=
>>>> , and
>>>>>> submitting a patch guide:
>>> apache.org_documentation_latest_submitting-2Da-2Dpatch_&d=DgIFaQ&c=
>>> 08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=
>>> yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=
>>> 0Ynrto5MaNdgc2fOUtxv50ouikBU_P7VEv6KNub9Bhk&s=PSj3seUwzL_USxWvdvqlMKrU_
>>> yfBXpOSQ4XfjdhnmO0&e=
>>>> .
>>>>>> In practice, there are some limitations and risks to this model.
>>>> one,
>>>>>> a shepherding process is not a substitute for the Apache Way, and
>>>>>> critical that design decisions and reviews are still done in the
>>>>>> Additionally, in projects where a single organization has
>>>> disproportionate
>>>>>> representation at the committer level it can create bottlenecks if
>>>> features
>>>>>> are a lower priority for those orgs (while not malicious, it may
>>>> that
>>>>>> certain patches are shepherded while others are ignored). It's
>>> possible
>>>> to
>>>>>> work within these limitations, especially in cases where the community
>>>> is
>>>>>> having healthy conversations about the direction and roadmap for
>>>>>> project (similar to the original thread).
>>>>>> If this is something the project would like to push forward, I'd
>>>> suggest a
>>>>>> committer vote to ensure there's sufficient buy-in.
>>>>>>> 2) I think the “how to contribute” docs could emphasise activities
>>>> other
>>>>>>> than creating new features as a great place to
>>> 08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=
>>> yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=
>>> 0Ynrto5MaNdgc2fOUtxv50ouikBU_P7VEv6KNub9Bhk&s=
>>> gN1SaWPyD2s998oRRQXN0ayhhOmSWnIMFR8PLiyw7tc&e=
>>>> seems that
>>>>>> review,
>>>>>>> testing and doco could all do with more hands (as on just about
>>>>>>> project). So, encouraging this as a way to start on the project
>>> might
>>>>>> help
>>>>>>> to get some more bandwidth in this area rather than people creating
>>>>>> patches
>>>>>>> that the committers don’t have bandwidth to review. I would
be happy
>>>> to
>>>>>>> draft an update to the docs including some of this if people
>>>> it’s a
>>>>>>> good idea.
>>>>>> This would be great. If you make changes here and create a JIRA ticket
>>>>>> associated with it, please add me to the ticket and I'll happily
>>> provide
>>>>>> feedback.
>>>>>> Dave
>>>>>>> Cheers
>>>>>>> Ben
>>>>>>> On Sun, 6 Nov 2016 at 06:40 Michael Shuler <>
>>>>>> wrote:
>>>>>>>> On 11/04/2016 06:43 PM, Jeff Beck wrote:
>>>>>>>>> I run the local Cassandra User Group and I would love
to help
>>> get
>>>> the
>>>>>>>>> community more involved. I would propose holding a night
to add
>>>>>> patches
>>>>>>>> to
>>>>>>>>> Cassandra some will be simple things like making sure
>>> asserts
>>>>>> have
>>>>>>>>> proper messages with them etc, but some may be slightly
>>>> The
>>>>>> goal
>>>>>>>>> being to just get people used to the process, to help
make this
>>> a
>>>>>> success
>>>>>>>>> it would be great if we could have support on getting
>>> patches
>>>> we
>>>>>>>> submit
>>>>>>>>> at least looked at briefly in 1 month. That timeframe
allows us
>>> to
>>>>>> talk
>>>>>>>>> about it at the next meetup and show people their contributions
>>>> even
>>>>>>>> small
>>>>>>>>> ones are valued.
>>>>>>>> This is a great idea and I have a suggestion that would benefit
>>> the
>>>>>>>> project as a whole, as well as help new people get used to
>>>>>>>> development process:
>>>>>>>> Document the process.
>>>>>>>> Recently, the project included documentation in the source
>>>> under
>>>>>>>> `doc/`, which is directly presented at
>>> cassandra.apache.org_doc_latest_&d=DgIFaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kq
>>> hAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=
>>> 0Ynrto5MaNdgc2fOUtxv50ouikBU_P7VEv6KNub9Bhk&s=
>>> nobuS9ngFj52bmS0NaFnZKuZzWut6TPN0yohfHDioXs&e=
>>>>>>>> The red bar at the top has a link to contributions, there
are docs
>>>>>> about
>>>>>>>> getting started with development, reviewing patches, and
>>> If
>>>>>>>> those docs need updating for better readability, missing
>>>> hints
>>>>>>>> for new contributors, etc. I think this could be one of the
>>>>>>>> valuable contributions a user group could make, as well as
>>>> some
>>>>>>>> initial experience in the development process itself.
>>>>>>>>> Before we did this night I would probably dig through
>>> tickets
>>>>>> and
>>>>>>>> get
>>>>>>>>> an example list going and any feedback notes on making
>>> process
>>>>>> easier
>>>>>>>>> would be great.
>>>>>>>> Some more ideas:
>>>>>>>> The user group members could get themselves set up in JIRA
>>> order
>>>> to
>>>>>>>> review one another's patches, get a feel for testing patches,
>>>>>> through
>>>>>>>> the motions of *how* to contribute improvements, and again,
>>>>>>>> documentation change patches up in JIRA, so everyone benefits
>>>> your
>>>>>>>> experiences, as the group works through the process.
>>>>>>>>> Generally if there is anything you need from the meetups
ask I
>>>> know I
>>>>>>>> will
>>>>>>>>> do my best to get the local group to support things.
>>>>>>>> Thanks for the interest!
>>>>>>>> --
>>>>>>>> Kind regards,
>>>>>>>> Michael
>>> --
>>> Alex Petrov
>> --
>> Dikang  

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message