You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by David Smiley <da...@gmail.com> on 2020/02/03 05:03:35 UTC
Propose JIRA "Fix Version" remove from create-issue screen
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
Re: Propose JIRA "Fix Version" remove from create-issue screen
Posted by David Smiley <da...@gmail.com>.
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 <an...@anshumgupta.net> 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 <da...@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
>
Re: Propose JIRA "Fix Version" remove from create-issue screen
Posted by Anshum Gupta <an...@anshumgupta.net>.
+1 on Option A.
Seems like it'll require an INFRA ticket though.
On Sun, Feb 2, 2020 at 9:03 PM David Smiley <da...@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
Re: Propose JIRA "Fix Version" remove from create-issue screen
Posted by Cassandra Targett <ca...@gmail.com>.
Yes, you’re correct.
We currently have only one screen used for create, edit, and view in each project. To change which fields show in any one of those views, we need another screen. Only Jira administrators can make a screen and update the screen scheme to use it, and, for our Jira, only Infra are Jira administrators.
On Feb 7, 2020, 9:56 AM -0600, David Smiley <da...@gmail.com>, wrote:
> Cassandra:
> I believe you have more JIRA administrative experience than I. I notice Solr has one "screen" used for create, edit, and view. "SOLR-JIRA-PROJECT" is the name of the screen. It appears I need to request that a JIRA administrator create a new screen for us that is associated only with the "create issue" operation of the "screen scheme". Do you agree? Likewise for the Lucene project. I'll go file an Infra ticket.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> > On Mon, Feb 3, 2020 at 9:04 AM Eric Pugh <ep...@opensourceconnections.com> wrote:
> > > +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 <er...@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 <ge...@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 <da...@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-unsubscribe@lucene.apache.org
> > > > > > For additional commands, e-mail: dev-help@lucene.apache.org
> > > > > >
> > > > >
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > > > For additional commands, e-mail: dev-help@lucene.apache.org
> > > > >
Re: Propose JIRA "Fix Version" remove from create-issue screen
Posted by David Smiley <da...@gmail.com>.
Cassandra:
I believe you have more JIRA administrative experience than I. I notice
Solr has one "screen" used for create, edit, and view. "SOLR-JIRA-PROJECT"
is the name of the screen. It appears I need to request that a JIRA
administrator create a new screen for us that is associated only with the
"create issue" operation of the "screen scheme". Do you agree? Likewise
for the Lucene project. I'll go file an Infra ticket.
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley
On Mon, Feb 3, 2020 at 9:04 AM Eric Pugh <ep...@opensourceconnections.com>
wrote:
> +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 <er...@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 <ge...@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 <da...@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-unsubscribe@lucene.apache.org
>> > For additional commands, e-mail: dev-help@lucene.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
Re: Propose JIRA "Fix Version" remove from create-issue screen
Posted by Eric Pugh <ep...@opensourceconnections.com>.
+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 <er...@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 <ge...@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 <da...@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-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Propose JIRA "Fix Version" remove from create-issue screen
Posted by Erick Erickson <er...@gmail.com>.
+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 <ge...@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 <da...@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Propose JIRA "Fix Version" remove from create-issue screen
Posted by Jason Gerlowski <ge...@gmail.com>.
+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 <da...@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org