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
