Re: [dita] DITA 1.3 Proposal Process

[Joann Hackos <joann.hackos@comtech-serv.com>]

Hi Robert,
I think you have a workable plan here. It is especially important that
whatever we vote on is announced in advance so that there are no surprises.

Perhaps we can ask the TC chair to notify all SCs but make a special effort
to notify the related SC at Step 1. If a proposal is in the works, the SCs
need to look at it as soon as possible.

Then, the notification after Step 2 ensures that everyone knows what is
happening and doesn't miss a critical piece of information about a proposal.

Thanks for working on this important issue.
JoAnn


On 8/9/10 9:57 AM, "Anderson Robert" <robander@us.ibm.com> wrote:

> 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
> subcommittees.
> 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
> 
> Thoughts?
> 
> Robert D Anderson
> IBM Authoring Tools Development
> Chief Architect, DITA Open Toolkit
> 
> 
>                  
>              Joann Hackos
>              <joann.hackos@com
>              tech-serv.com>                                             To
>                                        DITA TC <dita@lists.oasis-open.org>
>              08/07/2010 04:34                                           cc
>              PM  
>                                                                    Subject
>                                        [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.
> 
> Best,
> JoAnn
>