[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[no subject]

>> 3. review the remaining defined name descriptions. The descriptions
>> should be divided by topic (CLtL divisions have been used in the
>> past) and there should be one topic given to each reviewer. 
>> This job should take 1 month.
>> 4. collect, review and enter comments. This job should be done
>> by 2 people and should take 2-3 months.
>I think this is far too optimistic.  It might be realistic if we were
>all working full-time on producing the draft, but we aren't.
I don't agree with this. In the past I thought that the more time
given, the more time used, but that doesn't happen with most people.
It seems that a great deal of work gets done in the milliseconds
before a due date. As you know, the tricks to getting something done
are to create a great number of small tasks and set incremental
goals to get them done. The fact is that we could each work full-time
on this for years and never get it the way we exactly want it.
We have to just do something and declare it done for now, and
correct it for next time.
>As I've noted in my own review comments on the latest draft, there are
>some fairly extensive sections in the defined name descriptions that
>are still in need of heavy revision and rewriting (such as the
>DEFSTRUCT section).  If you're going to give the reviewers in item 3
>authority to make these kinds of changes directly and have the 2
>people in item 4 acting as editors just to make sure all the pieces
>are correct and still fit together stylistically, you might be able to
>get it done in 1 month by making use of massive parallelism (assuming
>you can find that many volunteers who are both willing and able to
>write).  But if you rely on the 2 people to do all the rewriting, it's
>likely to take them much longer than 2-3 months.
DEFSTRUCT is not a representative example. There are a relatively small
number of descriptions that are that long and will take that much

I'm not trying to minimize the amount of work that needs to be done, but
we have to stop wordsmithing and rearranging at some point. We
should never stop looking for technical errors (all kinds - inconsistencies,
omissions, etc.), but we should set a date at which we will send
an version of what we have for public review. After that we should
set a date for when public review is done. At that point, I'll make
a bet that there will STILL BE ERRORS! We are meerly producing an
incremental version of the standard, not the standard to end all