JIRA workflows for UBL 2.2 development

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

Fellow UBL TC members,

Planning ahead for our tasks for UBL 2.2, I'm looking at the JIRA 
workflows and how we will manage our many tickets.  The list of 
tickets applicable to a new UBL distribution can be summarized with 
this short URI:

https://issues.oasis-open.org/issues/?filter=12972

If that doesn't work for you, please try this lengthy URI:

https://issues.oasis-open.org/issues/?jql=project%20%3D%20UBL%20AND%20resolution%20in%20(Unresolved%2C%20Fixed%2C%20%22Won%27t%20Fix%22%2C%20Duplicate%2C%20Incomplete%2C%20%22Cannot%20Reproduce%22%2C%20Applied%2C%20%22No%20Action%22%2C%20Invalid%2C%20Later)%20AND%20status%20in%20(Open%2C%20Resolved%2C%20Applied)%20ORDER%20BY%20priority%20DESC%2C%20key%20DESC

In both cases, if you get a split "detail" view showing the list on 
the left and a ticket on the right, then find the views icon to the 
right and select the "list" view for a better summary of the project.

Right now the status of all UBL 2.2 tickets is OPEN and I have 
DEFERRED tickets that are not related to UBL 2.2.  One exception is 
the NDR ticket (UBL-6) that will soon be marked "CLOSED"; as it is in 
a public review I have marked it as "APPLIED" and I will change it to 
"CLOSED" when the NDR documents are published.

What follows is the process I propose to manage the status of tickets 
moving forward.

All tickets that are "OPEN" are tickets that have been put forward to 
the TC but the TC hasn't yet resolved what to do with them.  Two 
things can happen: (1) When the TC agrees to add a ticket to the 
master for a public review, the status changes to "RESOLVED" and the 
resolution is changed to "FIXED"; (2) When the TC agrees not to add a 
ticket to UBL 2.2, the status changes to "RESOLVED" and the 
resolution is changed to an indication of the reason for the 
disposition, then the status changes immediately to "APPLIED" because 
there is no further action for the ticket towards UBL 2.2.

That gives us the "to do" list for incorporation into the next public 
review:  all tickets with the status of "RESOLVED".  That tells 
everyone that the masters now need to be changed before the next 
public review to incorporate the ticket, but that hasn't happened yet.

If problems are found with the issue during that incorporation, the 
status changes from RESOLVED back to OPEN.

When an issue has been incorporated into the masters for a public 
review distribution, I'll change the status from RESOLVED to 
APPLIED.  So we know when preparing a public review all of the 
tickets with APPLIED will be in the distribution, and those that are 
not APPLIED are not in the distribution.

If during the public review we find a problem, I'll change the status 
from APPLIED to RESOLVED to OPEN for the issue to be reexamined.

By the end of the last public review all tickets should be at APPLIED 
status, and the resolution column tells us our disposition of each one.

When UBL 2.2 is released I'll change the status from APPLIED to CLOSED.

I have not paid particular attention to the "Priority" field for the 
tickets, so please do not attribute any importance to it.  If you 
think we need to exploit this value, please speak up.

Please let me know if this makes sense to you.  I haven't worked with 
JIRA workflows before.  I am hoping we can use the ticket status to 
better understand the progress of UBL 2.2 development.  Any 
suggestions to improve on this are most welcome.

. . . . . . . Ken

--
Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
Streaming hands-on XSLT/XPath 2 training @US$45: http://goo.gl/Dd9qBK |
Crane Softwrights Ltd. _ _ _ _ _ _ http://www.CraneSoftwrights.com/o/ |
G Ken Holman _ _ _ _ _ _ _ _ _ _ mailto:gkholman@CraneSoftwrights.com |
Google+ blog _ _ _ _ _ http://plus.google.com/+GKenHolman-Crane/posts |
Legal business disclaimers: _ _ http://www.CraneSoftwrights.com/legal |


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus