My thinking is that current way of assigning a contributor after the patch is done (or almost done) is OK. Parallel efforts are also OK until they are discussed in the issue's thread. Ilya Ganelin made a good point that it is about moving the project forward. It also adds means of competition "who make it faster/better" which is also good for the project and community. My only concern is about the throughput of Databricks folks who monitor issues, check patches and assign a contributor. Monitoring should be done on a constant basis (weekly?).
Best regards, Alexander -----Original Message----- From: Vinod Kumar Vavilapalli [mailto:vino...@hortonworks.com] Sent: Wednesday, April 22, 2015 2:59 PM To: Patrick Wendell Cc: Nicholas Chammas; Ganelin, Ilya; Mark Hamstra; Sean Owen; dev Subject: Re: Should we let everyone set Assignee? Last one for the day. Everyone, as I said clearly, I was "not alluding to anything fishy in practice", I was describing how things go wrong in such an environment. Sandy's email lays down some of these problems. Assigning a JIRA in other projects is not a reservation. It is a clear intention of working on design or code. You don't need a new convention of signaling. In almost all other projects, it is assigning tickets - that's how it is used. +Vinod On Apr 22, 2015, at 2:37 PM, Patrick Wendell <pwend...@gmail.com> wrote: > Sandy - I definitely agree with that. We should have a convention of > signaling someone intends to work - for instance by commenting on the > JIRA and we should document this on the contribution guide. The nice > thing about having that convention is that multiple people can say > they are going to work on something, whereas only one person can be > given the assignee slot on a JIRA. > > > On Wed, Apr 22, 2015 at 2:33 PM, Nicholas Chammas > <nicholas.cham...@gmail.com> wrote: >> To repeat what Patrick said (literally): >> >> If an issue is "assigned" to person X, but some other person Y >> submits a great patch for it, I think we have some obligation to >> Spark users and to the community to merge the better patch. So the >> idea of reserving the right to add a feature, it just seems overall off to >> me. >> >> No-one in the Spark community dictates who gets to do work. When an >> issue is assigned to someone in JIRA, it's either because a) they did >> the work and the issue is now resolved, or b) they are signaling to >> others that they are working on it. >> >> In the case of b), nothing stops other people from working on the >> issue and it's quite normal for other people to complete issues that >> were technically assigned to someone else. There is no land grabbing >> or stalling. Anyone who has contributed to Spark for any amount of time >> knows this. >> >> Vinod, >> >> I want to take this opportunity to call out the approach to >> communication you took here. >> >> As a random contributor to Spark and active participant on this list, >> my reaction when I read your email was this: >> >> You do not know how the Spark community actually works. >> You read a thread that contains some trigger phrases. >> You wrote a lengthy response as a knee-jerk reaction. >> >> I'm not trying to mock, but I want to be direct and honest about how >> you came off in this thread to me and probably many others. >> >> Why not ask questions first--many questions? Why not make doubly sure >> that you understand the situation correctly before responding? >> >> In many ways this is much like filing a bug report. "I'm seeing this. >> It seems wrong to me. Is this expected?" I think we all know from >> experience that this kind of bug report is polite and will likely >> lead to a productive discussion. On the other hand: "You're returning >> a -1 here? This is obviously wrong! And, boy, lemme tell you how >> wrong you are!!!" No-one likes to deal with bug reports like this. >> More importantly, they get in the way of fixing the actual problem, if there >> is one. >> >> This is not about the Apache Way or not. It's about basic etiquette >> and effective communication. >> >> I understand that there are legitimate potential concerns here, and >> it's important that, as an Apache project, Spark work according to >> Apache principles. But when some person who has never participated on >> this list pops up out of nowhere with a lengthy lecture on the Apache >> Way and whatnot, I have to say that that is not an effective way to >> communicate. Pretty much the same thing happened with Greg Stein on >> an earlier thread some months ago about designating maintainers for >> components. >> >> The concerns are legitimate, I'm sure, and we want to keep Spark in >> line with the Apache Way. And certainly, there have been many times >> when a project veered off course and needed to corrected. >> >> But when we want to make things right, I hope we can do it in a way >> that respectfully and tactfully engages the community. These >> "lectures delivered from above" -- which is how they come off -- are not >> helpful. >> >> Nick >> >> >> On Wed, Apr 22, 2015 at 4:31 PM Ganelin, Ilya >> <ilya.gane...@capitalone.com> >> wrote: >>> >>> As a contributor, I¹ve never felt shut out from the Spark community, >>> nor have I seen any examples of territorial behavior. A few times >>> I¹ve expressed interest in more challenging work and the response I >>> received was generally ³go ahead and give it a shot, just understand >>> that this is sensitive code so we may end up modifying the PR >>> substantially.² Honestly, that seems fine, and in general, I think >>> it¹s completely fair to go with the PR model - e.g. If a JIRA has an >>> open PR then it¹s an active effort, otherwise it¹s fair game unless >>> otherwise stated. At the end of the day, it¹s about moving the >>> project forward and the only way to do that is to have actual code >>> in the pipes -speculation and intent don¹t really help, and there¹s >>> nothing preventing an interested party from submitting a PR against an >>> issue. >>> >>> Thank you, >>> Ilya Ganelin >>> >>> >>> >>> >>> >>> >>> On 4/22/15, 1:25 PM, "Mark Hamstra" <m...@clearstorydata.com> wrote: >>> >>>> Agreed. The Spark project and community that Vinod describes do >>>> not resemble the ones with which I am familiar. >>>> >>>> On Wed, Apr 22, 2015 at 1:20 PM, Patrick Wendell >>>> <pwend...@gmail.com> >>>> wrote: >>>> >>>>> Hi Vinod, >>>>> >>>>> Thanks for you thoughts - However, I do not agree with your >>>>> sentiment and implications. Spark is broadly quite an inclusive >>>>> project and we spend a lot of effort culturally to help make newcomers >>>>> feel welcome. >>>>> >>>>> - Patrick >>>>> >>>>> On Wed, Apr 22, 2015 at 1:11 PM, Vinod Kumar Vavilapalli >>>>> <vino...@hortonworks.com> wrote: >>>>>> Actually what this community got away with is pretty much an >>>>> anti-pattern compared to every other Apache project I have seen. >>>>> And may I say in a not so Apache way. >>>>>> >>>>>> Waiting for a committer to assign a patch to someone leaves it as >>>>>> a >>>>> privilege to a committer. Not alluding to anything fishy in >>>>> practice, but this also leaves a lot of open ground for >>>>> self-interest. Committers defining notions of good fit / level of >>>>> experience do not work, highly subjective and lead to group >>>>> control. >>>>>> >>>>>> In terms of semantics, here is what most other projects (dare I >>>>>> say >>>>> every Apache project?) that I have seen do >>>>>> - A new contributor comes in who is not yet added to the JIRA >>>>> project. >>>>> He/she requests one of the project's JIRA admins to add him/her. >>>>>> - After that, he or she is free to assign tickets to themselves. >>>>>> - What this means >>>>>> -- Assigning a ticket to oneself is a signal to the rest of >>>>>> the >>>>> community that he/she is actively working on the said patch. >>>>>> -- If multiple contributors want to work on the same patch, it >>>>> needs >>>>> to resolved amicably through open communication. On JIRA, or on >>>>> mailing lists. Not by the whim of a committer. >>>>>> - Common issues >>>>>> -- Land grabbing: Other contributors can nudge him/her in case >>>>>> of >>>>> inactivity and take them over. Again, amicably instead of a >>>>> committer making subjective decisions. >>>>>> -- Progress stalling: One contributor assigns the ticket to >>>>> himself/herself is actively debating but with no real code/docs >>>>> contribution or with any real intention of making progress. Here >>>>> workable, reviewable code for review usually wins. >>>>>> >>>>>> Assigning patches is not a privilege. Contributors at Apache are >>>>>> a >>>>> bunch >>>>> of volunteers, the PMC should let volunteers contribute as they >>>>> see fit. We do not assign work at Apache. >>>>>> >>>>>> +Vinod >>>>>> >>>>>> On Apr 22, 2015, at 12:32 PM, Patrick Wendell >>>>>> <pwend...@gmail.com> >>>>> wrote: >>>>>> >>>>>>> One over arching issue is that it's pretty unclear what >>>>>>> "Assigned to X" in JIAR means from a process perspective. >>>>>>> Personally I actually feel it's better for this to be more >>>>>>> historical - i.e. who ended up submitting a patch for this >>>>>>> feature that was merged - rather than creating an exclusive >>>>>>> reservation for a particular user to work on something. >>>>>>> >>>>>>> If an issue is "assigned" to person X, but some other person Y >>>>> submits >>>>>>> a great patch for it, I think we have some obligation to Spark >>>>>>> users and to the community to merge the better patch. So the >>>>>>> idea of reserving the right to add a feature, it just seems >>>>>>> overall off to >>>>> me. >>>>>>> IMO, its fine if multiple people want to submit competing >>>>>>> patches for something, provided everyone comments on JIRA saying >>>>>>> they are intending to submit a patch, and everyone understands >>>>>>> there is duplicate effort. So commenting with an intention to >>>>>>> submit a patch, IMO seems like the healthiest workflow since it >>>>>>> is non exclusive. >>>>>>> >>>>>>> To me the main benefit of "assigning" something ahead of time is >>>>>>> if you have a committer that really wants to see someone >>>>>>> specific work >>>>> on >>>>>>> a patch, it just acts as a strong signal that there is someone >>>>>>> endorsed to work on that patch. That doesn't mean no one else >>>>>>> can submit a patch, but it is IMO more of a warning that there >>>>>>> may be existing work which is likely to be high quality, to >>>>>>> avoid duplicated effort. >>>>>>> >>>>>>> When it was really easy to assign features to themselves, I saw >>>>>>> a lot of anti-patterns in the community that seemed unhealthy, >>>>> specifically: >>>>>>> >>>>>>> - It was really unclear what it means semantically if someone is >>>>>>> assigned to a JIRA. >>>>>>> - People assign JIRA's to themselves that aren't a good fit, >>>>>>> given >>>>> the >>>>>>> authors level of experience. >>>>>>> - People expect if they assign JIRA's to themselves that others >>>>>>> won't submit patches, and become upset if they do. >>>>>>> - People are discouraged from working on a patch because someone >>>>>>> else was officially assigned. >>>>>>> >>>>>>> - Patrick >>>>>>> >>>>>>> On Wed, Apr 22, 2015 at 11:13 AM, Sean Owen <so...@cloudera.com> >>>>> wrote: >>>>>>>> Anecdotally, there are a number of people asking to set the >>>>>>>> Assignee field. This is currently restricted to Committers in >>>>>>>> JIRA. I know >>>>> the >>>>>>>> logic was to prevent people from Assigning a JIRA and then >>>>>>>> leaving >>>>> it; >>>>>>>> it also matters a bit for questions of "credit". >>>>>>>> >>>>>>>> Still I wonder if it's best to just let people go ahead and set >>>>>>>> it, >>>>> as >>>>>>>> the lesser "evil". People can already do a lot like resolve >>>>>>>> JIRAs >>>>> and >>>>>>>> set shepherd and critical priority and all that. >>>>>>>> >>>>>>>> I think the intent was to let "Developers" set this, but maybe >>>>>>>> due >>>>> to >>>>>>>> an error, that's not how the current JIRA permission is >>>>>>>> implemented. >>>>>>>> >>>>>>>> I ask because I'm about to ping INFRA to update our scheme. >>>>>>>> >>>>>>>> >>>>> ------------------------------------------------------------------ >>>>> --- >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For >>>>>>>> additional commands, e-mail: dev-h...@spark.apache.org >>>>>>>> >>>>>>> >>>>>>> >>>>>>> ---------------------------------------------------------------- >>>>>>> ----- To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org >>>>>>> For additional commands, e-mail: dev-h...@spark.apache.org >>>>>>> >>>>>> >>>>> >>>>> ------------------------------------------------------------------ >>>>> --- To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For >>>>> additional commands, e-mail: dev-h...@spark.apache.org >>>>> >>>>> >>> >>> ________________________________________________________ >>> >>> The information contained in this e-mail is confidential and/or >>> proprietary to Capital One and/or its affiliates. The information >>> transmitted herewith is intended only for use by the individual or >>> entity to which it is addressed. If the reader of this message is >>> not the intended recipient, you are hereby notified that any review, >>> retransmission, dissemination, distribution, copying or other use >>> of, or taking of any action in reliance upon this information is >>> strictly prohibited. If you have received this communication in >>> error, please contact the sender and delete the material from your computer. >>> >>> >>> -------------------------------------------------------------------- >>> - To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For >>> additional commands, e-mail: dev-h...@spark.apache.org >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
