Hi Jacques I took a look at the Service Desk functionality you enabled in Jira and I'm not sure that it fits the project flow. It seems to be focussed at customer service desk resolution within agreed timeframes. Although you could argue that our users are also our customers, no one is under any obligation to fix an issue within a fixed time frame â everyone gives their time voluntarily.
I understand that the service desk is used by the infra team as they have specific Service Level Agreements they need to meet and I think imposing SLAs onto a voluntary team of contributors could cause a bit of unnecessary pressure and stress. The main thing we as a project need to address, is to sort out and make sense of our Jira backlog (or 'jira mess') so that it becomes a useful tool rather than where things stay in limbo. I'd suggest rather than trying to fix everything at once, let's try to find the things that could improve the throughput or reduction of issues and focus on implementing them as a first step. Thanks Sharan On 2016-07-30 13:53 (+0200), Jacques Le Roux <jacques.le.r...@les7arts.com> wrote: > Hi Sharan, All, > > I just did something which might help us, at least on your point 4. I have > enabled the Jira Service Desk option so we have now a SLA feature (Service > Level Agreement) > I used the default, can be changed at > https://issues.apache.org/jira/servicedesk/agent/OFBIZ/sla (need more work > and especially agreement, to be > discussed I guess) > It shows at the top right of each issue > There is also queues at > https://issues.apache.org/jira/servicedesk/agent/OFBIZ/queues > > I don't think we want to change that > https://issues.apache.org/jira/servicedesk/agent/OFBIZ/people > I don't think we need > https://issues.apache.org/jira/servicedesk/agent/OFBIZ/customer I guess we > can customize to have something like > https://issues.apache.org/jira/servicedesk/customer/portal/1, related with > line above, useful for us? I guess not. > > There are reports at > https://issues.apache.org/jira/servicedesk/agent/OFBIZ/reports > > I think this could be usefully used to organise and prioritise our issues, > beginning by our own. > > What do you think? > > Jacques > > > Le 15/07/2016 12:03, Jacques Le Roux a crit : > > Hi Sharan, inline... > > > > Le 15/07/2016 11:53, Sharan Foga a crit : > > > >> Hi All > >> > >> We have an amazing number of Jiras open and because we have so many it's > >> getting very confusing as to what are the priorities and things are > >> getting clogged up. > >> > >> I've got a few initial ideas and suggestions that could maybe help improve > >> the workflow > >> > >> 1) Highlight Parked / On Hold Jiras > >> We have quite a few Jira issues that are 'parked' or 'on hold' \u2013 so > >> it would be good if these were clearly identified so that if people come > >> across them they know that they are not being worked on (and the reason). > >> > >> We could look at adding a new status, a flag or a label that could hold > >> this information. > > > > For those we could maybe close them with the "Later" status? So nothing to > > do (but closing them), we did that already, not sure it completely fits > > for all cases though... > > > >> 2) QA Review for New Jiras > >> I think it would also be good to look at introducing some type of review > >> stage for newly created issues. This also could give us a bit of QA to > >> make sure that there is enough information needed for the task to be > >> worked on. It could also be then allocated to a workstream. > > > > Are we not already (slowly) doing it? Do we really need a policy or (a) > > tool/s for that? I fear we don't miss policies but rather free time from > > contributors... > > > >> 3) Define Workstreams > >> We have a good idea of the areas that we want to focus so it should be > >> relatively easy to setup some workstreams. I'd like to explore the idea > >> of > >> workstreams a bit more because it could be something that could be an > >> entire sprint, an issue category or it could be the equivalent of a > >> planned > >> future release. > >> > >> I know Jira allow us to define a Roadmap and versions and that we already > >> have something setup that helps us with our release management > >> (I.e.automatically incorporates all the Jiras applied to a version) that > >> we don't want to break \u2013 so this might need more investigation > >> > >> 4) Review of Old Jiras > >> One of things that we've had hanging around for ages is a lot of old > >> Jiras. At the moment I think Jacques takes on a few at a time, so it could > >> be > >> good to get some other volunteers and start looking at these and either > >> closing them, parking them or allocating them to a workstream. > > > > This relates to point 1 > > > >> These are a few of the ideas I had in mind \u2013 the main objective is to > >> make Jira into a useful tool for help us with our workflow. > >> > >> Please feel free to let me have your feedback and comments, and if anyone > >> else has other ideas and suggestion to share, then please do. > > > > Thanks for this initiative Sharan! > > > > Jacques > > > >> Thanks > >> Sharan > >> > >> > > > > > >
