Re: [chairs] New processes -- How they affect adoption work

[robert_weir@us.ibm.com]

Hi Kristen,

Here are a few tricks that I use to save some time:

1) Combine some approval steps into a single TC ballot.  For example, I 
will ask the TC to approve a draft and contingent on its approval, to also 
request a public review, all at the same time.  For example, "Shall the TC 
approve XXX as Committee Specification Draft XX and if approved shall the 
TC request a 30-day public review with notification to external 
stakeholders, etc..."  Using a contingent motion like that can shave a 
week off. 

2) If you haven't already have your TC approve a "standing rule" that 
allows members to request an electronic ballot via the mailing list. 
Otherwise you need to wait until a TC meeting to initiate a ballot.  See 
TC Process 2.13 "TC Voting".  This can shave up to a week off. 

3)But depending on your meeting schedule, meeting attendance levels and 
degree of consensus on your TC, you might be better off avoiding 
electronic ballots and doing CND votes in a meeting.  In other words, if 
you know you'll get the full majority vote in a meeting, and you meet 
every week, then that is almost always faster than having a minimum 7-day 
electronic ballot.  But if you meet less frequently, etc., then an 
electronic ballot may be faster, since you can initiate it any day of the 
week, provided you have the standing rule.

4) Once you have an approved CND or CSD, changes are expensive, since you 
require at least another 15-day review.  And don't forget that there is 
often a delay of a week between requesting a public review and initiating 
the public review.  So if it is a relatively short white paper and not 
controversial, you're best bet is to have careful review in the TC, and 
make sure it is perfect before sending it out for public review.  In other 
words, don't treat public review as a QA cycle where you expect to find 
errors, but as "I dare you to find anything wrong".  If you can reliably 
get through public reviews without finding anything that needs to be 
changed, then you've shaved a month off the cycle. 


Regards,

-Rob



"Kristen Eberlein" <keberlein@sdl.com> wrote on 12/16/2010 11:30:13 AM:

> 
> [chairs] New processes -- How they affect adoption work
> 
> 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
>  [image removed] 
> 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
>  [image removed] 
> Please consider the environment before printing this e-mail
>