So, here is the document for review (and the inevitable barrage of comments ). I hope the other leads can take a few minutes in the near future to have a look especially have a look to see if they agree with the guidelines I have outlined.
I based this on my own experience with Jira over the last few years and tried to adapt it to this environment.
I still see no reason to assign issues per default to the project lead. RSS feeds and custom queries are a better approach to get notified about new issues and to track them. Thatâs how I keep track of new Smack and Openfire issues and make the initial issue review. @rcollier (and others) wouldnât that also be a solution for you? Or how about JIRAâs e-mail notifications?
I also propose that assigned issues without any source code commits in, say, 3 months and not in âin-progressâ status should get unassigned. Ideally automatically or if necessary manually.
1 - I think that horse is dead, stop beating it.
2 - Agreed. I will update the document.
3 - Lets move comments and discussion to the actual document so it can be kept in context.
I would like to lock this thread to push further comments and discussion to the document. Any objections?
Yes, you can lock it i think
Where is the horse dead? I see people in favor of creating new tickets as unassinged, Guus also likes the idea but stays neutral otherwise and the arguments for keeping the current practice are very weak.
Walterâs âitâs a Industry Standardâ doesnât explains why we should do so. Sorry Walter, but thatsâ not an argument, other FOSS projects use JIRA different. And I think the disadvantages of the current practice justify that we stop doing so. Thatâs why I raised the topic in the first place. I havnât heard one good argument why tickets should get assigned to the project lead. But since there are none, pardon me if I raise my voice about something that I think isnât right.
And I made it clear that there are other ways to get informed about new issues. Or is there something else that forces new tickets to be assigned to the project lead?
Since you are asking for one good reason, Iâlltry to come up with one. When we moved Spark to 2.6.3 I had 2 active developers and 5 nightly testers that were fixing, enhancing, testing, reporting. To keep this focussed on a plan (e.g. getting controll on file transfer), it was mandatory to provide guidance to teh developers by reviewing, judging and assigning as a project lead. If you do not do this in such a scenario (active project team, multiple people), we have a more Kanban style of development, where the team pulls what they thing is suitable.
Both approaches are valid and have prerequisites. In the current state of Spark, a ânew is unassignedâ is ok. For Openfire, I would think differently, since Guus may want to exercise some control on the ânext feature/fixâ because we just had a major release that may need âHot fixâ releases. In his position, I would be more than interested to have nex assigned to the project lead that drove the major release.
The Unassigned state does hide the status of an issue a bit. You just donât know, if the issue is confirmed or virgin state. Gaining leadership in a project with unassigned policy would require a complete review of all issues for a person who wants to take overâŚ
Honestly, and I donât want to be offensive or so, but I canât comprehend any of your points.
To keep this focussed on a plan (e.g. getting controll on file transfer), it was mandatory to provide guidance to teh developers by reviewing, judging and assigning as a project lead.
What does providing guidance and reviewing have to do with assigning new issues to the project lead? I track every openfire and smack issue. And review every single commit of the two projects without having every new issue assigned to me.
Guus may want to exercise some control on the ânext feature/fixâ because we just had a major release that may need âHot fixâ releases.
And a project lead canât do that if he is not assigned to new issues? What about RSS and e-mail notifications about new issues? These come without the downside of making the impression that there is activily worked on the issues. I guess that is my whole point.
Gaining leadership in a project with unassigned policy would require a complete review of all issues for a person who wants to take overâŚ
And this would change with the current policy? If somebody takes over a project he would ideally familiarize with every issue, maybe even some important closed ones. I dontâ see how a unassigned policy would change that.