agreed, what Patrick suggests seems very reasonable.
On Wednesday, April 22, 2015 1:26 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
>
>
