RE: PAC: Suggested language for CS 6

["B. Tommie Usdin" <btusdin@mulberrytech.com>]

Karl Best wrote:
>Given the current small number of committees, we don't really need voting
>schedules tied to months or quarters; the ballot could just be sent out when
>the TC has it finished. The problem arises when we take into account the
>infinitely scalable problem where there may some day be hundred or thousands
>of committees. Do we need to impose these constraints now, and delay current
>activities so much, just in order to prepare for eventualities? Perhaps we
>can just say that for now we will follow a simple schedule, and include
>language for OASIS to specify a regular schedule some time in the future
>when it gets to the size where batches must be sent out instead of singles.

I'm concerned about the premiss here; all of our work on this activity has
been based on the assumption that we are designing a process for a large
number of TCs, and that the process will not be tweaked after it is in
place.  None of us knows for sure if this assumption is valid, but we're
living with it.

If we are to accept this "lets do it one way until it becomes inconvenient
and then revisit" suggestion I think we should revisit most of the
decisions the committee has made.  Most of the process we are drafting is
overkill at this time!

>
>So, how about this: TC submits anytime, OASIS gets the ballot out within two
>weeks of submission, members have 60 days to review and vote, and OASIS has
>two weeks to compile and return the vote to the TC. Total three months,
>usually less as OASIS won't always take the full two weeks on each end. As
>the quantity gets to the point of requiring batches, we could send out a
>batch on the first of each month; this will mean overlaps as two months is
>allowed for voting, but this would certainly speed things up.
>

I am also concerned about compressing the review time to 60 days.  This
really isn't long enough for people who are busy doing other things to take
a good hard look at something new and see if they have problems with it.
If we go to a schedule this compressed I think we also need to require a
positive not a negative vote: perhaps a TC Specification should become an
OASIS Standard if enough (50% ?) of the members LIKE IT.  On this schedule,
with the kill-by-negative-vote process, it seems to me that virtually
everything will pass.

-- Tommie

======================================================================
B. Tommie Usdin                        mailto:btusdin@mulberrytech.com
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                           Phone: 301/315-9631
Suite 207                                    Direct Line: 301/315-9634
Rockville, MD  20850                                 Fax: 301/315-8285
----------------------------------------------------------------------
  Mulberry Technologies: A Consultancy Specializing in SGML and XML

======================================================================