(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 <sro...@gmail.com> 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 <kabhwan.opensou...@gmail.com> > 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 <gurwls...@gmail.com> >> 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 <kabhwan.opensou...@gmail.com>님이 >>> 작성: >>> >>>> 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". >>>> >>>> >>>>
