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&jqlQuery=project+=+12310865+AND+labels+=+lhf+AND+status+!=+resolved
<https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+=+12310865+AND+labels+=+lhf+AND+status+!=+resolved>
> On Nov 10, 2016, at 12:06 PM, Anuj Wadehra <anujw_2...@yahoo.co.in.INVALID>
> 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<zznat...@gmail.com> 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 <dikan...@gmail.com> 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 <alek...@apache.org>
>>> 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" <ben.sla...@instaclustr.com> 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 <dles...@apache.org> 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&d=DgIFaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kq
>>> hAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=
>>> 0Ynrto5MaNdgc2fOUtxv50ouikBU_P7VEv6KNub9Bhk&s=
>>> MAZTdq4wfrTiqh7nImEMcFWtTrsixRFOX7Pi0SKqQv0&e=
>>>>>
>>>>>> wrote:
>>>>>>> Hi All,
>>>>>>>
>>>>>>> I thought I would add a couple of observations and suggestions 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_&d=DgIFaQ&c=
>>> 08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=
>>> yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=
>>> 0Ynrto5MaNdgc2fOUtxv50ouikBU_P7VEv6KNub9Bhk&s=
>>> MB2cGSGm5RHMnWWRGLZ4h8P7Mo0Rvm6k5mW2yhQVZ7U&e=
>>>> , and
>>>>>> submitting a patch guide:
>>>>>>
>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__mesos.
>>> apache.org_documentation_latest_submitting-2Da-2Dpatch_&d=DgIFaQ&c=
>>> 08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=
>>> yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=
>>> 0Ynrto5MaNdgc2fOUtxv50ouikBU_P7VEv6KNub9Bhk&s=PSj3seUwzL_USxWvdvqlMKrU_
>>> yfBXpOSQ4XfjdhnmO0&e=
>>>> .
>>>>>>
>>>>>> In practice, there are some limitations and risks to this model. 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
>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__start.It&d=DgIFaQ&c=
>>> 08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=
>>> yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=
>>> 0Ynrto5MaNdgc2fOUtxv50ouikBU_P7VEv6KNub9Bhk&s=
>>> gN1SaWPyD2s998oRRQXN0ayhhOmSWnIMFR8PLiyw7tc&e=
>>>> seems that
>>>>>> review,
>>>>>>> testing and doco could all do with more hands (as on just about 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 <mich...@pbandjelly.org>
>>>>>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__
>>> cassandra.apache.org_doc_latest_&d=DgIFaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kq
>>> hAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=
>>> 0Ynrto5MaNdgc2fOUtxv50ouikBU_P7VEv6KNub9Bhk&s=
>>> nobuS9ngFj52bmS0NaFnZKuZzWut6TPN0yohfHDioXs&e=
>>>>>>>>
>>>>>>>> The red bar at the top has a link to contributions, there are docs
>>>>>> about
>>>>>>>> getting started with development, reviewing patches, and 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
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>> --
>>> Alex Petrov
>>>
>>
>>
>>
>> --
>> Dikang
