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=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-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=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-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 >> > > >> > >>
