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
