On Mon, Jan 11, 2016 at 05:32PM, Yakov Zhdanov wrote: > Cos, > > > In JIRA, open tickets are automatically got moved to the next version, > once > > the current one is getting "released" in JIRA, so the reassignment is done > > without any human intervention normally. There's no need for any process > > around it, IIRC. > > Agree, but this way you can miss some important tickets or not so important > tickets, but filed per devlist or userlist request and promised to be > fixed. If anyone knows how to effectively manage this in Jira, please let > us know. I think we should definitely try working "fixVersion" field as > described.
I believe the most effective way to do so is once the list of features in the release is discussed and agreed in the community, the RM will keep an eye on the particular tickets and nudge folks if they aren't on time for the release. there's nothing wrong with fixVersion field per se, I just was making a note about proposed bulk JIRA updates. > > A couple notes on the page: > > - the macro to JIRA doesn't work, actually. Wiki users are different from > > JIRA ones. So it'd make sense to make an anonymous filter > > Do you mean "lead" column? I think, we can just remove it. > > > - what's the "Lead" role? > > I meant that here we can put a person who is able to help with any question > that may come out. However, all questions may be asked on dev list. So, > this column seems redundant. What I've seen to work in a number of other projects is a list of maintainers. Say, you have people who are most interested in a particular component and have best expertise built in it. Having a version controlled list in the source tree would be a good way to quickly figure out who's the right person to reach out to with any issues in the area. Lead just sounds too enterprisee and managerial. Cos
signature.asc
Description: Digital signature
