On Thu, 9 Feb 2012 12:58:40 ext [email protected] wrote: > Hi, > > ... > > > There is some discussion over if we should burden maintainers with Release > Management work. > > There is a suggestion of a new workflow "Nokia Engineer" - no privileges in > Gerrit only in Jira.
That role might be useful, but please don't call it "Nokia Engineer". Even if we don't expect anyone to ever volunteer to do task management roles, Qt as an open project could grow to other companies. Calling it "Task Manager" or "Issue Secretary" (or something along those lines that's not a joke ;) ) will mitigate the risk of having to change the name again later. > > ... > > > Default Assignee > > There is call for discussion around default assignee - is it the module > maintainer? Which tasks are up for grabs if everything new goes to the > maintainer? The theory I was taught was that you don't use your 'tasks assigned to me' list as your list of your in-progress bugs. You use your 'tasks assigned to me and listed as in-progress' for that list. So assignment merely means "If someone's going to look at this bug, it'll probably be this guy first". If you're working on a bug and don't want people to take it away, you mark it as in-progress. Then the tasks which are up for grabs are the ones assigned to the maintainer (or anyone, actually) which are not marked as 'in-progress'. On the 'unassigned' suggestion, I think that could only work if there's an easy way to find the correct maintainer for a component. Currently the table in qt-project contains some data, which is nice, but it's just not convenient enough or obvious enough to work with JIRA. Default assignee has basically been the way people find maintainers for bug reporting (at least), if you take that away then something else is needed. -- Alan Alpert Senior Engineer Nokia, Qt Development Frameworks _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
