I think one of the benefits of assignee fields that I've seen in other projects is their potential to coordinate and prevent duplicate work. It's really frustrating to put a lot of work into a patch and then find out that someone has been doing the same. It's helpful for the project etiquette to include a way to signal to others that you are working or intend to work on a patch. Obviously there are limits to how long someone should be able to hold on to a JIRA without making progress on it, but a signal is still useful. Historically, in other projects, the assignee field serves as this signal. If we don't want to use the assignee field for this, I think it's important to have some alternative, even if it's just encouraging contributors to comment "I'm planning to work on this" on JIRA.
-Sandy On Wed, Apr 22, 2015 at 1:30 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 > >
