I had suggested the same earlier. See below email I sent to the infrastructure group.
-------- Original Message -------- Subject: Re: Jasig JIRA allowing creator of Jira issue to be assigned the Jira issue Date: Wed, 18 Dec 2013 15:07:26 -0700 From: James Wennmacher <[email protected]> To: Jim Helwig <[email protected]>, [email protected] CC: Jeff Sittler <[email protected]>, Eric Dalquist <[email protected]>, Andrew Wills <[email protected]> Assuming you can do all this with Jira (I think you can), I propose: 1. allowing issues to be assigned to any authenticated user (Users). Only users with assign permission can actually assign though (except for #2). 2. Add allowing Reporter to assign issue to themselves 3. If not already present, allow Assignee to Start Progress, Stop Progress 4. Modify the Jira workflow to add a workflow step 'Pull Request Submitted' after Open or In-Progress that Assignee (or Developers or Administrators) can do. I don't think this should put the issue into Resolved status though. I think it should still be considered Unresolved. This still means a developer or similar would need to assign issues to people who didn't report an issue. To consider: a) We can consider allowing any authenticated user to assign an issue to themselves since non-developers/admins could only move an issue to Pull Request Submitted and can't resolve or close an issue. I favor this. b) We can allow Assignee to edit an issue since there is change history. I'm inclined to leave at Assignee can add comments (or limit the fields they can modify) but not edit issues, though a Reporter can edit the issue they reported. c) We can create a new role Contributors as Jim suggested, though I think there is administrative hassle with that and authenticated users are limited enough the above proposal should not add much risk. Thoughts? James Wennmacher - Unicon 480.558.2420 On 06/23/2014 07:58 AM, Andrew Petro wrote: > uPortal developers, > > I'd like to consider widening the set of persons to whom UP JIRA > issues can be "assigned". > > Currently that field is constrained down to a role that we also use > for other purposes. For instance, "uPortal developers" can see > restricted security-related JIRA issues. I **am not** suggesting that > we widen the set of folks who can e.g. see those issues, nor am I here > suggesting radically widening the set of committers. > > Rather, I'm suggesting a technical, tactical tweak in the way JIRA is > configured for the UP project. > > The current situation is goofy in that folks like Josh Helmer can do > lovely work > > https://issues.jasig.org/browse/UP-4149 > > but cannot be the "assignee" of the issue on which they do the lovely > work. This impairs slightly giving credit where credit is due [1] > and, I think much more importantly, it makes it harder to use the > issue tracker to signal intentions. In a better workflow, Josh would > take assignment of this issue when he spiritually takes ownership of > completing it. > > Part of the power of Git and distributed version control is that it > decouples ability to take tasks and do valuable work from formal > "committership". Adjusting JIRA configuration would help in taking > advantage of that looser coupling. > > Kind regards, > > Andrew > > > > > [1]: Though I rather think that at this point if you're looking to > assign credit, a view like this > > https://github.com/Jasig/uPortal/graphs/contributors?from=2012-01-01&type=c > > > is more useful than anything JIRA can spit out. > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
