spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Wendell <pwend...@gmail.com>
Subject Re: Should we let everyone set Assignee?
Date Wed, 22 Apr 2015 20:20:15 GMT
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
<vinodkv@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 <pwendell@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 <sowen@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-unsubscribe@spark.apache.org
>>> For additional commands, e-mail: dev-help@spark.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@spark.apache.org
>> For additional commands, e-mail: dev-help@spark.apache.org
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@spark.apache.org
For additional commands, e-mail: dev-help@spark.apache.org


Mime
View raw message