+1 on Option A. Seems like it'll require an INFRA ticket though.
On Sun, Feb 2, 2020 at 9:03 PM David Smiley <david.w.smi...@gmail.com> wrote: > I think too often a "Fix Version" is set prematurely, especially by > contributors who don't know better and seem to choose arbitrary values, > thus making this JIRA field less meaningful. Ideally it is set on > resolution. We've also used it to assign issues to releases in advance to > avoid forgetting about them.[1] The permissions on this field in JIRA > appears to be a bit unique[2]; it's tied to the ability to "Resolve" > issues. Reporters (who could be anybody) can resolve issues (e.g. to > close) can thus set the fix version. I can see a couple options to improve > the situation *and we could do both*. I propose we do both in fact. > > Option A: Remove "Fix Version" from the "create issue" screen. > If *usually* this shouldn't be set on issue creation, then let's remove > the temptation to set it here. Many contributors, I think, only ever see > the create-issue screen and won't edit the issue, which we'll leave open > for the ability to set this field. Implementing this appears easy as we've > got our own project-specific screen to manipulate. > > Option B: Revoke the "Resolve" permission for the Reporter. > It seems unusual for simple contributors to "Resolve" the issue. They > might note it's a duplicate after-the-fact but it seems quite rare to me; > it's usually us committers (who retain the right to Resolve any issue) who > point out a duplicate or perhaps decide the issue is a "Won't-Fix" or > whatever. Implementing this proposal would require moving to a > project-specific permission scheme instead of using the default one that's > in use by 349 projects. > > [1]: We might stop the practice of using fix-version as a TODO for > unresolved issues, and thus fix-version would simply only ever get set for > resolved issues and thus be editable on a resolution screen. But what > other approach? Maybe Priority of Blocker, though it wouldn't > differentiate the next-major release from the next-minor one. Shrug; the > status quo is fine I guess. > > [2]: > https://confluence.atlassian.com/adminjiraserver083/managing-project-permissions-976767811.html > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley > -- Anshum Gupta
