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 <[email protected]>
To: dev <[email protected]>; lars hofhansl <[email protected]>
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 <[email protected]> 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 <[email protected]>
> To: dev <[email protected]>
> Sent: Friday, March 13, 2015 9:09 AM
> Subject: Re: Jira role cleanup
>
> On Fri, Mar 13, 2015 at 11:01 AM, Andrew Purtell <[email protected]>
> 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
