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

 


Help: OASIS Mailing Lists Help | MarkMail Help

workprocess message

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


Subject: RE: PAC: Suggested language for CS 6


> Let's assume for purposes of discussion that the year begins
> January 1.  Let's pretend that I'm the chair of a TC that meets
> the first week of January and votes to send a specification to
> OASIS for standardization.  Then the next quarterly package goes
> out March 1, the call for a vote goes out July 1, and the vote on
> our proposed standard ends September 30.  That's almost nine
> months.
>
> Am I the only one who thinks that this is a really long time?

Yes, that's a very long time. If I were a TC chair I wouldn't want to wait
more than a couple months to get my results back. But some compromise has to
be made with the people who get the ballots out and back in (me) and the
people who are reviewing the spec and doing the voting.

I assume I could, in most cases, turn around the ballot packets in a week or
so instead of a month. Could we also expect review and voting to occur in a
six to eight week period instead of three months? And what if we had a
voting cycle every month instead of three? Best case would then be ~three
month submission to results, and worse case is, what, four or five months?

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.

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.

</karl>



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


Powered by eList eXpress LLC