OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: JIRA workflows for UBL 2.2 development

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:


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


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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]