+1 on Option A. [-0] on Option B. Even though it might not be everyday, I don't think we should put roadblocks in front of users who want to clean up after themselves. We do occasionally see users create jira issues and then close them themselves when they realize user error or something else was at play.
On Mon, Feb 3, 2020 at 12:03 AM David Smiley <[email protected]> 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
