spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Owen <>
Subject Re: [DISCUSS] assignee practice on committers+ (possible issue on preemption)
Date Fri, 19 Feb 2021 04:59:31 GMT
I don't believe Assignee has ever been used for anything except to give a
bit of informal credit to the person who drove most of the work on the
issue, when it's resolved.
If that's the question - does Assignee mean only that person can work on
the issue? then no, it has never meant that.

You say you have an example, one that was resolved. Is this a single case
or systemic? I don't think I recall seeing problems of this form.

We _have_ had multiple incompatible PRs for a JIRA before, occasionally.
We have also definitely had people file huge umbrella JIRAs, parts of which
_nobody_ ever completes, but, for lack of any interest from the filer or
anyone else.

I think it's fair to give a person a reasonable shot at producing a
solution if they propose a problem or feature.
We have had instances where a new contributor files a relatively simple
issue, and finds another contributor opened the obvious PR before they had
a chance (maybe they needed a day to get the PR together). That seemed a
bit discourteous.

 If you need a solution as well, and one isn't forthcoming, just open a PR
and propose your own? I don't hear that anyone told you not to, but I also
don't know what this is about. You can always propose a PR as an
alternative to compare with, to facilitate collaboration. Nothing wrong
with that.

On Thu, Feb 18, 2021 at 10:45 PM Jungtaek Lim <>

> (Actually the real world case was fixed somehow and I wouldn't like to
> point out a fixed one. I just would like to make sure what I think is
> correct and is considered as "consensus".)
> Just consider the case as simple - someone files two different JIRA issues
> for new features and assigns to him/herself altogether, without sharing
> anything about the ongoing efforts someone has made. (So you have no idea
> even someone just files two different JIRA issues without "any" progress
> and has them in a backlog.) The new features are not new and are likely
> something others could work in parallel.
> That said, committers can explicitly represent "I'm working on this so
> please refrain from making redundant efforts." via assigning the issue,
> which is actually similar to the comment "I'm working on this".
> Unfortunately, this works only when the feature is something one who filed
> a JIRA issue works uniquely. Occasional opposite cases aren't always a
> notion of ignoring the signal of "I'm working on this". There're also
> coincidences two different individuals/teams are working on exactly the
> same at the same time.
> My concern is that "assignment" might be considered pretty much stronger
> than just commenting "I'm working on this" - it's like "Regardless of your
> current progress, I started working on this so don't consider your effort
> to be proposable. You should have filed the JIRA issue before I file one."
> Is it possible for contributors to do the same? I guess not.
> The other problem is the multiple assignments in parallel. I wouldn't like
> to guess someone over-uses the power of assignments, but technically it's
> simply possible that someone can file JIRA issues on his/her backlog which
> can be done in a couple of months or so with assigning to him/herself,
> which effectively blocks others from working or proposing the same. I
> consider this as preemptive which sounds bad and even unfair.
> On Fri, Feb 19, 2021 at 12:14 AM Sean Owen <> wrote:
>> I think it's OK to raise particular instances. It's hard for me to
>> evaluate further in the abstract.
>> I don't think we use Assignee much at all, except to kinda give credit
>> when something is done. No piece of code or work can be solely owned by one
>> person; this is just ASF policy.
>> I think we've seen the occasional opposite case too: someone starts
>> working on an issue, and then someone else also starts working on it with a
>> competing fix or change.
>> These are ultimately issues of communication. If an issue is pretty
>> stalled, and you have a proposal, nothing wrong with just going ahead with
>> a proposal. There may be no disagreement. It might result in the
>> other person joining your PR. As I say, not sure if there's a deeper issue
>> than that if even this hasn't been tried?
>> On Mon, Feb 15, 2021 at 8:35 PM Jungtaek Lim <
>>> wrote:
>>> Thanks for the input, Hyukjin!
>>> I have been keeping my own policy among all discussions I have raised -
>>> I would provide the hypothetical example closer to the actual one and avoid
>>> pointing out directly. The main purpose of the discussion is to ensure our
>>> policy / consensus makes sense, no more. I can provide a more detailed
>>> explanation if someone feels the explanation wasn't sufficient to
>>> understand.
>>> Probably this discussion could play as a "reminder" to every committers
>>> if similar discussion was raised before and it succeeded to build
>>> consensus. If there's some point we don't build consensus yet, it'd be a
>>> good time to discuss further. I don't know what exactly was the discussion
>>> and the result so what is new here, but I guess this might be a duplicated
>>> one as you say similar issue.
>>> On Tue, Feb 16, 2021 at 11:09 AM Hyukjin Kwon <>
>>> wrote:
>>>> I remember I raised a similar issue a long time ago in the dev mailing
>>>> list. I agree that setting no assignee makes sense in most of the cases,
>>>> and also think we share similar thoughts about the assignee on
>>>> umbrella JIRAs, followup tasks, the case when it's clear with a design doc,
>>>> etc.
>>>> It makes me think that the actual issue by setting an assignee happens
>>>> rarely, and it is an issue to several specific cases that would need a look
>>>> case-by-case.
>>>> Were there specific cases that made you concerned?
>>>> 2021년 2월 15일 (월) 오전 8:58, Jungtaek Lim <>님이
>>>> 작성:
>>>>> Hi devs,
>>>>> I'd like to raise a discussion and hear voices on the "assignee"
>>>>> practice on committers which may lead issues on preemption.
>>>>> I feel this is the one of major unfairnesses between contributors and
>>>>> committers if used improperly, especially when someone assigns themselves
>>>>> with multiple JIRA issues.
>>>>> Let's say there're features A and B, which may take a month for each
>>>>> (or require design doc) - both are individual major features, not
>>>>> subtasks or some sort of "follow-up".
>>>>> Technically, committers can file two JIRA issues and assign both of
>>>>> issues, "without actually doing no progress", and implicitly ensure no
>>>>> works on these issues for a couple of months. Even just a plan on backlog
>>>>> can prevent others from taking up.
>>>>> I don't think this is fair with contributors, because contributors
>>>>> don't tend to file an JIRA issue unless they made a lot of progress.
>>>>> like to remind you, competition from contributor's position is quite
>>>>> and stressful.) Say they already spent a month working on it and testing
>>>>> in production. They feel ready and visit JIRA, and realize the JIRA issue
>>>>> was made and assigned to someone, while there's no progress on the JIRA
>>>>> issue. No idea how much progress "someone" makes. They "might" ask about
>>>>> the progress, but nothing will change if "someone" simply says "I'm still
>>>>> working on this" (with even 1% of progress). Isn't this actually against
>>>>> the reason we don't allow setting assignee to contributor?
>>>>> For sure, assigning the issue would make sense if the issue is a
>>>>> subtask or follow-up, or the issue made explicit progress like design
>>>>> is being put. In other cases I don't see any reason assigning the issue
>>>>> explicitly. Someone may say to contributors, just leave a comment "I'm
>>>>> working on it", but isn't it also something committers can also do when
>>>>> they are "actually" working?
>>>>> I think committers should have no advantage on the possible
>>>>> competition on contribution, and setting assignee without explicit progress
>>>>> makes me worried.
>>>>> To make it fair, either we should allow contributors to assign them or
>>>>> don't allow committers to assign them unless extreme cases - they can
>>>>> use the approach contributors do.
>>>>> (Again I'd feel OK to assign if there's a design doc proving that they
>>>>> really spent non-trivial effort already. My point is preempting JIRA
>>>>> with only sketched ideas or even just rationalizations.)
>>>>> Would like to hear everyone's voices.
>>>>> Thanks,
>>>>> Jungtaek Lim (HeartSaVioR)
>>>>> ps. better yet, probably it's better then to restrict something
>>>>> explicitly if we sincerely respect the underlying culture on the statement
>>>>> "In case several people contributed, prefer to assign to the more ‘junior’,
>>>>> non-committer contributor".

View raw message