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
