I thought that the below e-mail might make some of these discussions about the new processes more concrete. It provides a step-by-step look at how the new processes will affect the work of the DITA Adoption Committee in publishing a white paper.
Background: The DITA Adoption Committee has produced a series of nine white papers over the past year, each explaining different aspects of new DITA 1.2 functionality. You can view a list of these white papers at http://dita.xml.org/wiki/oasis-dita-adoption-committee . The feedback from the DITA user community has been extremely favorable; people (users, vendors, developers, etc.) all have commented that the white papers have helped immensely by providing explanative, non-normative information about aspects of the new standard.
Best regards,
Kris
Co-chair, OASIS DITA Technical Committee
Charter member, OASIS DITA Adoption Committee
Kristen James Eberlein l DITA Architect and Technical Specialist l SDL Structured Content Technologies Division l (t) + 1 (919) 682-2290 l keberlein@sdl.com
Please consider the environment before printing this e-mail
From: Kristen Eberlein
Sent: Thursday, November 11, 2010 5:55 PM
To: Scott McGrath
Cc: Gershon Joseph (gerjosep); Joann Hackos
Subject: Adoption TC concerns
Hi, Scott.
Thanks for the conversation today and for being willing to arrange for a member of the Process Committee to attend a TC meeting and explain the rationale behind the new process.
Again, the Adoption Committee’s primary concern is that the new process will take too much time.
Here is a summary of how the new process will affect the DITA Adoption Committee:
1. We discuss, draft, revise, and generate consensus on a work product. This usually takes several TC meetings or longer, depending on the complexity or nature of the subject. This is the process that the TC has followed as it has produced 9 feature articles during the past 15 months.
2. We register the work product at http://marypmcrae.com/wptemplate-request .
3. We approve the work product as a committee note draft. This requires a full majority vote of the TC.
4. We approve to submit a committee note draft for public review; this also requires a full majority vote of the TC. If approved by the TC, this draft becomes a committee note public review draft; it must be accompanied by a “recommendation from the TC of external stakeholders who should be notified of the review.”
5. We request that the committee note draft be uploaded to OASIS: http://marypmcrae.com/cnd-creation-request .
6. We request a 30-day public review from Mary McRae: http://marypmcrae.com/30-day-cndpr-request .
7. Mary McRae announces the public review to the OASIS membership list and “optionally on other public mail lists.”
8. Non-TC Members post comments to the TC's public-comment list. We must acknowledge the receipt of each comment and track the comments received; at the end of the review period, we need to post a list of how each comment has been handled to our e-mail list.
9. If we make ANY changes to the committee note draft as a result of the public review, we need to start the whole process over. The review period this time is only 15 days.
10. After a public review that does not generates any comments that result in the changes to the committee note draft, we can approve the work product as a committee note. This requires a special majority vote of the TC. If the 15-day review generated any comments, this vote cannot be held before seven days have passed since the close of the public review. To conduct the special majority vote, we need to notify Mary McRae that the TC is ready to vote and provide her with the location of the editable versions of the files. She sets up and conducts the ballot.
Step #1 is our current process; all the other steps will add time and additional administrative work for the TC. It is going to add a minimum of 30 days plus any turnaround time from the TC administrator on each of the requests; realistically, I think that we’ll also need one or two or more 15-day reviews. All of this is in addition to the work that we currently do to discuss, draft, revise, and generate consensus on a work product; our TC members are adamant that we do not want to issue a committee note draft for public review before it has gone through our current process.
A secondary concern is whether the requirements for PDF and XHTML formatting are formally specified and stable. It takes serious volunteer effort to build XSL transformations and plug-ins to generate output that meets OASIS formatting requirements. If those requirements are not available and stable, we waste valuable time that people donate toward the effort.
While I personally welcome having a formal process and even appreciate the official forms used to trigger the different phases of the process, I am concerned that it will hamper our ability to produce the sort of valuable work that we have done so far.
Best regards,
Kris
Kristen James Eberlein l DITA Architect and Technical Specialist l SDL Structured Content Technologies Division l (t) + 1 (919) 682-2290 l keberlein@sdl.com
Please consider the environment before printing this e-mail