FYI. There is a lot of great information here. Please review the attached documents and review the queue ( https://issues.oasis-open.org/browse/DITA/).
Thanks and best regards,
--Scott
Scott Hudson
Content Strategist
Training & Documentation
Global Services & Support
Jeppesen | Digital Aviation | Boeing
Jeppesen email: scott.hudson@jeppesen.com
55 Inverness Drive East | Englewood, CO 80112 | www.jeppesen.com
From: Chet Ensign [mailto:chet.ensign@oasis-open.org]
Sent: Friday, May 20, 2016 8:40 AM
To: Scott Hudson
Subject: Re: OASIS Jira for DITA TC use?
Hi Scott,
Thanks for asking. Glad to help you look into this.
First, as noted, the DITA TC does have a JIRA project in place. See https://issues.oasis-open.org/browse/DITA/. Every member of the TC can access it and open issues, comment on issues, etc.
JIRA may not be the best issue tracking system in the world but honestly if I did not have JIRA, TC Admin would collapse. Whenever you enter one of the support tickets for ballots, public reviews, etc. it opens a JIRA ticket for me and that becomes both my work queue, my priority list and my history.
A few TCs are really using JIRA well to track work on their specifications and it helps them for the same reason. As one TC Chair put it "People can talk and talk and talk but until it is listed in JIRA, it isn't real." For example, have a look at TOSCA -> https://issues.oasis-open.org/browse/TOSCA/?selectedTab=com.atlassian.jira.jira-projects-plugin:issues-panel. Another is CAMP -> https://issues.oasis-open.org/browse/CAMP/. Also OData -> https://issues.oasis-open.org/browse/ODATA/
They define components for each different work product they are developing so that they can tie issues to their projected release. And they define versions so that they can track issues to stages - e.g. we're addressing this one in CSD01, this in CSD02 - other TCs have used those to track comments from public reviews as well. Obviously they assign issues to TC members. And then they use the JIRA link to put issues on their upcoming agendas, discuss them in meetings, and ultimately vote to resolve them - close them as completed or etc. You'll see in minutes votes to close JIRA x, y and z.
The way I've seen work best is that someone presents a topic to the TC for discussion. If the TC agrees that the issue warrants consideration, then it is entered into JIRA as New with the person raising it generally the Reporter. When the TC makes the decision to actually work on it, then it gets assigned to someone - usually the person who brought it forward, and Opened. Once it is Open, it is 'real.' Once they believe they have a solution to present they mark it as Resolved. Then finally when the TC approves the solution and the update is made to the working draft, the issue is closed.
I've attached a few documents on using JIRA for standards development that will give a bit more detail.
If you'd like to talk more about this or talk to one of the chairs about how they use it for their standards dev, let me know. I'll help out as much as I can. Obviously I'm a fan. Of JIRA and DITA both...
/chet
On Fri, May 20, 2016 at 8:53 AM, Scott Hudson <scott.hudson@jeppesen.com> wrote:
Hi Chet,
below you will find a discussion from our most recent DITA TC meeting. We would like to explore using Jira to manage requirements and issues for the next version of the DITA specification development. Can OASIS make Jira accessible for TC use? Is there a way I can begin testing this approach?
Here is the discussion from our 5/17 meeting:
5. New item: DITA TC in Agile?
https://lists.oasis-open.org/archives/dita/201604/msg00054.html (Doherty, 27 April 2016)
Stan gave overview; I've been noticing how prolific Agile has become, U.S. DOD projects, e.g., all require Agile scrum. So, should we be moving to this methodology? One approach is to organize a backlog of prioritized work items, e.g. stuff for errata, Lightweight DITA (LD), committee notes, etc., then leaders break it down into digestible chunks; 2 working teams, each self-organizaing; they're there to handle whatever is in the backlog. The teams work in recurring intervals (sprints) and people meet regularly, look at schedules, and commit to small pieces. You don't deliver everything you work on, but it's done in incremental, highly visible, self-organizing groups. My suggestion was in response to Kris's cry for help in organizing and managing our work.
- Scott; would we have the spec be considered an epic? (in Agile terminology)
- Stan; it might be; depending on situation, we might have many epics or just a few. how parallel or serial, it gets organized, helps to drive its definition. 'a scrum is what you make of it'
- Scott; our SCs are kind of scrum teams,
- Stan; yeah
- Kris; I'd be interested in learning where Agile has been successful in volunteer situations, especially in standards work.
- Robert; we use Agile in my work team and it works well, but I've been skeptical on how it would work in volunteer situations; so I wonder how that would play out. Another thing that makes standards work peculiar is that we all have related but not idential goals; we all have different priorities for what's in the backlog.
- Stan; good point; team in gen'l can provide feedback on stuff, but you need one or more persons in the role of project owner; they set the priorities, it's not up for a vote. that's different from our operating mode.
- Kris; I'm always interested in something that would let the TC work more efficiently and guarantee its health and well being.
- Robert; I like what we did in 1.3 with our backlog (Trello), with folks coming with proposal; TC took on role of 'customer'.
- Kris; I don't know if we could have 1 or 2 people be that voice; we're really bound to operate by Robert's rules of order. we've worked towards consensus. reality is there is no one customer; we each have different constituencies.
- Scott; I agree; to have one single owner would bias what gets worked on.
- Stan; I didn't look at any other standards orgs to see if they do this; maybe ACM, or ISO. maybe Chet at OASIS would know. it's surrounding us; but it's not visible in other committees, if they're using it.
- Kris; will anyone reach out to Chet or other folks to do some research?.
- Eliot; I won't volunteer, but apropos of this, I was at a different standards meeting (W3C) last week, they were definitely not using Agile.
- Amber; One of my clients, the Sustainability Accounting Board, is very successfully using Agile. They are a small org and not dependent on volunteer membership, but working on a standard. It keeps evolutions of standards moving at regular pace.
- Kris; it would be very interesting to find out if there are particular aspects of their standard working for them in their use of Agile.
- Don; did a search, came up with XDI standard editors.
- Kris; do we have volunteers?
- Stan, I'll do it, but only with someone else?
- Keith; I'll volunteer; and just btw, W3C has been criticized for not being Agile enough; it takes too long to issue standards, and it has a difficult conflict resolution method.
- Eliot; I'd definitely not recommend them as a model.
- Kris; [review of our method] I don't have a high level of experience with Agile; I don't really know what we could do to incorporate some, but not all, of it.
- Robert; we've been using Agile for 10 years; I've heard many people say 'there's only one right way to do Agile', but I've seen a lot of different ways to do it, so it's not one right thing, but a collection of methodologies.
- Stan; I agree
- Kris; what aspect might be good for us? we could have more formal backlogs, and incorporate time in each meeting for looking at them.
- Eliot; our use of Trello was pretty close to Agile.
- Kris; and all our work is conducted in a transparent fashion, which is a piece of Agile.
- Chris; because we meet weekly, we have a built-in scrum. It would be helpful if OASIS provided us with a JIRA.
- Kris; they have one; we can use it. Can someone look into our using JIRA at OASIS?
- Stan; be glad to do that as part of Keith and my work.
- Kris; I looked at Jira at one point, to report changes, but I thought it would be more time-consuming than using a spreadsheet.
- Stan; the nice thing about Jira is that it's public and real-time.
- Kris; it would be great to check it out; when I checked, the way that OASIS had set it up made it unusable. it would be great to have a better bug-tracking system
- Scott; I'd be happy to help out with Jira too; we use that here.
- Kris; Scott, can you contact Chet and look at it? Stan and Keith can focus more broadly.
ActionItem: Stan, Keith, and Scott will investigate Agile development methodologies as they've been used in developing standards, with an eye to making recommendations about which parts might be applicable to the TC's work. In particular, Scott will contact Chet about the status of OASIS's Jira tools; Stan and Keith will focus on broad outlines of Agile methods.
Thanks and best regards,
--Scott
Scott Hudson
Content StrategistTraining & Documentation
Global Services & Support
Jeppesen | Digital Aviation | Boeing
extension: 556228 | phone: 303.328.6228 | mobile: 303.350.7934Jeppesen email: scott.hudson@jeppesen.com
55 Inverness Drive East | Englewood, CO 80112 | www.jeppesen.com
--
/chet
----------------
Chet Ensign
Director of Standards Development and TC Administration
OASIS: Advancing open standards for the information society
http://www.oasis-open.org
Primary: +1 973-996-2298
Mobile: +1 201-341-1393