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 Thu, 18 Feb 2021 15:13:59 GMT
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 <>

> 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 one
>>> 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. (I'd like to
>>> remind you, competition from contributor's position is quite tense and
>>> stressful.) Say they already spent a month working on it and testing it 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 doc 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 still
>>> 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 issues
>>> 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