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 <kabhwan.opensou...@gmail.com> wrote: > (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". >>>>> >>>>> >>>>>
