cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh McKenzie <jmcken...@apache.org>
Subject Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)
Date Sat, 12 Nov 2016 13:15:04 GMT
>
> 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_2003@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.hanna1234@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_2003@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<zznate.m@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 <dikang85@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.petrov@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-SVWiwkSinPT6Rr9PoPKtQ@mail.gmail.com
> %3E
> >>>
> >>> On Mon, Nov 7, 2016 at 5:38 PM Aleksey Yeschenko <aleksey@apache.org>
> >>> wrote:
> >>>
> >>>> Agreed.
> >>>>
> >>>> --
> >>>> AY
> >>>>
> >>>> On 7 November 2016 at 16:38:07, Jeff Jirsa (
> jeff.jirsa@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.slater@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 <dlester@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 <michael@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
>
>
>
>

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