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
