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