I agree, Assignee has been used primarily to give recognition to the contributor who ended up submitting the patch which got merged. Typically jira's remain unassigned - even if it were to be assigned, it conveys no meaning or ownership or ongoing work : IMO it is equivalent to an unassigned jira. There could ofcourse be discussions on dev@ or comments in the jira or design docs or WIP PR"s - but if a better approach comes along, or previous work stalls - contributors can (and please, must !) contribute to the jira. Ofcourse, if there is active work going on as a PR under review or SPIP/proposal being discussed - taking part in that process would help imo.
Regards, Mridul On Thu, Feb 18, 2021 at 11:00 PM Sean Owen <sro...@gmail.com> wrote: > 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". >>>>>> >>>>>> >>>>>>
