Issue filed: https://issues.apache.org/jira/browse/INFRA-19835
~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Fri, Feb 7, 2020 at 4:27 PM Anshum Gupta <[email protected]> wrote: > +1 on Option A. > > Seems like it'll require an INFRA ticket though. > > On Sun, Feb 2, 2020 at 9:03 PM 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 >> > > > -- > Anshum Gupta >
