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


We all agree that (like members) SCs should get involved early in any
proposal that affects them or that their work may affect.

The issue is how do they recognize that a proposal has particular
relevance for them.

Sometimes the proposer(s) or the chair or someone else on the TC call
will recognize implications for a SC, but most often it will be someone
on the SC. I may be wrong, but I think there are some SCs that only have
a member attending when they have a SC report to the TC.

So, best if each SC has a member who regularly attends the TC and is
conversant with current work of the SC. 

Backup to that, but no substitute for it, is Robert's suggestion that
the chair notify every SC when a proposal passes Step 1 or 2. At that
point, if this is news to the SC it behooves them to look at the
proposal and evaluate their possible interest.

The time constraint is a good suggestion too. Was that implicit in the
original process proposal, & just needs to be more explicit?

	/B

> -----Original Message-----
> From: Robert D Anderson [mailto:robander@us.ibm.com] 
> Sent: Monday, August 09, 2010 11:57 AM
> To: Joann Hackos
> Cc: DITA TC
> 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 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
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS 
> TC that generates this mail.  Follow this link to all your 
> TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> oups.php 
> 
> 


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