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


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

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

Subject: Re: [dita] DITA 1.3 Proposal Process

Hi JoAnn,

I agree that we need something in the process to help get the SCs involved,
but I'm not quite sure how to incorporate this. There are a few items that
make me wary:
1) The proposer of a new item often does not know what is relevant to
2) It's better for all concerned if the SC is involved early rather than
later (we'll get better proposals, fewer surprises, and fewer rewrites)
3) If subcommittees require a formal review only after the proposal is
ready, it may take an excessive amount of time (especially for groups that
only meet monthly).

What if we require that the TC chair notify all SC chairs when any proposal
passes step 1 or 2? After step 1, the SC chairs can determine on their own
if they are impacted. If the SC is interested, they should add a member to
the group creating the proposal, to ensure they are kept up to date. That
member is responsible for keeping the SC informed of progress. Notification
after step 2 is a backup check; the chair (or group) can again verify
whether they are impacted, and add a member to the group responsible for
writing up the final version.

I'd also suggest adding a time constraint to the process - for example, all
proposals written up for step 2 or 3 must be submitted to the TC at least
one TC meeting before the one where the vote takes place. That should help
submitters and reviewers as well as the SCs. The first TC meeting and
minutes give everybody notice of what's up for discussion / vote the next
week. Glaring holes are more likely to be noticed ahead of time, rather
than using up TC time. SCs also have at least a week to discuss the item;
remember that SCs who were interested should already have a member helping
with the proposal, so they should be aware of the status.

From my point of view, the keys here are:
1) Just as with ordinary TC members, the SC is responsible for determining
interest and getting involved.
2) Notifications to the SC ensure that they become involved in relevant
proposals as early as possible; I'd hope that interested SCs get involved
after step 1
3) Early involvement of the SC ensures that the group is not surprised and
that the SC view is represented in the proposal


Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit

             Joann Hackos                                                  
             tech-serv.com>                                             To 
                                       DITA TC <dita@lists.oasis-open.org> 
             08/07/2010 04:34                                           cc 
                                       [dita] DITA 1.3 Proposal Process    

Hi --
One item I would strongly want to see added to the process. That a
subcommittee whose work and members may be affected by the proposal is
specifically notified and given time for a formal review.

This should have happened with the Glossary proposal in DITA 1.2. I missed
it entirely and only later did we learn about the extent to which it was in
competition with the hard work done by the Translation Subcommittee.

Special care should be taken to alert specialists about proposal that will
affect them. We will have a Technical Communication Subcommittee, as soon
as Gershon and I can find bandwidth.

The decisions about the Task Model affected Tech Comm considerably and
again were not discussed. The generic task model was not in and of itself
the issue but the use of the constraint model to create the strict task
caused problems, as you know.

In this case, the way the proposal was implemented was not made clear (at
least not to my recollection) until very late.


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