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


Help: OASIS Mailing Lists Help | MarkMail Help

chairs message

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

Subject: Better Standardization of Jira Life-cycle

Was : Subject: Re: [chairs] Chairs: Requesting your feedback on comment resolution logs

Patrick Durusau wrote:
>> I would second the comment on the inability to configure Jira being a real issue.
>> I understand and would argue for standardization, just not poor standardization.
>> Personally I don't think Jira is really appropriate to document work in any event. Driven 
>> by a different mind set than most document approaches.

So what would a better standardization of Jira look like?

The current lifecycle is 

New - Open - Resolved - Applied - Closed.
Deferred is an optional dead-end.

In recent work on three TCs, we found that life-cycle to short.
We found we needed an originator, for reporting purposes.

More detailed comments:

We would have liked two orignators. We used environment instead.

We established a rule that the person who commented was put in as the  "Environment". The reporter was not useful, as it indicated data entry rather than the origin of the report. Many commenters could be grouped. For example, in Energy Interoperation, members of the wholesale electric quadrant would meet as a committee, and submit to us a large spreadsheet of their comments. These spreadsheets included the original commenter. It would have been nice to be able to prepare a report by the Commenter/Orginator, as well as by the Commenter Group / Originator Group (Trade association). As these commenters did not have Jira IDs, they did not have a pick list of "Reporters" that would work.

We entered the source of the comments in the environment, and reported on that . By sub-contracting all comment entry to my daughter, I was able to achieve consistency in this practice. TC members also submitted their own issues. We usually had to go back and add the "Environment" on these, because the UI did not make it clear that we had adopted a convention.

We prepared final reports by Comment Originator (person), and Commenter Group (Industry segment or trade association) and mailed out the PDF of same. 

Life Cycle:

Here again we abused the standard language in Jira. Leaving out the Deferred issues, we did the following:

New - Entered but not being worked.

Open - Being worked. Usually we had one person who cared the most (PWCM). That person was not necessarily the person who was working the problem. What we *tried* to do was assign a task to someone to work, and then assign it back to the one who cared most for "approval". For example, a comment might suggest a change in a schema. The PWCM might add a comment on what the solution should look like, and assign it to the schema editor. The schema editor would make a proposed change, and assign it back to the PWCM for review. TC members could always chime in with their own comments. In the simple case, this worked fine. In the case where the Issue was assigned back and forth between multiple people, this did not work as well. Ideally, the PWCM would accept the work, indicating same by moving it to resolved. In practice, we had several times where the identified PWCM was unhappy because someone else moved it to Resolved.

It would have been good to have a [Proposed] state, for after the hand-offs are done, to put it in the hands of the PWCM. From proposed, the PWCM can move it to Resolved, or can push it back for further work. At some point, the TC may have to vote on the proposal if the TC and the PWCM can't agree.

The Resolved state was effectively directions to the Editor[s]. Make these changes. Edit to approximate English. Change the Schema and let the changes ripple through the model/structure. The Editor would move it to the next stage of Applied. The applied should be looked at by the PWCM, but we had no real mechanism for this. The editor may think he has faithfully applied the proposal, and then edited for clear language, spelling, etc, and then applied affects of the change to the 4 places in the document that refer to this change...and updated an illustration, ... The TC and/or the PWCM may think otherwise. 

We would then vote, as a TC, on moving Applied to Closed. An awkward part of the current Jira lifecycle is that you cannot directly re=open applied, but must Close, then Re-open. 

Sometimes the [proposed] or the Applied would get contentious, or threaten to metastasize. In those cases we would vote to defer before releasing a PR. It would have been useful to have a special comment for "Why are you deferring". In any case, moving from applied to deferred requires moving to closed, reopening, deferring.

As we accompanied Closing with TC Votes, it might be nice to have a "Closing note", to link to minutes or the vote, or something similar.

Other Issues:

With Comments coming in, and being re-entered, there was some confusion sometimes. We were working with regulated entities, and received Comments as signed PDFs from regulatory lawyers (i.e., no cut and paste). We received one submission of comments and use cases as a couple hundred MB PDF from a public utility commission. Of course, even when we got text, there might be 4 comments in a single letter. It would be nice to have a field for a link to the origin of the comment, whether the email or the PDF....


"Computers are useless. They can only give you answers." -- Pablo Picasso  

Toby Considine
Chair, OASIS oBIX Technical Committee
U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee 
Facilities Technology Office
University of North Carolina
Chapel Hill, NC
Email: Toby.Considine@ unc.edu
Phone: (919)962-9073 
blog: www.NewDaedalus.com

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