I am not really sure if assigning JIRA issues to the project lead is a good policy. I creates the impression to end users that there is actually somebody assigned to the issue and maybe even working on it. IMHO it would be better to leave them to unassigned, because that’s what they are really are.
I discussed that with Robin a while ago. He was in favor of the current policy. If I remeber his argument was that the project lead has an overview of the current open issues. But that could also be achieved with a simply JIRA query, and remeber those can be saved for later re-use.
I also think that new developers which want to contribute would be more attracted to “unassigned” issues instead of a issue that belongs to someone. That would also match my workflow to assign myself only to issues I intend to fix in the near feature.
O, this is a psychology I usually leave it auto assigning to a project lead, so someone should be aware about the new tickets. I’m not sure every developer here has some sort of JIRA monitoring. I do (though i’m not a dev). I get emails about new tickets per day and also there is a widget on JIRA dashboard to watch new tickets. Sometimes i just want to be sure an issue will get an attention. Speaking about new developers, maybe some are put off by already assigned developer, maybe others check the date of the ticket and if it is old enough and no work was done, well… Sure, we can change our policy to make it Unassigned for every new ticket, but all current active developers should agree (Guus, Walter and his team, Robin, you and some other new guys). Or we can encourage new comers to take on already assigned tickets, when they ask in the forums where to start.
Thanks for bringing this up. I do see benefit in this. Having issues that are not being addressed unassigned will provide some clarity. I’m not strongly in favor or opposed to this. I’ll conform to the majority vote on the matter.
Besides sending yourself an e-mail with new issues (I don’t like spamming myself ), there is even an RSS stream for new issues. For example select ‘Smack’ -> Filters -> Added Recently -> Views -> RSS (Issues).
One email doesn’t hurt (i still get dozens on ticket updates and comments), but having more options is good. Though i haven’t figured a way to get an rss feed for all the projects in one. Anyway, i guess we should wait for Walter and Robin to comment on that. And maybe Daryl can tell if we can have an option in Jira to default to unassigned option for new tickets. Because i will forget to change it every time
I like the “unassigned” option. I had a time figuring out which tickets where actually being worked on and which weren’t, and hesitated to “steal” the assignee from ones I wanted to work on… I think an “unassigned” is very clear.
Also perhaps, after some period of time that a ticket has no activity, the Assignee gets set back to “Unassigned” ? This would fix the situation where a dev. stops work and doesn’t update the ticket or notify anyone else to take over. I think there are many tickets in that situation currently where work began but then stopped and no one knows the current status of the ticket anymore…
I don’t think that JIRA provides an option to automatically reassign issues to “Unassigned”. And IMHO there is no need for it, if you want to fix an issue that somebody else is assigned to you can always ping him about the current status.
bummer if it doesn’t have that option… i think to an onlooker, seeing a few “Unassigned” tickets says “we need your help!”, while assigned tickets may look as if we have most bases covered… …
sending a ping is ok… although if it were me i wouldn’t start work until i either heard back or a good amount of time went by (say a week or whatever)… out of fear of duplicating work in progress… just my thoughts…
I assume that they are not being worked on unless the assignee has marked it as In Progress. This is what that state is for. Once a developer starts working on a task, then they should mark it as such which indicates that they are actively working on it.
That is what I told Flow when it came to tasks that are assigned to me. Go ahead and reassign them to yourself unless they have a state of In Progress.
works for me. although i don’t think it’s immediately obvious… perhaps we can have a banner or something added to Jira that explains the “etiquette” for assignments?
Is there really a need for a banner in JIRA? We could post the rules / etiquettes here, or even just understand the common practice. In JIRA issues are typically automagically assigned to the owner of a project; however, unless work is started it is still a viable option to poke in on it, or even just post a comment on the issue as to the status as you may inclined to work on said issue as you may have a work around/solution!
Personally, I am of the mindset that as it is open source, it is fair game to work on anything, or contribute in any way possible. If it is not in progress please feel free to take a stab at it. You can do no harm in doing so, only stimulate the minds of others
Well, we are using plain Jira that is somewhat the gold standard for issue tracking. We are using that one internaly in my team and that’s fine with me. If someone wants it to move to unassigned it’s a deviation of Atlassian Standard. Not necessarily something I would go for. I would only change it, if it help us progress.
It is maybe a good idea to assign tickets to the project lead if you use JIRA within a company where it’s easy to communicate which each other and happens on a daily basis and where the JIRA instance is private.
But if you use it in an open source project then assigned tickets to the project lead simply creates the impression that there is work beeing done, when in fact nobody is working on the issue, regardless of the ‘in progress’ state.
So I ask: Is anybody against changing the policiy to assign new tickets to unassigned and dropping all tickets he/she doesn’t intent to fix in the near future?
I would prefer to keep the default assignee as the project lead. I know I like to get notifiied of any new issues and changes in existing ones. I can also evaluate the issue when it is newly entered and edit it accordingly.
That being said, I agree with the point that it gives a false impression of tasks being worked on. I am proposing that the leads here do some housekeeping when it comes to Jira, and simply evaluate and update issues as they come in. This would mean setting the assignee status as well as checking whether the issue is a duplicate, has enough info, evaluating it’s severity level and potentially setting the proposed release. I have already “unassigned” the majority of issues for Smack 3.3, and will do the rest of them in the next couple of days.
I will write up some guidelines, if everyone would like, that would reflect this process, as well as add some etiquette for working on tasks. I am thinking of some things along the lines of.
unassigned tasks are open for anyone to wrk on.
Assigned but not In Progress, contact the assignee to see if it can be reassigned, sharing of ideas (this can be done directly in the issue as well) or just requesting information.
Would this seem like a reasonable solution that would keep everyone happy?
I am sold on that idea and will accept the “review to unassign” role. Project leads may look into component and classifications. New developers can get a better view of “open” areas. I’ll do an exercise on Spark (as soon as I can log on again).
…