Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Eric Evans]

On Sun, Nov 13, 2016 at 1:13 AM, Ben Slater  wrote:
> For anyone that’s interested, I’ve submitted my doc changes for point 2
> below (emphasising contributions other than new features) here:
> https://issues.apache.org/jira/browse/CASSANDRA-12906
>
> I haven’t added anything about the sponsor/shepherd idea as doesn’t seem to
> be agreed at this point.
>
> Cheers
> Ben
>
> On Mon, 7 Nov 2016 at 09:34 Nate McCall  wrote:
>
>> Ben,
>> Thank you for providing two thoughtful, concrete recommendations.
>> There is some good feedback in general on this thread, but I'm calling
>> Ben's response out because point #1 is important to discuss and point
>> #2 is immediately actionable.
>>
>> > 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 a JIRA
>> > and asking for comment but I think the process is a bit unclear and a bit
>> > intimidating for people starting off and it would be nice to know who was
>> > your primary reviewer for a piece of work. (Or maybe this process does
>> > exist and I don’t know about.)
>>
>> This is a good idea, but it assumes a single point triage and resource
>> management that we don't really have right now.
>>
>> For the history of the project, we had triage in the form of sponsored
>> resources flighting most of the new issues. This has made the rest of
>> us complacent. It's probably the most immediate thing to fix and I
>> don't know how to do that.
>>
>> Does anybody have any recommendations about ASF projects doing this
>> effectively? Note that the folks from DS engineering are still heavily
>> involved and I very much thank them for that, but diversifying is the
>> only way to get us over our complacency.
>>
>> > 2) I think the “how to contribute” docs could emphasise activities other
>> > than creating new features as a great place to start.It seems that
>> review,
>> > testing and doco could all do with more hands (as on just about any
>> > 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 think it’s a
>> > good idea.
>>
>> Also a good idea and much more accessible/easily fixable.
>>
>> We will gladly look at any doc updates for this, looping in the
>> broader community once published (this last part being key - I'm
>> afraid if we ask for help too early, we'll get tons of interest to
>> which we cannot reply and then be in even worse shape).
>>
>> -Nate
>>



-- 
Eric Evans
john.eric.ev...@gmail.com

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Ben Slater]

For anyone that’s interested, I’ve submitted my doc changes for point 2
below (emphasising contributions other than new features) here:
https://issues.apache.org/jira/browse/CASSANDRA-12906

I haven’t added anything about the sponsor/shepherd idea as doesn’t seem to
be agreed at this point.

Cheers
Ben

On Mon, 7 Nov 2016 at 09:34 Nate McCall  wrote:

> Ben,
> Thank you for providing two thoughtful, concrete recommendations.
> There is some good feedback in general on this thread, but I'm calling
> Ben's response out because point #1 is important to discuss and point
> #2 is immediately actionable.
>
> > 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 a JIRA
> > and asking for comment but I think the process is a bit unclear and a bit
> > intimidating for people starting off and it would be nice to know who was
> > your primary reviewer for a piece of work. (Or maybe this process does
> > exist and I don’t know about.)
>
> This is a good idea, but it assumes a single point triage and resource
> management that we don't really have right now.
>
> For the history of the project, we had triage in the form of sponsored
> resources flighting most of the new issues. This has made the rest of
> us complacent. It's probably the most immediate thing to fix and I
> don't know how to do that.
>
> Does anybody have any recommendations about ASF projects doing this
> effectively? Note that the folks from DS engineering are still heavily
> involved and I very much thank them for that, but diversifying is the
> only way to get us over our complacency.
>
> > 2) I think the “how to contribute” docs could emphasise activities other
> > than creating new features as a great place to start.It seems that
> review,
> > testing and doco could all do with more hands (as on just about any
> > 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 think it’s a
> > good idea.
>
> Also a good idea and much more accessible/easily fixable.
>
> We will gladly look at any doc updates for this, looping in the
> broader community once published (this last part being key - I'm
> afraid if we ask for help too early, we'll get tons of interest to
> which we cannot reply and then be in even worse shape).
>
> -Nate
>

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Josh McKenzie]

>
> 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.


I've personally found that attaching a design doc for moderate to large
efforts with a combination of use-case, problem statement, and current
design helps give that snapshot and keep people on the same page. Nothing
too burdensome, just a page or so to summarize the pages and pages of JIRA
conversations and where we ended up.

If someone wants to understand the path on how things got to their current
point, JIRA comments get you there.

On Sat, Nov 12, 2016 at 2:23 AM, Anuj Wadehra <
anujw_2...@yahoo.co.in.invalid> wrote:

> 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.
>
>
> ThanksAnuj
>
>
>
>
> On Friday, 11 November 2016 1:40 AM, Jeremy Hanna <
> jeremy.hanna1...@gmail.com> 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] https://wiki.apache.org/cassandra/HowToContribute <
> https://wiki.apache.org/cassandra/HowToContribute>
> [2] https://issues.apache.org/jira/secure/IssueNavigator.
> jspa?reset=true=project+=+12310865+AND+labels+
> =+lhf+AND+status+!=+resolved  jira/secure/IssueNavigator.jspa?reset=true=
> project+=+12310865+AND+labels+=+lhf+AND+status+!=+resolved>
>
> > 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 

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Anuj Wadehra]

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.


ThanksAnuj


 

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] https://wiki.apache.org/cassandra/HowToContribute 

[2] 
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true=project+=+12310865+AND+labels+=+lhf+AND+status+!=+resolved
 


> 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 

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Jeremy Hanna]

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] https://wiki.apache.org/cassandra/HowToContribute 

[2] 
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true=project+=+12310865+AND+labels+=+lhf+AND+status+!=+resolved
 


> 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 <
>> oleksandr.pet...@gmail.com> 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]
>>> 

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Anuj Wadehra]

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 <
> oleksandr.pet...@gmail.com> 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]
>> http://mail-archives.apache.org/mod_mbox/cassandra-dev/201605.mbox/%
>> 3ccakkz8q088ojbvhycyz2_2eotqk4y-svwiwksinpt6rr9pop...@mail.gmail.com%3E
>>
>> On Mon, Nov 7, 2016 at 5:38 PM Aleksey Yeschenko 
>> wrote:
>>
>> > Agreed.
>> >
>> > --
>> > AY
>> >
>> > On 7 November 2016 at 16:38:07, Jeff Jirsa (jeff.ji...@crowdstrike.com)
>> > wrote:
>> >
>> > ‘Accepted’ JIRA status seems useful, but would encourage something more
>> > explicit like ‘Concept Accepted’ or similar to denote that the concept is
>> > 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 a
>> > >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?
>> > >
>> 

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Nate McCall]

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 <
> oleksandr.pet...@gmail.com> 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]
>> http://mail-archives.apache.org/mod_mbox/cassandra-dev/201605.mbox/%
>> 3ccakkz8q088ojbvhycyz2_2eotqk4y-svwiwksinpt6rr9pop...@mail.gmail.com%3E
>>
>> On Mon, Nov 7, 2016 at 5:38 PM Aleksey Yeschenko 
>> wrote:
>>
>> > Agreed.
>> >
>> > --
>> > AY
>> >
>> > On 7 November 2016 at 16:38:07, Jeff Jirsa (jeff.ji...@crowdstrike.com)
>> > wrote:
>> >
>> > ‘Accepted’ JIRA status seems useful, but would encourage something more
>> > explicit like ‘Concept Accepted’ or similar to denote that the concept is
>> > 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 a
>> > >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 <
>> > https://urldefense.proofpoint.com/v2/url?u=http-3A__ben.
>> slater-40instaclustr.com=DgIFaQ=08AGY6txKsvMOP6lYkHQpPMRA1U6kq
>> hAwGa8-0QCg3M=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow=
>> 0Ynrto5MaNdgc2fOUtxv50ouikBU_P7VEv6KNub9Bhk=
>> MAZTdq4wfrTiqh7nImEMcFWtTrsixRFOX7Pi0SKqQv0=
>> > >
>> > >> wrote:
>> > >> > Hi All,
>> > >> >
>> > >> > I thought I would add a couple of observations and suggestions as
>> > 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 be
>> > >> > completely ignored.
>> > >> > 2) The second worst thing is for it to be rejected without a good
>> > >> > 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
>> > 

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Dikang Gu]

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 <
oleksandr.pet...@gmail.com> 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]
> http://mail-archives.apache.org/mod_mbox/cassandra-dev/201605.mbox/%
> 3ccakkz8q088ojbvhycyz2_2eotqk4y-svwiwksinpt6rr9pop...@mail.gmail.com%3E
>
> On Mon, Nov 7, 2016 at 5:38 PM Aleksey Yeschenko 
> wrote:
>
> > Agreed.
> >
> > --
> > AY
> >
> > On 7 November 2016 at 16:38:07, Jeff Jirsa (jeff.ji...@crowdstrike.com)
> > wrote:
> >
> > ‘Accepted’ JIRA status seems useful, but would encourage something more
> > explicit like ‘Concept Accepted’ or similar to denote that the concept is
> > 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 a
> > >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 <
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__ben.
> slater-40instaclustr.com=DgIFaQ=08AGY6txKsvMOP6lYkHQpPMRA1U6kq
> hAwGa8-0QCg3M=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow=
> 0Ynrto5MaNdgc2fOUtxv50ouikBU_P7VEv6KNub9Bhk=
> MAZTdq4wfrTiqh7nImEMcFWtTrsixRFOX7Pi0SKqQv0=
> > >
> > >> wrote:
> > >> > Hi All,
> > >> >
> > >> > I thought I would add a couple of observations and suggestions as
> > 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 be
> > >> > completely ignored.
> > >> > 2) The second worst thing is for it to be rejected without a good
> > >> > 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 a
> > JIRA
> > >> > and asking for comment but I think the process is a bit unclear and
> a
> > bit
> > >> > intimidating for people starting off and it would be nice to know
> who
> > was
> > >> > your primary reviewer for a piece of work. (Or maybe this process
> does
> > >> > exist 

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Oleksandr Petrov]

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]
http://mail-archives.apache.org/mod_mbox/cassandra-dev/201605.mbox/%3ccakkz8q088ojbvhycyz2_2eotqk4y-svwiwksinpt6rr9pop...@mail.gmail.com%3E

On Mon, Nov 7, 2016 at 5:38 PM Aleksey Yeschenko  wrote:

> Agreed.
>
> --
> AY
>
> On 7 November 2016 at 16:38:07, Jeff Jirsa (jeff.ji...@crowdstrike.com)
> wrote:
>
> ‘Accepted’ JIRA status seems useful, but would encourage something more
> explicit like ‘Concept Accepted’ or similar to denote that the concept is
> 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 a
> >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 <
> https://urldefense.proofpoint.com/v2/url?u=http-3A__ben.slater-40instaclustr.com=DgIFaQ=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow=0Ynrto5MaNdgc2fOUtxv50ouikBU_P7VEv6KNub9Bhk=MAZTdq4wfrTiqh7nImEMcFWtTrsixRFOX7Pi0SKqQv0=
> >
> >> wrote:
> >> > Hi All,
> >> >
> >> > I thought I would add a couple of observations and suggestions as
> 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 be
> >> > completely ignored.
> >> > 2) The second worst thing is for it to be rejected without a good
> >> > 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 a
> JIRA
> >> > and asking for comment but I think the process is a bit unclear and a
> bit
> >> > intimidating for people starting off and it would be nice to know 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 the
> >> 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. A
> >> 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 the
> >> Mesos source tree." More info on how they approach this is in both their
> >> newbie guide:
> 

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Aleksey Yeschenko]

Agreed.

-- 
AY

On 7 November 2016 at 16:38:07, Jeff Jirsa (jeff.ji...@crowdstrike.com) wrote:

‘Accepted’ JIRA status seems useful, but would encourage something more 
explicit like ‘Concept Accepted’ or similar to denote that the concept is 
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 a  
>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 
>> >  >  
>> wrote:  
>> > Hi All,  
>> >  
>> > I thought I would add a couple of observations and suggestions as 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 be  
>> > completely ignored.  
>> > 2) The second worst thing is for it to be rejected without a good  
>> > 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 a JIRA  
>> > and asking for comment but I think the process is a bit unclear and a bit  
>> > intimidating for people starting off and it would be nice to know 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 the  
>> 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. A  
>> 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 the  
>> Mesos source tree." More info on how they approach this is in both their  
>> newbie guide: 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__mesos.apache.org_documentation_newbie-2Dguide_=DgIFaQ=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow=0Ynrto5MaNdgc2fOUtxv50ouikBU_P7VEv6KNub9Bhk=MB2cGSGm5RHMnWWRGLZ4h8P7Mo0Rvm6k5mW2yhQVZ7U=
>>  , and  
>> submitting a patch guide:  
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__mesos.apache.org_documentation_latest_submitting-2Da-2Dpatch_=DgIFaQ=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow=0Ynrto5MaNdgc2fOUtxv50ouikBU_P7VEv6KNub9Bhk=PSj3seUwzL_USxWvdvqlMKrU_yfBXpOSQ4XfjdhnmO0=
>>  .  
>>  
>> In practice, there are some limitations and risks to this model. For one,  
>> a shepherding process is not a substitute for the Apache Way, and it's  
>> critical that design decisions and reviews are still done in the open.  
>> 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 mean 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 

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Jeff Jirsa]

‘Accepted’ JIRA status seems useful, but would encourage something more 
explicit like ‘Concept Accepted’ or similar to denote that the concept is 
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 a
>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 
>> >  >
>> wrote:
>> > Hi All,
>> >
>> > I thought I would add a couple of observations and suggestions as 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 be
>> > completely ignored.
>> > 2) The second worst thing is for it to be rejected without a good
>> > 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 a JIRA
>> > and asking for comment but I think the process is a bit unclear and a bit
>> > intimidating for people starting off and it would be nice to know 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 the
>> 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. A
>> 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 the
>> Mesos source tree." More info on how they approach this is in both their
>> newbie guide: 
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__mesos.apache.org_documentation_newbie-2Dguide_=DgIFaQ=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow=0Ynrto5MaNdgc2fOUtxv50ouikBU_P7VEv6KNub9Bhk=MB2cGSGm5RHMnWWRGLZ4h8P7Mo0Rvm6k5mW2yhQVZ7U=
>>  , and
>> submitting a patch guide:
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__mesos.apache.org_documentation_latest_submitting-2Da-2Dpatch_=DgIFaQ=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow=0Ynrto5MaNdgc2fOUtxv50ouikBU_P7VEv6KNub9Bhk=PSj3seUwzL_USxWvdvqlMKrU_yfBXpOSQ4XfjdhnmO0=
>>  .
>>
>> In practice, there are some limitations and risks to this model. For one,
>> a shepherding process is not a substitute for the Apache Way, and it's
>> critical that design decisions and reviews are still done in the open.
>> 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 mean 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 the
>> 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 

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Ben Slater]

Thanks Dave. The shepherd concept sounds a lot like I had in mind (and a
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 
> wrote:
> > Hi All,
> >
> > I thought I would add a couple of observations and suggestions as 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 be
> > completely ignored.
> > 2) The second worst thing is for it to be rejected without a good
> > 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 a JIRA
> > and asking for comment but I think the process is a bit unclear and a bit
> > intimidating for people starting off and it would be nice to know 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 the
> 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. A
> 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 the
> Mesos source tree." More info on how they approach this is in both their
> newbie guide: http://mesos.apache.org/documentation/newbie-guide/, and
> submitting a patch guide:
> http://mesos.apache.org/documentation/latest/submitting-a-patch/.
>
> In practice, there are some limitations and risks to this model. For one,
> a shepherding process is not a substitute for the Apache Way, and it's
> critical that design decisions and reviews are still done in the open.
> 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 mean 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 the
> 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 start.It seems that
> review,
> > testing and doco could all do with more hands (as on just about any
> > 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 think 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 some 

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Dave Lester]

Hi Ben,

A few ideas to add to your suggestions [inline]:

On 2016-11-06 13:51 (-0800), Ben Slater  wrote: 
> Hi All,
> 
> I thought I would add a couple of observations and suggestions as 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 be
> completely ignored.
> 2) The second worst thing is for it to be rejected without a good
> 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 a JIRA
> and asking for comment but I think the process is a bit unclear and a bit
> intimidating for people starting off and it would be nice to know 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 the 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. A 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 the Mesos source 
>tree." More info on how they approach this is in both their newbie guide: 
>http://mesos.apache.org/documentation/newbie-guide/, and submitting a patch 
>guide: http://mesos.apache.org/documentation/latest/submitting-a-patch/.

In practice, there are some limitations and risks to this model. For one, a 
shepherding process is not a substitute for the Apache Way, and it's critical 
that design decisions and reviews are still done in the open. 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 mean 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 the 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 start.It seems that review,
> testing and doco could all do with more hands (as on just about any
> 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 think 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 some asserts have
> > > proper messages with them etc, but some may be slightly larger. 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 the 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 the
> > 

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Nate McCall]

Ben,
Thank you for providing two thoughtful, concrete recommendations.
There is some good feedback in general on this thread, but I'm calling
Ben's response out because point #1 is important to discuss and point
#2 is immediately actionable.

> 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 a JIRA
> and asking for comment but I think the process is a bit unclear and a bit
> intimidating for people starting off and it would be nice to know who was
> your primary reviewer for a piece of work. (Or maybe this process does
> exist and I don’t know about.)

This is a good idea, but it assumes a single point triage and resource
management that we don't really have right now.

For the history of the project, we had triage in the form of sponsored
resources flighting most of the new issues. This has made the rest of
us complacent. It's probably the most immediate thing to fix and I
don't know how to do that.

Does anybody have any recommendations about ASF projects doing this
effectively? Note that the folks from DS engineering are still heavily
involved and I very much thank them for that, but diversifying is the
only way to get us over our complacency.

> 2) I think the “how to contribute” docs could emphasise activities other
> than creating new features as a great place to start.It seems that review,
> testing and doco could all do with more hands (as on just about any
> 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 think it’s a
> good idea.

Also a good idea and much more accessible/easily fixable.

We will gladly look at any doc updates for this, looping in the
broader community once published (this last part being key - I'm
afraid if we ask for help too early, we'll get tons of interest to
which we cannot reply and then be in even worse shape).

-Nate

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Ben Slater]

Hi All,

I thought I would add a couple of observations and suggestions as 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 be
completely ignored.
2) The second worst thing is for it to be rejected without a good
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 a JIRA
and asking for comment but I think the process is a bit unclear and a bit
intimidating for people starting off and it would be nice to know who was
your primary reviewer for a piece of work. (Or maybe this process does
exist and I don’t know about.)
2) I think the “how to contribute” docs could emphasise activities other
than creating new features as a great place to start.It seems that review,
testing and doco could all do with more hands (as on just about any
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 think it’s a
good idea.

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 some asserts have
> > proper messages with them etc, but some may be slightly larger. 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 the 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 the
> development process:
>
>   Document the process.
>
> Recently, the project included documentation in the source tree under
> `doc/`, which is directly presented at
> https://cassandra.apache.org/doc/latest/
>
> The red bar at the top has a link to contributions, there are docs about
> getting started with development, reviewing patches, and testing. If
> those docs need updating for better readability, missing steps, hints
> for new contributors, etc. I think this could be one of the most
> valuable contributions a user group could make, as well as provide some
> initial experience in the development process itself.
>
> > Before we did this night I would probably dig through some tickets and
> get
> > an example list going and any feedback notes on making the process easier
> > would be great.
>
> Some more ideas:
> The user group members could get themselves set up in JIRA in order to
> review one another's patches, get a feel for testing patches, go through
> the motions of *how* to contribute improvements, and again, get
> documentation change patches up in JIRA, so everyone benefits from 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
>

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Michael Shuler]

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 some asserts have
> proper messages with them etc, but some may be slightly larger. 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 the 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 the
development process:

  Document the process.

Recently, the project included documentation in the source tree under
`doc/`, which is directly presented at
https://cassandra.apache.org/doc/latest/

The red bar at the top has a link to contributions, there are docs about
getting started with development, reviewing patches, and testing. If
those docs need updating for better readability, missing steps, hints
for new contributors, etc. I think this could be one of the most
valuable contributions a user group could make, as well as provide some
initial experience in the development process itself.

> Before we did this night I would probably dig through some tickets and get
> an example list going and any feedback notes on making the process easier
> would be great.

Some more ideas:
The user group members could get themselves set up in JIRA in order to
review one another's patches, get a feel for testing patches, go through
the motions of *how* to contribute improvements, and again, get
documentation change patches up in JIRA, so everyone benefits from 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

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Edward Capriolo]

On Sat, Nov 5, 2016 at 9:19 AM, Benedict Elliott Smith 
wrote:

> Hi Ed,
>
> I would like to try and clear up what I perceive to be some
> misunderstandings.
>
> Aleksey is relating that for *complex* tickets there are desperately few
> people with the expertise necessary to review them.  In some cases it can
> amount to several weeks' work, possibly requiring multiple people, which is
> a huge investment.  EPaxos is an example where its complexity likely needs
> multiple highly qualified reviewers.
>
> Simpler tickets on the other hand languish due to poor incentives - they
> aren't sexy for volunteers, and aren't important for the corporately
> sponsored contributors, who also have finite resources.  Nobody *wants* to
> do them.
>
> This does contribute to an emergent lack of diversity in the pool of
> contributors, but it doesn't discount Aleksey's point.  We need to find a
> way forward that handles both of these concerns.
>
> Sponsored contributors have invested time into efforts to expand the
> committer pool before, though they have universally failed.  Efforts like
> the "low hanging fruit squad" seem like a good idea that might payoff, with
> the only risk being the cloud hanging over the project right now.  I think
> constructive engagement with potential sponsors is probably the way
> forward.
>
> (As an aside, the policy on test coverage was historically very poor
> indeed, but is I believe much stronger today - try not to judge current
> behaviours on those of the past)
>
>
> On 5 November 2016 at 00:05, Edward Capriolo 
> wrote:
>
> > "I’m sure users running Cassandra in production would prefer actual
> proper
> > reviews to non-review +1s."
> >
> > Again, you are implying that only you can do a proper job.
> >
> > Lets be specific here: You and I are working on this one:
> >
> > https://issues.apache.org/jira/browse/CASSANDRA-10825
> >
> > Now, Ariel reported there was no/low code coverage. I went looking a the
> > code and found a problem.
> >
> > If someone were to merge this: I would have more incentive to look for
> > other things, then I might find more bugs and improvements. If this
> process
> > keeps going, I would naturally get exposed to more of the code. Finally
> in
> > maybe (I don't know in 10 or 20 years) I could become one of these
> > specialists.
> >
> > Lets peal this situation apart:
> >
> > https://issues.apache.org/jira/browse/CASSANDRA-10825
> >
> > "If you grep test/src and cassandra-dtest you will find that the string
> > OverloadedException doesn't appear anywhere."
> >
> > Now let me flip this situation around:
> >
> > "I'm sure the users running Cassandra in production would prefer proper
> > coding practice like writing unit and integration test to rubber stamp
> > merges"
> >
> > When the shoe is on the other foot it does not feel so nice.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Fri, Nov 4, 2016 at 7:08 PM, Aleksey Yeschenko 
> > wrote:
> >
> > > Dunno. A sneaky correctness or data corruption bug. A performance
> > > regression. Or something that can take a node/cluster down.
> > >
> > > Of course no process is bullet-proof. The purpose of review is to
> > minimise
> > > the odds of such a thing happening.
> > >
> > > I’m sure users running Cassandra in production would prefer actual
> proper
> > > reviews to non-review +1s.
> > >
> > > --
> > > AY
> > >
> > > On 4 November 2016 at 23:03:23, Edward Capriolo (edlinuxg...@gmail.com
> )
> > > wrote:
> > >
> > > I feel that is really standing up on a soap box. What would be the
> worst
> > > thing that happens here
> >
>

Benedict,

Well said. I think we both see a similar way forward.

"Sponsored contributors have invested time into efforts to expand the
committer pool before, though they have universally failed."

Lets talk about this. I am following a number of tickets. Take for example
this one.

https://issues.apache.org/jira/browse/CASSANDRA-12649

September 19th: User submits a patch along with a clear rational. (It is
right in the description of the ticket):

October 19th: (me) +1 (non binding) users with unpredictable batch sizes
tend to also have gc problems and this would aid in insight.

October 28th: Someone else: Would be nice to see this committed. We have
seen a lot of users mistakenly batch against multiple partitions.

Note: 3 people have agreed they see this as useful.

November 1st
So rebased the patch on 3.X and one of the added unit tests actually
exposed a bug that was just introduced in CASSANDRA-12060
. Attached new,
rebased patch here, however doubtful it's going to make it into 3.10.

Also raised CASSANDRA-12867
 to cover the bug.

Note: Did a test in this patch uncover something else?

yesterday

I discussed the patch with Aleksey Yeschenko

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Jake Luciani]

Hi Tyler,

There is a nice guide now in the docs on how to contribute[1].
If you try it and find holes you can also help by contributing to those
docs.

-Jake
[1]: http://cassandra.apache.org/doc/latest/development/index.html

On Sat, Nov 5, 2016 at 11:08 AM, Tyler Tolley 
wrote:

> Just want to weigh in my 2 cents. I've been following the dev list for
> quite a while and wanted to contribute. As I approached trying to handle
> some lhf, I couldn't find any instructions on how to check out, build, test
> or any guidance on coding standards and best practices. Maybe these existed
> and were hard to find, maybe I was too inexperienced to understand them.
> Either way, given my experience at the time, I wasn't able to contribute
> and never came back.
>
> If that hasn't changed, that's where I would start to get more people
> contributing. I realize the project is pretty complex, but the more we can
> lower the bar of entry, the more people will contribute. This doesn't help
> solve the problem of more people to review big changes right away, but
> perhaps it will free experienced contributors up to help with those. Again,
> just my 2 cents.
>
> On Sat, Nov 5, 2016, 7:19 AM Benedict Elliott Smith 
> wrote:
>
> > Hi Ed,
> >
> > I would like to try and clear up what I perceive to be some
> > misunderstandings.
> >
> > Aleksey is relating that for *complex* tickets there are desperately few
> > people with the expertise necessary to review them.  In some cases it can
> > amount to several weeks' work, possibly requiring multiple people, which
> is
> > a huge investment.  EPaxos is an example where its complexity likely
> needs
> > multiple highly qualified reviewers.
> >
> > Simpler tickets on the other hand languish due to poor incentives - they
> > aren't sexy for volunteers, and aren't important for the corporately
> > sponsored contributors, who also have finite resources.  Nobody *wants*
> to
> > do them.
> >
> > This does contribute to an emergent lack of diversity in the pool of
> > contributors, but it doesn't discount Aleksey's point.  We need to find a
> > way forward that handles both of these concerns.
> >
> > Sponsored contributors have invested time into efforts to expand the
> > committer pool before, though they have universally failed.  Efforts like
> > the "low hanging fruit squad" seem like a good idea that might payoff,
> with
> > the only risk being the cloud hanging over the project right now.  I
> think
> > constructive engagement with potential sponsors is probably the way
> > forward.
> >
> > (As an aside, the policy on test coverage was historically very poor
> > indeed, but is I believe much stronger today - try not to judge current
> > behaviours on those of the past)
> >
> >
> > On 5 November 2016 at 00:05, Edward Capriolo 
> > wrote:
> >
> > > "I’m sure users running Cassandra in production would prefer actual
> > proper
> > > reviews to non-review +1s."
> > >
> > > Again, you are implying that only you can do a proper job.
> > >
> > > Lets be specific here: You and I are working on this one:
> > >
> > > https://issues.apache.org/jira/browse/CASSANDRA-10825
> > >
> > > Now, Ariel reported there was no/low code coverage. I went looking a
> the
> > > code and found a problem.
> > >
> > > If someone were to merge this: I would have more incentive to look for
> > > other things, then I might find more bugs and improvements. If this
> > process
> > > keeps going, I would naturally get exposed to more of the code. Finally
> > in
> > > maybe (I don't know in 10 or 20 years) I could become one of these
> > > specialists.
> > >
> > > Lets peal this situation apart:
> > >
> > > https://issues.apache.org/jira/browse/CASSANDRA-10825
> > >
> > > "If you grep test/src and cassandra-dtest you will find that the string
> > > OverloadedException doesn't appear anywhere."
> > >
> > > Now let me flip this situation around:
> > >
> > > "I'm sure the users running Cassandra in production would prefer proper
> > > coding practice like writing unit and integration test to rubber stamp
> > > merges"
> > >
> > > When the shoe is on the other foot it does not feel so nice.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Fri, Nov 4, 2016 at 7:08 PM, Aleksey Yeschenko 
> > > wrote:
> > >
> > > > Dunno. A sneaky correctness or data corruption bug. A performance
> > > > regression. Or something that can take a node/cluster down.
> > > >
> > > > Of course no process is bullet-proof. The purpose of review is to
> > > minimise
> > > > the odds of such a thing happening.
> > > >
> > > > I’m sure users running Cassandra in production would prefer actual
> > proper
> > > > reviews to non-review +1s.
> > > >
> > > > --
> > > > AY
> > > >
> > > > On 4 November 2016 at 23:03:23, Edward Capriolo (
> edlinuxg...@gmail.com
> > )
> > > > wrote:
> > > >
> > > > I feel that is really standing up on a soap box. What 

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Tyler Tolley]

Just want to weigh in my 2 cents. I've been following the dev list for
quite a while and wanted to contribute. As I approached trying to handle
some lhf, I couldn't find any instructions on how to check out, build, test
or any guidance on coding standards and best practices. Maybe these existed
and were hard to find, maybe I was too inexperienced to understand them.
Either way, given my experience at the time, I wasn't able to contribute
and never came back.

If that hasn't changed, that's where I would start to get more people
contributing. I realize the project is pretty complex, but the more we can
lower the bar of entry, the more people will contribute. This doesn't help
solve the problem of more people to review big changes right away, but
perhaps it will free experienced contributors up to help with those. Again,
just my 2 cents.

On Sat, Nov 5, 2016, 7:19 AM Benedict Elliott Smith 
wrote:

> Hi Ed,
>
> I would like to try and clear up what I perceive to be some
> misunderstandings.
>
> Aleksey is relating that for *complex* tickets there are desperately few
> people with the expertise necessary to review them.  In some cases it can
> amount to several weeks' work, possibly requiring multiple people, which is
> a huge investment.  EPaxos is an example where its complexity likely needs
> multiple highly qualified reviewers.
>
> Simpler tickets on the other hand languish due to poor incentives - they
> aren't sexy for volunteers, and aren't important for the corporately
> sponsored contributors, who also have finite resources.  Nobody *wants* to
> do them.
>
> This does contribute to an emergent lack of diversity in the pool of
> contributors, but it doesn't discount Aleksey's point.  We need to find a
> way forward that handles both of these concerns.
>
> Sponsored contributors have invested time into efforts to expand the
> committer pool before, though they have universally failed.  Efforts like
> the "low hanging fruit squad" seem like a good idea that might payoff, with
> the only risk being the cloud hanging over the project right now.  I think
> constructive engagement with potential sponsors is probably the way
> forward.
>
> (As an aside, the policy on test coverage was historically very poor
> indeed, but is I believe much stronger today - try not to judge current
> behaviours on those of the past)
>
>
> On 5 November 2016 at 00:05, Edward Capriolo 
> wrote:
>
> > "I’m sure users running Cassandra in production would prefer actual
> proper
> > reviews to non-review +1s."
> >
> > Again, you are implying that only you can do a proper job.
> >
> > Lets be specific here: You and I are working on this one:
> >
> > https://issues.apache.org/jira/browse/CASSANDRA-10825
> >
> > Now, Ariel reported there was no/low code coverage. I went looking a the
> > code and found a problem.
> >
> > If someone were to merge this: I would have more incentive to look for
> > other things, then I might find more bugs and improvements. If this
> process
> > keeps going, I would naturally get exposed to more of the code. Finally
> in
> > maybe (I don't know in 10 or 20 years) I could become one of these
> > specialists.
> >
> > Lets peal this situation apart:
> >
> > https://issues.apache.org/jira/browse/CASSANDRA-10825
> >
> > "If you grep test/src and cassandra-dtest you will find that the string
> > OverloadedException doesn't appear anywhere."
> >
> > Now let me flip this situation around:
> >
> > "I'm sure the users running Cassandra in production would prefer proper
> > coding practice like writing unit and integration test to rubber stamp
> > merges"
> >
> > When the shoe is on the other foot it does not feel so nice.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Fri, Nov 4, 2016 at 7:08 PM, Aleksey Yeschenko 
> > wrote:
> >
> > > Dunno. A sneaky correctness or data corruption bug. A performance
> > > regression. Or something that can take a node/cluster down.
> > >
> > > Of course no process is bullet-proof. The purpose of review is to
> > minimise
> > > the odds of such a thing happening.
> > >
> > > I’m sure users running Cassandra in production would prefer actual
> proper
> > > reviews to non-review +1s.
> > >
> > > --
> > > AY
> > >
> > > On 4 November 2016 at 23:03:23, Edward Capriolo (edlinuxg...@gmail.com
> )
> > > wrote:
> > >
> > > I feel that is really standing up on a soap box. What would be the
> worst
> > > thing that happens here
> >
>

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Benedict Elliott Smith]

Hi Ed,

I would like to try and clear up what I perceive to be some
misunderstandings.

Aleksey is relating that for *complex* tickets there are desperately few
people with the expertise necessary to review them.  In some cases it can
amount to several weeks' work, possibly requiring multiple people, which is
a huge investment.  EPaxos is an example where its complexity likely needs
multiple highly qualified reviewers.

Simpler tickets on the other hand languish due to poor incentives - they
aren't sexy for volunteers, and aren't important for the corporately
sponsored contributors, who also have finite resources.  Nobody *wants* to
do them.

This does contribute to an emergent lack of diversity in the pool of
contributors, but it doesn't discount Aleksey's point.  We need to find a
way forward that handles both of these concerns.

Sponsored contributors have invested time into efforts to expand the
committer pool before, though they have universally failed.  Efforts like
the "low hanging fruit squad" seem like a good idea that might payoff, with
the only risk being the cloud hanging over the project right now.  I think
constructive engagement with potential sponsors is probably the way forward.

(As an aside, the policy on test coverage was historically very poor
indeed, but is I believe much stronger today - try not to judge current
behaviours on those of the past)


On 5 November 2016 at 00:05, Edward Capriolo  wrote:

> "I’m sure users running Cassandra in production would prefer actual proper
> reviews to non-review +1s."
>
> Again, you are implying that only you can do a proper job.
>
> Lets be specific here: You and I are working on this one:
>
> https://issues.apache.org/jira/browse/CASSANDRA-10825
>
> Now, Ariel reported there was no/low code coverage. I went looking a the
> code and found a problem.
>
> If someone were to merge this: I would have more incentive to look for
> other things, then I might find more bugs and improvements. If this process
> keeps going, I would naturally get exposed to more of the code. Finally in
> maybe (I don't know in 10 or 20 years) I could become one of these
> specialists.
>
> Lets peal this situation apart:
>
> https://issues.apache.org/jira/browse/CASSANDRA-10825
>
> "If you grep test/src and cassandra-dtest you will find that the string
> OverloadedException doesn't appear anywhere."
>
> Now let me flip this situation around:
>
> "I'm sure the users running Cassandra in production would prefer proper
> coding practice like writing unit and integration test to rubber stamp
> merges"
>
> When the shoe is on the other foot it does not feel so nice.
>
>
>
>
>
>
>
>
>
>
> On Fri, Nov 4, 2016 at 7:08 PM, Aleksey Yeschenko 
> wrote:
>
> > Dunno. A sneaky correctness or data corruption bug. A performance
> > regression. Or something that can take a node/cluster down.
> >
> > Of course no process is bullet-proof. The purpose of review is to
> minimise
> > the odds of such a thing happening.
> >
> > I’m sure users running Cassandra in production would prefer actual proper
> > reviews to non-review +1s.
> >
> > --
> > AY
> >
> > On 4 November 2016 at 23:03:23, Edward Capriolo (edlinuxg...@gmail.com)
> > wrote:
> >
> > I feel that is really standing up on a soap box. What would be the worst
> > thing that happens here
>

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Edward Capriolo]

"I’m sure users running Cassandra in production would prefer actual proper
reviews to non-review +1s."

Again, you are implying that only you can do a proper job.

Lets be specific here: You and I are working on this one:

https://issues.apache.org/jira/browse/CASSANDRA-10825

Now, Ariel reported there was no/low code coverage. I went looking a the
code and found a problem.

If someone were to merge this: I would have more incentive to look for
other things, then I might find more bugs and improvements. If this process
keeps going, I would naturally get exposed to more of the code. Finally in
maybe (I don't know in 10 or 20 years) I could become one of these
specialists.

Lets peal this situation apart:

https://issues.apache.org/jira/browse/CASSANDRA-10825

"If you grep test/src and cassandra-dtest you will find that the string
OverloadedException doesn't appear anywhere."

Now let me flip this situation around:

"I'm sure the users running Cassandra in production would prefer proper
coding practice like writing unit and integration test to rubber stamp
merges"

When the shoe is on the other foot it does not feel so nice.










On Fri, Nov 4, 2016 at 7:08 PM, Aleksey Yeschenko 
wrote:

> Dunno. A sneaky correctness or data corruption bug. A performance
> regression. Or something that can take a node/cluster down.
>
> Of course no process is bullet-proof. The purpose of review is to minimise
> the odds of such a thing happening.
>
> I’m sure users running Cassandra in production would prefer actual proper
> reviews to non-review +1s.
>
> --
> AY
>
> On 4 November 2016 at 23:03:23, Edward Capriolo (edlinuxg...@gmail.com)
> wrote:
>
> I feel that is really standing up on a soap box. What would be the worst
> thing that happens here

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Jeff Beck]

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 some asserts have
proper messages with them etc, but some may be slightly larger. 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 the 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.

Before we did this night I would probably dig through some tickets and get
an example list going and any feedback notes on making the process easier
would be great.

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.

Jeff

On Fri, Nov 4, 2016 at 6:08 PM Aleksey Yeschenko  wrote:

Dunno. A sneaky correctness or data corruption bug. A performance
regression. Or something that can take a node/cluster down.

Of course no process is bullet-proof. The purpose of review is to minimise
the odds of such a thing happening.

I’m sure users running Cassandra in production would prefer actual proper
reviews to non-review +1s.

-- 
AY

On 4 November 2016 at 23:03:23, Edward Capriolo (edlinuxg...@gmail.com)
wrote:

I feel that is really standing up on a soap box. What would be the worst
thing that happens here

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Aleksey Yeschenko]

Dunno. A sneaky correctness or data corruption bug. A performance regression. 
Or something that can take a node/cluster down.

Of course no process is bullet-proof. The purpose of review is to minimise the 
odds of such a thing happening.

I’m sure users running Cassandra in production would prefer actual proper 
reviews to non-review +1s.

-- 
AY

On 4 November 2016 at 23:03:23, Edward Capriolo (edlinuxg...@gmail.com) wrote:

I feel that is really standing up on a soap box. What would be the worst 
thing that happens here

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Edward Capriolo]

"There is also the issue of specialisation. Very few people can be trusted
with review of arbitrary
Cassandra patches. I can count them all on fingers of one hand."

I have to strongly disagree  here. The Cassandra issue tracker is over
12000 tickets. I do not think that cassandra has added 12000 "features"
since it's inception.  I reject this concept that only a hand full of
people are capable of reviewing and merging things. Firstly, if this
process was so insanely bullet proof we never had alternating tick-tock fix
releases. (Unless someone is going to argue we are still fixing zero day
bugs from the facebook code drop :). I in my spare time have passed over
code and found things.

I do not mean this to come off as offensive. There clearly are specialists
and they are well respected. When someone say things like:

"real reviews, not rubber-stamping a +1 formally"

I feel that is really standing up on a soap box. What would be the worst
thing that happens here? A "rubber stamp" review sneaks in and causes bug
12001. OMG! NO SOMEONE RUBBER STAMPED SOMETHING AND CREATED A BUG. THAT
NEVER HAPPENED BEFORE IN THE HISTORY OF THE PROJECT. THERE HAS NEVER BEEN A
UNTESTED FEATURE ADDED WHICH BROKE SOMETHING ELSE. ETC ETC.

Be real about this situation it. Just added sasi stuff has bugs.





On Fri, Nov 4, 2016 at 6:27 PM, Aleksey Yeschenko 
wrote:

> I’m sure that impactful, important, and/or potentially destabilising
> patches will continue getting reviewed
> by those engineers.
>
> As for patches that no organisation with a strong enough commercial
> interest cares about, they probably won’t.
> Engineering time is quite expensive, most employers are understaffed as it
> is, overloaded with deadlines and
> fires, so it’s hard to justify donating man hours to work that brings no
> value to your employer - be it Instagram,
> Apple, or DataStax.
>
> I don’t want to sound negative here, but I’d rather not fake optimism
> here, either. Expect that kind of patches
> to stay in unreviewed limbo for the most part.
>
> But significant work will still get reviewed and committed, keeping the
> project overall healthy. I wouldn’t worry much.
>
> --
> AY
>
> On 4 November 2016 at 22:13:42, Aleksey Yeschenko (alek...@apache.org)
> wrote:
>
> This has always been a concern. We’ve always had a backlog on unreviewed
> patches.
>
> Reviews (real reviews, not rubber-stamping a +1 formally) are real work,
> often taking as much work
> as creating the patch in question. And taking as much expertise (or more).
>
> It’s also not ‘fun’ and doesn’t lend itself to scratch-your-own-itch
> drive-by style contributions.
>
> In other words, not something people tend to volunteer for. Something done
> mostly by people
> paid to do the work, reviews assigned to them by their managers.
>
> There is also the issue of specialisation. Very few people can be trusted
> with review of arbitrary
> Cassandra patches. I can count them all on fingers of one hand. There are
> islands of expertise
> and people who can review certain subsystems, and most of them are
> employed by a certain one
> company. A few people at Apple, but with no real post-8099, 3.0 code
> experience at the moment.
>
> What I’m saying is that it’s insufficient to just have desire to volunteer
> - you also need the actual
> knowledge and skill to properly review non-trivial work, and for that we
> largely only have DataStax
> employed contributors, with a sprinkle of people at Apple, and that’s
> sadly about it.
>
> We tried to improve it by holding multiple bootcamps, at Summits, and
> privately within major companies,
> at non-trivial expense to the company, but those initiatives mostly failed
> so far :(
>
> This has always been a problem (lack of review bandwidth), and always will
> be. That said, I don’t expect it to get
> much worse than it is now.
>
> --
> AY
>
> On 4 November 2016 at 21:50:20, Nate McCall (zznat...@gmail.com) wrote:
>
> To be clear, getting the community more involved is a super hard,
> critically important problem to which I don't have a concrete answer
> other than I'm going to keep reaching out for opinions, ideas and
> involvement.
>
> Just like this.
>
> Please speak up here if you have ideas on how this could work.
>
> On Sat, Nov 5, 2016 at 10:38 AM, Nate McCall  wrote:
> > [Moved to a new thread because this topic is important by itself]
> >
> > There are some excellent points here - thanks for bringing this up.
> >
> >> What can inspiring developers contribute to 4.0
> >> that would move the project forward to it’s goals and would be very
> likely
> >> included in the final release?
> >
> > That is a hard question with regards to the tickets I listed. My goal
> > was to list the large, potentially breaking changes which would
> > necessitate a move from '3' to '4' major release. Unfortunately in
> > this context, those types of issues have a huge surface area that
> > requires experience with the code to 

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Aleksey Yeschenko]

I’m sure that impactful, important, and/or potentially destabilising patches 
will continue getting reviewed
by those engineers.

As for patches that no organisation with a strong enough commercial interest 
cares about, they probably won’t.
Engineering time is quite expensive, most employers are understaffed as it is, 
overloaded with deadlines and
fires, so it’s hard to justify donating man hours to work that brings no value 
to your employer - be it Instagram,
Apple, or DataStax.

I don’t want to sound negative here, but I’d rather not fake optimism here, 
either. Expect that kind of patches
to stay in unreviewed limbo for the most part.

But significant work will still get reviewed and committed, keeping the project 
overall healthy. I wouldn’t worry much.

-- 
AY

On 4 November 2016 at 22:13:42, Aleksey Yeschenko (alek...@apache.org) wrote:

This has always been a concern. We’ve always had a backlog on unreviewed 
patches.

Reviews (real reviews, not rubber-stamping a +1 formally) are real work, often 
taking as much work
as creating the patch in question. And taking as much expertise (or more).

It’s also not ‘fun’ and doesn’t lend itself to scratch-your-own-itch drive-by 
style contributions.

In other words, not something people tend to volunteer for. Something done 
mostly by people
paid to do the work, reviews assigned to them by their managers.

There is also the issue of specialisation. Very few people can be trusted with 
review of arbitrary
Cassandra patches. I can count them all on fingers of one hand. There are 
islands of expertise
and people who can review certain subsystems, and most of them are employed by 
a certain one
company. A few people at Apple, but with no real post-8099, 3.0 code experience 
at the moment.

What I’m saying is that it’s insufficient to just have desire to volunteer - 
you also need the actual
knowledge and skill to properly review non-trivial work, and for that we 
largely only have DataStax
employed contributors, with a sprinkle of people at Apple, and that’s sadly 
about it.

We tried to improve it by holding multiple bootcamps, at Summits, and privately 
within major companies,
at non-trivial expense to the company, but those initiatives mostly failed so 
far :(

This has always been a problem (lack of review bandwidth), and always will be. 
That said, I don’t expect it to get
much worse than it is now.

-- 
AY

On 4 November 2016 at 21:50:20, Nate McCall (zznat...@gmail.com) wrote:

To be clear, getting the community more involved is a super hard,
critically important problem to which I don't have a concrete answer
other than I'm going to keep reaching out for opinions, ideas and
involvement.

Just like this.

Please speak up here if you have ideas on how this could work.

On Sat, Nov 5, 2016 at 10:38 AM, Nate McCall  wrote:
> [Moved to a new thread because this topic is important by itself]
>
> There are some excellent points here - thanks for bringing this up.
>
>> What can inspiring developers contribute to 4.0
>> that would move the project forward to it’s goals and would be very likely
>> included in the final release?
>
> That is a hard question with regards to the tickets I listed. My goal
> was to list the large, potentially breaking changes which would
> necessitate a move from '3' to '4' major release. Unfortunately in
> this context, those types of issues have a huge surface area that
> requires experience with the code to review in a meaningful way.
>
> We are kind of in this trap now with the Gossip 2.0 tickets. There are
> very few people who feel comfortable enough to give Jason feedback on
> the patches because he has effectively replaced (necessarily, IMO)
> seven years of edge case fixes baked into the current implementation.
> And that stuff is just hard in the first place.
>
> I'm not completely sure what the answer is here. I will tell you that
> from my own experience, an excellent way to get familiar with the code
> and concepts would be to look at some of these large tickets in
> detail, go through what changed and ask some questions about the
> choices made.
>
> Community is based on participation, conversation and exchange of
> knowledge. The more involvement we have in day to day exchanges, the
> more we all learn and the healthier things will become.
>
>> What should people work on that would not be
>> left ignored, because there’s no need for it or no time to really take care
>> of it?
>
> We have a huge pile of backlogged tickets in "unresolved" and "patch
> available." Going through these and testing, reviewing, submitting
> patches, even pinging on status, rebasing if needed would be awesome.
> Frankly, we need the help.
>
> Another thought - "I would like to add X, how should I go about doing
> this?" is an excellent conversation to start on the mail list:
> https://lists.apache.org/thread.html/0ecddfb2ecc72e8c5f4027d96b72345d3476edfe0094f89b42a93539@%3Cdev.cassandra.apache.org%3E
>
>>
>> Each 

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Aleksey Yeschenko]

This has always been a concern. We’ve always had a backlog on unreviewed 
patches.

Reviews (real reviews, not rubber-stamping a +1 formally) are real work, often 
taking as much work
as creating the patch in question. And taking as much expertise (or more).

It’s also not ‘fun’ and doesn’t lend itself to scratch-your-own-itch drive-by 
style contributions.

In other words, not something people tend to volunteer for. Something done 
mostly by people
paid to do the work, reviews assigned to them by their managers.

There is also the issue of specialisation. Very few people can be trusted with 
review of arbitrary
Cassandra patches. I can count them all on fingers of one hand. There are 
islands of expertise
and people who can review certain subsystems, and most of them are employed by 
a certain one
company. A few people at Apple, but with no real post-8099, 3.0 code experience 
at the moment.

What I’m saying is that it’s insufficient to just have desire to volunteer - 
you also need the actual
knowledge and skill to properly review non-trivial work, and for that we 
largely only have DataStax
employed contributors, with a sprinkle of people at Apple, and that’s sadly 
about it.

We tried to improve it by holding multiple bootcamps, at Summits, and privately 
within major companies,
at non-trivial expense to the company, but those initiatives mostly failed so 
far :(

This has always been a problem (lack of review bandwidth), and always will be. 
That said, I don’t expect it to get
much worse than it is now.

-- 
AY

On 4 November 2016 at 21:50:20, Nate McCall (zznat...@gmail.com) wrote:

To be clear, getting the community more involved is a super hard,  
critically important problem to which I don't have a concrete answer  
other than I'm going to keep reaching out for opinions, ideas and  
involvement.  

Just like this.  

Please speak up here if you have ideas on how this could work.  

On Sat, Nov 5, 2016 at 10:38 AM, Nate McCall  wrote:  
> [Moved to a new thread because this topic is important by itself]  
>  
> There are some excellent points here - thanks for bringing this up.  
>  
>> What can inspiring developers contribute to 4.0  
>> that would move the project forward to it’s goals and would be very likely  
>> included in the final release?  
>  
> That is a hard question with regards to the tickets I listed. My goal  
> was to list the large, potentially breaking changes which would  
> necessitate a move from '3' to '4' major release. Unfortunately in  
> this context, those types of issues have a huge surface area that  
> requires experience with the code to review in a meaningful way.  
>  
> We are kind of in this trap now with the Gossip 2.0 tickets. There are  
> very few people who feel comfortable enough to give Jason feedback on  
> the patches because he has effectively replaced (necessarily, IMO)  
> seven years of edge case fixes baked into the current implementation.  
> And that stuff is just hard in the first place.  
>  
> I'm not completely sure what the answer is here. I will tell you that  
> from my own experience, an excellent way to get familiar with the code  
> and concepts would be to look at some of these large tickets in  
> detail, go through what changed and ask some questions about the  
> choices made.  
>  
> Community is based on participation, conversation and exchange of  
> knowledge. The more involvement we have in day to day exchanges, the  
> more we all learn and the healthier things will become.  
>  
>> What should people work on that would not be  
>> left ignored, because there’s no need for it or no time to really take care  
>> of it?  
>  
> We have a huge pile of backlogged tickets in "unresolved" and "patch  
> available." Going through these and testing, reviewing, submitting  
> patches, even pinging on status, rebasing if needed would be awesome.  
> Frankly, we need the help.  
>  
> Another thought - "I would like to add X, how should I go about doing  
> this?" is an excellent conversation to start on the mail list:  
> https://lists.apache.org/thread.html/0ecddfb2ecc72e8c5f4027d96b72345d3476edfe0094f89b42a93539@%3Cdev.cassandra.apache.org%3E
>   
>  
>>  
>> Each contribution  
>> deserves some kind of response and even if it’s just a “not relevant for  
>> next release, will look into it another time” type of reply.  
>  
> I completely agree. Per the above, anyone should feel like they can  
> chime in on tickets. It's a community effort.  
>  
> Particularly if you are an operator - your thoughts, experiences and  
> opinions matter (to me at least) like 10x what a developer thinks for  
> anything with operational or end user impact.  
>  
>> Having clear  
>> goals or a certain theme for the release should make it easier to decide  
>> what to review and where to decline. Does that make sense?  
>  
> I think anything *new* with a large surface area not already well  
> underway (and maybe some things that 

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Nate McCall]

To be clear, getting the community more involved is a super hard,
critically important problem to which I don't have a concrete answer
other than I'm going to keep reaching out for opinions, ideas and
involvement.

Just like this.

Please speak up here if you have ideas on how this could work.

On Sat, Nov 5, 2016 at 10:38 AM, Nate McCall  wrote:
> [Moved to a new thread because this topic is important by itself]
>
> There are some excellent points here - thanks for bringing this up.
>
>> What can inspiring developers contribute to 4.0
>> that would move the project forward to it’s goals and would be very likely
>> included in the final release?
>
> That is a hard question with regards to the tickets I listed. My goal
> was to list the large, potentially breaking changes which would
> necessitate a move from '3' to '4' major release. Unfortunately in
> this context, those types of issues have a huge surface area that
> requires experience with the code to review in a meaningful way.
>
> We are kind of in this trap now with the Gossip 2.0 tickets. There are
> very few people who feel comfortable enough to give Jason feedback on
> the patches because he has effectively replaced (necessarily, IMO)
> seven years of edge case fixes baked into the current implementation.
> And that stuff is just hard in the first place.
>
> I'm not completely sure what the answer is here. I will tell you that
> from my own experience, an excellent way to get familiar with the code
> and concepts would be to look at some of these large tickets in
> detail, go through what changed and ask some questions about the
> choices made.
>
> Community is based on participation, conversation and exchange of
> knowledge. The more involvement we have in day to day exchanges, the
> more we all learn and the healthier things will become.
>
>> What should people work on that would not be
>> left ignored, because there’s no need for it or no time to really take care
>> of it?
>
> We have a huge pile of backlogged tickets in "unresolved" and "patch
> available." Going through these and testing, reviewing, submitting
> patches, even pinging on status, rebasing if needed would be awesome.
> Frankly, we need the help.
>
> Another thought - "I would like to add X, how should I go about doing
> this?" is an excellent conversation to start on the mail list:
> https://lists.apache.org/thread.html/0ecddfb2ecc72e8c5f4027d96b72345d3476edfe0094f89b42a93539@%3Cdev.cassandra.apache.org%3E
>
>>
>> Each contribution
>> deserves some kind of response and even if it’s just a “not relevant for
>> next release, will look into it another time” type of reply.
>
> I completely agree. Per the above, anyone should feel like they can
> chime in on tickets. It's a community effort.
>
> Particularly if you are an operator - your thoughts, experiences and
> opinions matter (to me at least) like 10x what a developer thinks for
> anything with operational or end user impact.
>
>> Having clear
>> goals or a certain theme for the release should make it easier to decide
>> what to review and where to decline. Does that make sense?
>
> I think anything *new* with a large surface area not already well
> underway (and maybe some things that are?) should be tabled for 5 at
> this point. We really need to focus on stability via community
> involvement.

Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Nate McCall]

[Moved to a new thread because this topic is important by itself]

There are some excellent points here - thanks for bringing this up.

> What can inspiring developers contribute to 4.0
> that would move the project forward to it’s goals and would be very likely
> included in the final release?

That is a hard question with regards to the tickets I listed. My goal
was to list the large, potentially breaking changes which would
necessitate a move from '3' to '4' major release. Unfortunately in
this context, those types of issues have a huge surface area that
requires experience with the code to review in a meaningful way.

We are kind of in this trap now with the Gossip 2.0 tickets. There are
very few people who feel comfortable enough to give Jason feedback on
the patches because he has effectively replaced (necessarily, IMO)
seven years of edge case fixes baked into the current implementation.
And that stuff is just hard in the first place.

I'm not completely sure what the answer is here. I will tell you that
from my own experience, an excellent way to get familiar with the code
and concepts would be to look at some of these large tickets in
detail, go through what changed and ask some questions about the
choices made.

Community is based on participation, conversation and exchange of
knowledge. The more involvement we have in day to day exchanges, the
more we all learn and the healthier things will become.

> What should people work on that would not be
> left ignored, because there’s no need for it or no time to really take care
> of it?

We have a huge pile of backlogged tickets in "unresolved" and "patch
available." Going through these and testing, reviewing, submitting
patches, even pinging on status, rebasing if needed would be awesome.
Frankly, we need the help.

Another thought - "I would like to add X, how should I go about doing
this?" is an excellent conversation to start on the mail list:
https://lists.apache.org/thread.html/0ecddfb2ecc72e8c5f4027d96b72345d3476edfe0094f89b42a93539@%3Cdev.cassandra.apache.org%3E

>
> Each contribution
> deserves some kind of response and even if it’s just a “not relevant for
> next release, will look into it another time” type of reply.

I completely agree. Per the above, anyone should feel like they can
chime in on tickets. It's a community effort.

Particularly if you are an operator - your thoughts, experiences and
opinions matter (to me at least) like 10x what a developer thinks for
anything with operational or end user impact.

> Having clear
> goals or a certain theme for the release should make it easier to decide
> what to review and where to decline. Does that make sense?

I think anything *new* with a large surface area not already well
underway (and maybe some things that are?) should be tabled for 5 at
this point. We really need to focus on stability via community
involvement.