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". >>> >>> >>>
