You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by Sean Busbey <bu...@cloudera.com> on 2015/03/13 16:32:03 UTC
Jira role cleanup
FYI, some time next week I'm going to try to simplify our jira role list.
When I go to add new contributors it takes forever, I'm guessing because of
the list size.
I think I can trim it down some by making sure folks who are committers are
in the committer list and not the contributor list. AFAICT, our jira is set
to allow committers to do a proper superset of what contributors can do.
Some folks are already listed in both. I'll send a summary email warning
about what new powers folks have if there is anyone who's currently only in
the contributor list.
--
Sean
Re: Jira role cleanup
Posted by Ted Yu <yu...@gmail.com>.
bq. Beyond that I agree that we should limit this to a known set of people
(the contributors).
+1
bq. Maybe discuss this briefly at the next PMC meeting
+1 too.
On Sun, Mar 15, 2015 at 11:12 PM, lars hofhansl <la...@apache.org> wrote:
> Hmm... This is interesting. I think Jira management should be left to the
> committers. One can pretty much mess up a release, and make it hard to
> account for what's in and what's not when jiras are changed the around (the
> ultimate truth can be reconstructed from the git commit records, but that's
> tedious).
> Minimally somebody needs to be able to assign a jira to the person
> providing the patch, if those are committers only that's tedious but OK -
> we've been doing that anyway.Ideally the person could assign an _open_
> issue to him/herself and log work against an issue and change the due data.
> Those seem abilities we could grant to everybody as long as they are
> limited to open issues.
> Beyond that I agree that we should limit this to a known set of people
> (the contributors). Maybe discuss this briefly at the next PMC meeting,
> we're due to have one anyway. I'm willing to host one at Salesforce.
>
> -- Lars
>
> From: Sean Busbey <bu...@cloudera.com>
> To: dev <de...@hbase.apache.org>; lars hofhansl <la...@apache.org>
> Sent: Sunday, March 15, 2015 9:46 PM
> Subject: Re: Jira role cleanup
>
> I can make it so that issues can be assigned to non-contributors. Even if
> we don't do that, I believe jira permissions are all about constraining
> current actions, and are not enforced on existing ticketes.
>
> However, the "contributor" role in jira has several other abilities
> associated with it. Right now, in the order they appear in jira:
>
> * edit an issue's due date
> * move issues (between project workflows or projects the user has create
> on)
> * assign issues to other people
> * resolve and reopen issues, assign a fix version (but not close them)
> * manage watchers on an issue
> * log work against an issue
>
> Any of these could also be changed to remove contributors or allow wider
> jira users.
>
> If assignable users can assign to themselves when they don't have the
> assign users permission, then the only one I think we use is "resolve and
> reopen issues." And I don't think I'd want that open to all jira users.
>
> Do we want to have to handle marking issues resolved for folks? It makes
> sense to me, since I usually do that once I push the commit.
>
>
>
>
>
> On Sun, Mar 15, 2015 at 11:07 PM, lars hofhansl <la...@apache.org> wrote:
>
> > Not sure what jira does about an assignee when (s)he is removed from the
> > contributors list (I know you have to add a person to the contributors
> list
> > order to assign a jira to them).Other than the committers, we probably
> have
> > at least one jira assigned to a contributor (otherwise why add him/her as
> > contributor).
> > Can we change the jira rules in our space to allow assigning jiras to
> > users even when they're not listed as contributors?
> > We do not have a formal contributor status (why not?), so this list is
> > only needed because of jira.
> > -- Lars
> >
> > From: Sean Busbey <bu...@cloudera.com>
> > To: dev <de...@hbase.apache.org>
> > Sent: Friday, March 13, 2015 9:09 AM
> > Subject: Re: Jira role cleanup
> >
> > On Fri, Mar 13, 2015 at 11:01 AM, Andrew Purtell <ap...@apache.org>
> > wrote:
> >
> > > +1
> > > I think it would be fine to trim the contributor list too. We can
> always
> > > add people back on demand in order to (re)assign issues.
> > >
> > >
> > I wasn't sure how we generate the list of contributors. But then I
> noticed
> > that we don't link to jira for it like I thought we did[1].
> >
> > How about I make a saved jira query for people who have had jira's
> assigned
> > to them, add a link to that query for our "here are the contributors"
> > section, and then trim off from the role anyone who hasn't been assigned
> an
> > issue in the last year?
> >
> >
> > [1]: http://hbase.apache.org/team-list.html
> >
> >
> >
> > --
> > Sean
> >
> >
> >
> >
>
>
>
> --
> Sean
>
>
>
>
Re: Jira role cleanup
Posted by Sean Busbey <bu...@cloudera.com>.
Okay, it sounds like there's decent consensus. How much of this cleanup can
I take care of before the PMC meets?
Everyone fine if I do the earlier pruning we talked about and look into the
"anyone is assignable" bit?
On Mon, Mar 16, 2015 at 12:38 PM, Andrew Purtell <ap...@apache.org>
wrote:
> > I think Jira management should be left to the committers. One can pretty
> much mess up a release, and make it hard to account for what's in and
> what's not when jiras are changed the around (the ultimate truth can be
> reconstructed from the git commit records, but that's tedious).
>
> I agree we should avoid allowing contributors to change JIRA metadata if
> this is possible to restrict. Our commit log conventions aren't universally
> followed, due to human error, so they are not all tagged with issue
> identifiers, or the correct identifier.
>
>
>
I'm conflicted on this bit. Incrementally giving people more responsibility
is our best path to good decisions wrt new committers. I think it makes
sense to not give every new contributor the ability to set fix versions. On
the other hand, I'm sure there will be folks that I trust to accurately set
that metadata before they become committers. And what about folks who
contribute by helping to clean up said jira metadata?
When y'all discuss this, could someone please advocate a middle ground
where we no longer default to all contributors get metadata edit rights,
but we maintain a jira role that can be granted at the discretion of
existing jira admins (or commiters, or PMC or whatever y'all are
comfortable with)?
--
Sean
Re: Jira role cleanup
Posted by Sean Busbey <bu...@cloudera.com>.
On Mon, Mar 16, 2015 at 1:28 PM, Andrew Purtell <ap...@apache.org> wrote:
> On Mon, Mar 16, 2015 at 11:02 AM, Nick Dimiduk <nd...@gmail.com> wrote:
>
> > bq. Our commit log conventions aren't universally followed, due to human
> > error
> >
> > Going forward, I think we can alleviate this issue with a git hook and a
> > regexp.
> >
>
> That's a good idea.
>
>
>
FYI, ASF Infra doesn't allow custom server side git hooks[1] and I couldn't
find anything that does message enforcement casually checking in the asf
git hooks[2].
It looks like Apache Cloudstack has some client side hooks they recommend
for committers that do commit message enforcement[3]. We could use
something similar.
[1]: http://www.apache.org/dev/writable-git (last bullet)
[2]: http://s.apache.org/qxT
[3]:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-CommitMessages
--
Sean
Re: Jira role cleanup
Posted by Andrew Purtell <ap...@apache.org>.
On Mon, Mar 16, 2015 at 11:02 AM, Nick Dimiduk <nd...@gmail.com> wrote:
> bq. Our commit log conventions aren't universally followed, due to human
> error
>
> Going forward, I think we can alleviate this issue with a git hook and a
> regexp.
>
That's a good idea.
> On Mon, Mar 16, 2015 at 10:38 AM, Andrew Purtell <ap...@apache.org>
> wrote:
>
> > > I think Jira management should be left to the committers. One can
> pretty
> > much mess up a release, and make it hard to account for what's in and
> > what's not when jiras are changed the around (the ultimate truth can be
> > reconstructed from the git commit records, but that's tedious).
> >
> > I agree we should avoid allowing contributors to change JIRA metadata if
> > this is possible to restrict. Our commit log conventions aren't
> universally
> > followed, due to human error, so they are not all tagged with issue
> > identifiers, or the correct identifier.
> >
> >
> >
> > On Sun, Mar 15, 2015 at 11:12 PM, lars hofhansl <la...@apache.org>
> wrote:
> >
> > > Hmm... This is interesting. I think Jira management should be left to
> the
> > > committers. One can pretty much mess up a release, and make it hard to
> > > account for what's in and what's not when jiras are changed the around
> > (the
> > > ultimate truth can be reconstructed from the git commit records, but
> > that's
> > > tedious).
> > > Minimally somebody needs to be able to assign a jira to the person
> > > providing the patch, if those are committers only that's tedious but
> OK -
> > > we've been doing that anyway.Ideally the person could assign an _open_
> > > issue to him/herself and log work against an issue and change the due
> > data.
> > > Those seem abilities we could grant to everybody as long as they are
> > > limited to open issues.
> > > Beyond that I agree that we should limit this to a known set of people
> > > (the contributors). Maybe discuss this briefly at the next PMC meeting,
> > > we're due to have one anyway. I'm willing to host one at Salesforce.
> > >
> > > -- Lars
> > >
> > > From: Sean Busbey <bu...@cloudera.com>
> > > To: dev <de...@hbase.apache.org>; lars hofhansl <la...@apache.org>
> > > Sent: Sunday, March 15, 2015 9:46 PM
> > > Subject: Re: Jira role cleanup
> > >
> > > I can make it so that issues can be assigned to non-contributors. Even
> if
> > > we don't do that, I believe jira permissions are all about constraining
> > > current actions, and are not enforced on existing ticketes.
> > >
> > > However, the "contributor" role in jira has several other abilities
> > > associated with it. Right now, in the order they appear in jira:
> > >
> > > * edit an issue's due date
> > > * move issues (between project workflows or projects the user has
> create
> > > on)
> > > * assign issues to other people
> > > * resolve and reopen issues, assign a fix version (but not close them)
> > > * manage watchers on an issue
> > > * log work against an issue
> > >
> > > Any of these could also be changed to remove contributors or allow
> wider
> > > jira users.
> > >
> > > If assignable users can assign to themselves when they don't have the
> > > assign users permission, then the only one I think we use is "resolve
> and
> > > reopen issues." And I don't think I'd want that open to all jira users.
> > >
> > > Do we want to have to handle marking issues resolved for folks? It
> makes
> > > sense to me, since I usually do that once I push the commit.
> > >
> > >
> > >
> > >
> > >
> > > On Sun, Mar 15, 2015 at 11:07 PM, lars hofhansl <la...@apache.org>
> > wrote:
> > >
> > > > Not sure what jira does about an assignee when (s)he is removed from
> > the
> > > > contributors list (I know you have to add a person to the
> contributors
> > > list
> > > > order to assign a jira to them).Other than the committers, we
> probably
> > > have
> > > > at least one jira assigned to a contributor (otherwise why add
> him/her
> > as
> > > > contributor).
> > > > Can we change the jira rules in our space to allow assigning jiras to
> > > > users even when they're not listed as contributors?
> > > > We do not have a formal contributor status (why not?), so this list
> is
> > > > only needed because of jira.
> > > > -- Lars
> > > >
> > > > From: Sean Busbey <bu...@cloudera.com>
> > > > To: dev <de...@hbase.apache.org>
> > > > Sent: Friday, March 13, 2015 9:09 AM
> > > > Subject: Re: Jira role cleanup
> > > >
> > > > On Fri, Mar 13, 2015 at 11:01 AM, Andrew Purtell <
> apurtell@apache.org>
> > > > wrote:
> > > >
> > > > > +1
> > > > > I think it would be fine to trim the contributor list too. We can
> > > always
> > > > > add people back on demand in order to (re)assign issues.
> > > > >
> > > > >
> > > > I wasn't sure how we generate the list of contributors. But then I
> > > noticed
> > > > that we don't link to jira for it like I thought we did[1].
> > > >
> > > > How about I make a saved jira query for people who have had jira's
> > > assigned
> > > > to them, add a link to that query for our "here are the contributors"
> > > > section, and then trim off from the role anyone who hasn't been
> > assigned
> > > an
> > > > issue in the last year?
> > > >
> > > >
> > > > [1]: http://hbase.apache.org/team-list.html
> > > >
> > > >
> > > >
> > > > --
> > > > Sean
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Sean
> > >
> > >
> > >
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: Jira role cleanup
Posted by Nick Dimiduk <nd...@gmail.com>.
bq. Our commit log conventions aren't universally followed, due to human
error
Going forward, I think we can alleviate this issue with a git hook and a
regexp.
On Mon, Mar 16, 2015 at 10:38 AM, Andrew Purtell <ap...@apache.org>
wrote:
> > I think Jira management should be left to the committers. One can pretty
> much mess up a release, and make it hard to account for what's in and
> what's not when jiras are changed the around (the ultimate truth can be
> reconstructed from the git commit records, but that's tedious).
>
> I agree we should avoid allowing contributors to change JIRA metadata if
> this is possible to restrict. Our commit log conventions aren't universally
> followed, due to human error, so they are not all tagged with issue
> identifiers, or the correct identifier.
>
>
>
> On Sun, Mar 15, 2015 at 11:12 PM, lars hofhansl <la...@apache.org> wrote:
>
> > Hmm... This is interesting. I think Jira management should be left to the
> > committers. One can pretty much mess up a release, and make it hard to
> > account for what's in and what's not when jiras are changed the around
> (the
> > ultimate truth can be reconstructed from the git commit records, but
> that's
> > tedious).
> > Minimally somebody needs to be able to assign a jira to the person
> > providing the patch, if those are committers only that's tedious but OK -
> > we've been doing that anyway.Ideally the person could assign an _open_
> > issue to him/herself and log work against an issue and change the due
> data.
> > Those seem abilities we could grant to everybody as long as they are
> > limited to open issues.
> > Beyond that I agree that we should limit this to a known set of people
> > (the contributors). Maybe discuss this briefly at the next PMC meeting,
> > we're due to have one anyway. I'm willing to host one at Salesforce.
> >
> > -- Lars
> >
> > From: Sean Busbey <bu...@cloudera.com>
> > To: dev <de...@hbase.apache.org>; lars hofhansl <la...@apache.org>
> > Sent: Sunday, March 15, 2015 9:46 PM
> > Subject: Re: Jira role cleanup
> >
> > I can make it so that issues can be assigned to non-contributors. Even if
> > we don't do that, I believe jira permissions are all about constraining
> > current actions, and are not enforced on existing ticketes.
> >
> > However, the "contributor" role in jira has several other abilities
> > associated with it. Right now, in the order they appear in jira:
> >
> > * edit an issue's due date
> > * move issues (between project workflows or projects the user has create
> > on)
> > * assign issues to other people
> > * resolve and reopen issues, assign a fix version (but not close them)
> > * manage watchers on an issue
> > * log work against an issue
> >
> > Any of these could also be changed to remove contributors or allow wider
> > jira users.
> >
> > If assignable users can assign to themselves when they don't have the
> > assign users permission, then the only one I think we use is "resolve and
> > reopen issues." And I don't think I'd want that open to all jira users.
> >
> > Do we want to have to handle marking issues resolved for folks? It makes
> > sense to me, since I usually do that once I push the commit.
> >
> >
> >
> >
> >
> > On Sun, Mar 15, 2015 at 11:07 PM, lars hofhansl <la...@apache.org>
> wrote:
> >
> > > Not sure what jira does about an assignee when (s)he is removed from
> the
> > > contributors list (I know you have to add a person to the contributors
> > list
> > > order to assign a jira to them).Other than the committers, we probably
> > have
> > > at least one jira assigned to a contributor (otherwise why add him/her
> as
> > > contributor).
> > > Can we change the jira rules in our space to allow assigning jiras to
> > > users even when they're not listed as contributors?
> > > We do not have a formal contributor status (why not?), so this list is
> > > only needed because of jira.
> > > -- Lars
> > >
> > > From: Sean Busbey <bu...@cloudera.com>
> > > To: dev <de...@hbase.apache.org>
> > > Sent: Friday, March 13, 2015 9:09 AM
> > > Subject: Re: Jira role cleanup
> > >
> > > On Fri, Mar 13, 2015 at 11:01 AM, Andrew Purtell <ap...@apache.org>
> > > wrote:
> > >
> > > > +1
> > > > I think it would be fine to trim the contributor list too. We can
> > always
> > > > add people back on demand in order to (re)assign issues.
> > > >
> > > >
> > > I wasn't sure how we generate the list of contributors. But then I
> > noticed
> > > that we don't link to jira for it like I thought we did[1].
> > >
> > > How about I make a saved jira query for people who have had jira's
> > assigned
> > > to them, add a link to that query for our "here are the contributors"
> > > section, and then trim off from the role anyone who hasn't been
> assigned
> > an
> > > issue in the last year?
> > >
> > >
> > > [1]: http://hbase.apache.org/team-list.html
> > >
> > >
> > >
> > > --
> > > Sean
> > >
> > >
> > >
> > >
> >
> >
> >
> > --
> > Sean
> >
> >
> >
> >
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
Re: Jira role cleanup
Posted by Andrew Purtell <ap...@apache.org>.
> I think Jira management should be left to the committers. One can pretty
much mess up a release, and make it hard to account for what's in and
what's not when jiras are changed the around (the ultimate truth can be
reconstructed from the git commit records, but that's tedious).
I agree we should avoid allowing contributors to change JIRA metadata if
this is possible to restrict. Our commit log conventions aren't universally
followed, due to human error, so they are not all tagged with issue
identifiers, or the correct identifier.
On Sun, Mar 15, 2015 at 11:12 PM, lars hofhansl <la...@apache.org> wrote:
> Hmm... This is interesting. I think Jira management should be left to the
> committers. One can pretty much mess up a release, and make it hard to
> account for what's in and what's not when jiras are changed the around (the
> ultimate truth can be reconstructed from the git commit records, but that's
> tedious).
> Minimally somebody needs to be able to assign a jira to the person
> providing the patch, if those are committers only that's tedious but OK -
> we've been doing that anyway.Ideally the person could assign an _open_
> issue to him/herself and log work against an issue and change the due data.
> Those seem abilities we could grant to everybody as long as they are
> limited to open issues.
> Beyond that I agree that we should limit this to a known set of people
> (the contributors). Maybe discuss this briefly at the next PMC meeting,
> we're due to have one anyway. I'm willing to host one at Salesforce.
>
> -- Lars
>
> From: Sean Busbey <bu...@cloudera.com>
> To: dev <de...@hbase.apache.org>; lars hofhansl <la...@apache.org>
> Sent: Sunday, March 15, 2015 9:46 PM
> Subject: Re: Jira role cleanup
>
> I can make it so that issues can be assigned to non-contributors. Even if
> we don't do that, I believe jira permissions are all about constraining
> current actions, and are not enforced on existing ticketes.
>
> However, the "contributor" role in jira has several other abilities
> associated with it. Right now, in the order they appear in jira:
>
> * edit an issue's due date
> * move issues (between project workflows or projects the user has create
> on)
> * assign issues to other people
> * resolve and reopen issues, assign a fix version (but not close them)
> * manage watchers on an issue
> * log work against an issue
>
> Any of these could also be changed to remove contributors or allow wider
> jira users.
>
> If assignable users can assign to themselves when they don't have the
> assign users permission, then the only one I think we use is "resolve and
> reopen issues." And I don't think I'd want that open to all jira users.
>
> Do we want to have to handle marking issues resolved for folks? It makes
> sense to me, since I usually do that once I push the commit.
>
>
>
>
>
> On Sun, Mar 15, 2015 at 11:07 PM, lars hofhansl <la...@apache.org> wrote:
>
> > Not sure what jira does about an assignee when (s)he is removed from the
> > contributors list (I know you have to add a person to the contributors
> list
> > order to assign a jira to them).Other than the committers, we probably
> have
> > at least one jira assigned to a contributor (otherwise why add him/her as
> > contributor).
> > Can we change the jira rules in our space to allow assigning jiras to
> > users even when they're not listed as contributors?
> > We do not have a formal contributor status (why not?), so this list is
> > only needed because of jira.
> > -- Lars
> >
> > From: Sean Busbey <bu...@cloudera.com>
> > To: dev <de...@hbase.apache.org>
> > Sent: Friday, March 13, 2015 9:09 AM
> > Subject: Re: Jira role cleanup
> >
> > On Fri, Mar 13, 2015 at 11:01 AM, Andrew Purtell <ap...@apache.org>
> > wrote:
> >
> > > +1
> > > I think it would be fine to trim the contributor list too. We can
> always
> > > add people back on demand in order to (re)assign issues.
> > >
> > >
> > I wasn't sure how we generate the list of contributors. But then I
> noticed
> > that we don't link to jira for it like I thought we did[1].
> >
> > How about I make a saved jira query for people who have had jira's
> assigned
> > to them, add a link to that query for our "here are the contributors"
> > section, and then trim off from the role anyone who hasn't been assigned
> an
> > issue in the last year?
> >
> >
> > [1]: http://hbase.apache.org/team-list.html
> >
> >
> >
> > --
> > Sean
> >
> >
> >
> >
>
>
>
> --
> Sean
>
>
>
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: Jira role cleanup
Posted by lars hofhansl <la...@apache.org>.
Hmm... This is interesting. I think Jira management should be left to the committers. One can pretty much mess up a release, and make it hard to account for what's in and what's not when jiras are changed the around (the ultimate truth can be reconstructed from the git commit records, but that's tedious).
Minimally somebody needs to be able to assign a jira to the person providing the patch, if those are committers only that's tedious but OK - we've been doing that anyway.Ideally the person could assign an _open_ issue to him/herself and log work against an issue and change the due data. Those seem abilities we could grant to everybody as long as they are limited to open issues.
Beyond that I agree that we should limit this to a known set of people (the contributors). Maybe discuss this briefly at the next PMC meeting, we're due to have one anyway. I'm willing to host one at Salesforce.
-- Lars
From: Sean Busbey <bu...@cloudera.com>
To: dev <de...@hbase.apache.org>; lars hofhansl <la...@apache.org>
Sent: Sunday, March 15, 2015 9:46 PM
Subject: Re: Jira role cleanup
I can make it so that issues can be assigned to non-contributors. Even if
we don't do that, I believe jira permissions are all about constraining
current actions, and are not enforced on existing ticketes.
However, the "contributor" role in jira has several other abilities
associated with it. Right now, in the order they appear in jira:
* edit an issue's due date
* move issues (between project workflows or projects the user has create on)
* assign issues to other people
* resolve and reopen issues, assign a fix version (but not close them)
* manage watchers on an issue
* log work against an issue
Any of these could also be changed to remove contributors or allow wider
jira users.
If assignable users can assign to themselves when they don't have the
assign users permission, then the only one I think we use is "resolve and
reopen issues." And I don't think I'd want that open to all jira users.
Do we want to have to handle marking issues resolved for folks? It makes
sense to me, since I usually do that once I push the commit.
On Sun, Mar 15, 2015 at 11:07 PM, lars hofhansl <la...@apache.org> wrote:
> Not sure what jira does about an assignee when (s)he is removed from the
> contributors list (I know you have to add a person to the contributors list
> order to assign a jira to them).Other than the committers, we probably have
> at least one jira assigned to a contributor (otherwise why add him/her as
> contributor).
> Can we change the jira rules in our space to allow assigning jiras to
> users even when they're not listed as contributors?
> We do not have a formal contributor status (why not?), so this list is
> only needed because of jira.
> -- Lars
>
> From: Sean Busbey <bu...@cloudera.com>
> To: dev <de...@hbase.apache.org>
> Sent: Friday, March 13, 2015 9:09 AM
> Subject: Re: Jira role cleanup
>
> On Fri, Mar 13, 2015 at 11:01 AM, Andrew Purtell <ap...@apache.org>
> wrote:
>
> > +1
> > I think it would be fine to trim the contributor list too. We can always
> > add people back on demand in order to (re)assign issues.
> >
> >
> I wasn't sure how we generate the list of contributors. But then I noticed
> that we don't link to jira for it like I thought we did[1].
>
> How about I make a saved jira query for people who have had jira's assigned
> to them, add a link to that query for our "here are the contributors"
> section, and then trim off from the role anyone who hasn't been assigned an
> issue in the last year?
>
>
> [1]: http://hbase.apache.org/team-list.html
>
>
>
> --
> Sean
>
>
>
>
--
Sean
Re: Jira role cleanup
Posted by Sean Busbey <bu...@cloudera.com>.
I can make it so that issues can be assigned to non-contributors. Even if
we don't do that, I believe jira permissions are all about constraining
current actions, and are not enforced on existing ticketes.
However, the "contributor" role in jira has several other abilities
associated with it. Right now, in the order they appear in jira:
* edit an issue's due date
* move issues (between project workflows or projects the user has create on)
* assign issues to other people
* resolve and reopen issues, assign a fix version (but not close them)
* manage watchers on an issue
* log work against an issue
Any of these could also be changed to remove contributors or allow wider
jira users.
If assignable users can assign to themselves when they don't have the
assign users permission, then the only one I think we use is "resolve and
reopen issues." And I don't think I'd want that open to all jira users.
Do we want to have to handle marking issues resolved for folks? It makes
sense to me, since I usually do that once I push the commit.
On Sun, Mar 15, 2015 at 11:07 PM, lars hofhansl <la...@apache.org> wrote:
> Not sure what jira does about an assignee when (s)he is removed from the
> contributors list (I know you have to add a person to the contributors list
> order to assign a jira to them).Other than the committers, we probably have
> at least one jira assigned to a contributor (otherwise why add him/her as
> contributor).
> Can we change the jira rules in our space to allow assigning jiras to
> users even when they're not listed as contributors?
> We do not have a formal contributor status (why not?), so this list is
> only needed because of jira.
> -- Lars
>
> From: Sean Busbey <bu...@cloudera.com>
> To: dev <de...@hbase.apache.org>
> Sent: Friday, March 13, 2015 9:09 AM
> Subject: Re: Jira role cleanup
>
> On Fri, Mar 13, 2015 at 11:01 AM, Andrew Purtell <ap...@apache.org>
> wrote:
>
> > +1
> > I think it would be fine to trim the contributor list too. We can always
> > add people back on demand in order to (re)assign issues.
> >
> >
> I wasn't sure how we generate the list of contributors. But then I noticed
> that we don't link to jira for it like I thought we did[1].
>
> How about I make a saved jira query for people who have had jira's assigned
> to them, add a link to that query for our "here are the contributors"
> section, and then trim off from the role anyone who hasn't been assigned an
> issue in the last year?
>
>
> [1]: http://hbase.apache.org/team-list.html
>
>
>
> --
> Sean
>
>
>
>
--
Sean
Re: Jira role cleanup
Posted by lars hofhansl <la...@apache.org>.
Not sure what jira does about an assignee when (s)he is removed from the contributors list (I know you have to add a person to the contributors list order to assign a jira to them).Other than the committers, we probably have at least one jira assigned to a contributor (otherwise why add him/her as contributor).
Can we change the jira rules in our space to allow assigning jiras to users even when they're not listed as contributors?
We do not have a formal contributor status (why not?), so this list is only needed because of jira.
-- Lars
From: Sean Busbey <bu...@cloudera.com>
To: dev <de...@hbase.apache.org>
Sent: Friday, March 13, 2015 9:09 AM
Subject: Re: Jira role cleanup
On Fri, Mar 13, 2015 at 11:01 AM, Andrew Purtell <ap...@apache.org>
wrote:
> +1
> I think it would be fine to trim the contributor list too. We can always
> add people back on demand in order to (re)assign issues.
>
>
I wasn't sure how we generate the list of contributors. But then I noticed
that we don't link to jira for it like I thought we did[1].
How about I make a saved jira query for people who have had jira's assigned
to them, add a link to that query for our "here are the contributors"
section, and then trim off from the role anyone who hasn't been assigned an
issue in the last year?
[1]: http://hbase.apache.org/team-list.html
--
Sean
Re: Jira role cleanup
Posted by lars hofhansl <la...@apache.org>.
I was advocating a more formal "Contributor" role before, so that we can recognize folks for contributing, without making them committers right away.So I'm in favor of this!
-- Lars
From: Andrew Purtell <ap...@apache.org>
To: "dev@hbase.apache.org" <de...@hbase.apache.org>
Sent: Friday, March 13, 2015 9:31 AM
Subject: Re: Jira role cleanup
>
How about I make a saved jira query for people who have had jira's assigned
>
to them, add a link to that query for our "here are the contributors"
>
section, and then trim off from the role anyone who hasn't been assigned an
>
issue in the last year?
That sounds like a very fair proposition. The JIRA role list isn't public I
think, but just in case. Anyway, there's every reason to call out our
contributors publicly and offer acknowledgement as thanks.
On Fri, Mar 13, 2015 at 9:09 AM, Sean Busbey <bu...@cloudera.com> wrote:
> On Fri, Mar 13, 2015 at 11:01 AM, Andrew Purtell <ap...@apache.org>
> wrote:
>
> > +1
> > I think it would be fine to trim the contributor list too. We can always
> > add people back on demand in order to (re)assign issues.
> >
> >
> I wasn't sure how we generate the list of contributors. But then I noticed
> that we don't link to jira for it like I thought we did[1].
>
>
> How about I make a saved jira query for people who have had jira's assigned
> to them, add a link to that query for our "here are the contributors"
> section, and then trim off from the role anyone who hasn't been assigned an
> issue in the last year?
>
>
> [1]: http://hbase.apache.org/team-list.html
>
> --
> Sean
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: Jira role cleanup
Posted by Andrew Purtell <ap...@apache.org>.
>
How about I make a saved jira query for people who have had jira's assigned
>
to them, add a link to that query for our "here are the contributors"
>
section, and then trim off from the role anyone who hasn't been assigned an
>
issue in the last year?
That sounds like a very fair proposition. The JIRA role list isn't public I
think, but just in case. Anyway, there's every reason to call out our
contributors publicly and offer acknowledgement as thanks.
On Fri, Mar 13, 2015 at 9:09 AM, Sean Busbey <bu...@cloudera.com> wrote:
> On Fri, Mar 13, 2015 at 11:01 AM, Andrew Purtell <ap...@apache.org>
> wrote:
>
> > +1
> > I think it would be fine to trim the contributor list too. We can always
> > add people back on demand in order to (re)assign issues.
> >
> >
> I wasn't sure how we generate the list of contributors. But then I noticed
> that we don't link to jira for it like I thought we did[1].
>
>
> How about I make a saved jira query for people who have had jira's assigned
> to them, add a link to that query for our "here are the contributors"
> section, and then trim off from the role anyone who hasn't been assigned an
> issue in the last year?
>
>
> [1]: http://hbase.apache.org/team-list.html
>
> --
> Sean
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: Jira role cleanup
Posted by Sean Busbey <bu...@cloudera.com>.
On Fri, Mar 13, 2015 at 11:01 AM, Andrew Purtell <ap...@apache.org>
wrote:
> +1
> I think it would be fine to trim the contributor list too. We can always
> add people back on demand in order to (re)assign issues.
>
>
I wasn't sure how we generate the list of contributors. But then I noticed
that we don't link to jira for it like I thought we did[1].
How about I make a saved jira query for people who have had jira's assigned
to them, add a link to that query for our "here are the contributors"
section, and then trim off from the role anyone who hasn't been assigned an
issue in the last year?
[1]: http://hbase.apache.org/team-list.html
--
Sean
Re: Jira role cleanup
Posted by Andrew Purtell <ap...@apache.org>.
+1
I think it would be fine to trim the contributor list too. We can always
add people back on demand in order to (re)assign issues.
On Fri, Mar 13, 2015 at 8:32 AM, Sean Busbey <bu...@cloudera.com> wrote:
> FYI, some time next week I'm going to try to simplify our jira role list.
> When I go to add new contributors it takes forever, I'm guessing because of
> the list size.
>
> I think I can trim it down some by making sure folks who are committers are
> in the committer list and not the contributor list. AFAICT, our jira is set
> to allow committers to do a proper superset of what contributors can do.
>
> Some folks are already listed in both. I'll send a summary email warning
> about what new powers folks have if there is anyone who's currently only in
> the contributor list.
>
> --
> Sean
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)