I think you misread the thread, since that's the opposite of what Patrick suggested. He's suggesting that *nobody ever waits* to be assigned a JIRA to work on it; that anyone may work on a JIRA without waiting for it to be assigned.
The point is: assigning JIRAs discourages others from doing work and we don't want to do that. So the pattern so far has been to not use it (except retroactively to credit the major contributor to the resolution.) The cost of this policy is -- oops, maybe you work on something that's already being worked on. That isn't a problem in practice. We already have a way to signal that you're working on a patch: you open a PR. It automatically links to JIRA. Or you can just comment. I suppose you could also use Assignee as a strong signal that your'e working on it, and some people want to do that, and so I was floating the idea of just letting people use it as they like. But I also back the idea of not having a notion of "owner" of working on a JIRA. On Wed, Apr 22, 2015 at 9: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
