+1 as well. I have seen new contributors struggle with what setting that means... It can also set an expectation someone will just magically fix it!
On Mon, Feb 3, 2020 at 8:21 AM Erick Erickson <erickerick...@gmail.com> wrote: > +1 to option A. > > We can also remove the “fix version” whenever we notice it entered > prematurely. There’ll still be some that sneak through, but between > removing it from the create screen and fixing it when we notice, there’ll > be many fewer next time. Which is good enough. > > Yeah, using “blocker” is iffy the more I think about it, I don’t have much > of an opinion either way. It’s either “learn to ignore blockers that are > for a future version” or “look at everything that’s marked for the version > you’re releasing and is still open”. If we tighten up the “fix version”, > the second requires less effort…. > > > > On Feb 3, 2020, at 7:57 AM, Jason Gerlowski <gerlowsk...@gmail.com> > wrote: > > > > +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 <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 > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
