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