Agreed Sharan, it was just a try and it's not worth it for us. I just closed
it, thanks for checking!
Jacques
Le 17/08/2016 à 09:50, Sharan Foga a écrit :
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
