Re: Charters for review

Hello all,

I agree with many of Ian's concerns about the charter. I'd like to  
comment on some of them specifically.

On Nov 21, 2006, at 1:05 PM, Ian Hickson wrote:

> Thus:
>
>  * Regarding technical matters, there shouldn't be a difference
>    between being a working group member as a W3C Member Company, a W3C
>    Invited Expert, or participating as a non-W3C Member. This should
>    be made explicit in the charter; currently the charter implies that
>    non-members are not full members of the working group.

Unfortunately I think the W3C Process Document defines who is a  
"member of the working group", so I think the document will have to  
otherwise indicate that non-members may participate fully

>  * There should not be any secret mailing lists, even for
>    administrative purposes.

I agree. A separate administrative list may be useful, but I see no  
specific reason for it to be secret.

>  * There should not be teleconferences or face-to-face meetings, as
>    most participants could not afford to attend such meetings. There
>    could be the option of annual meetings, open to all participants,
>    with some of the less well financed working group members being
>    sponsored by the other members to attend, but such meetings would
>    have to be informal, with no actual decision-making ability, so as
>    to prevent the non-attending members from feeling
>    disenfranchised. (The existing community numbers in the hundreds;
>    teleconferences and face-to-face meetings are unmanageable at such
>    numbers anyway.)

I think it's ok to have teleconferences occasionally if there is a  
real need (sometimes it's faster to talk something out than settle  
via email)  but they should not be regularly scheduled. I think one  
face-to-face meeting a year (maybe two) is a good idea, but four is  
overkill. I sympathize with Ian's concerns about participants who  
can't make it to an in-person meeting, but I think making such  
meetings open to anyone who is able to attend, and having any  
decisions made at such a time still subject to review and comment by  
those not present, adequately addresses such concerns.


> DECISION PROCESS
>
> In any venture of this magnitude, it is guarenteed that everyone  
> will need
> to make compromises. However, it is important that in doing so, the
> quality of the work is not also compromised. To ensure that  
> specifications
> maintain a high level of quality, I would suggest assigning each
> deliverable a single editor, who is responsible for taking into  
> account
> everyone's opinions, and integrating them into one coherent whole.  
> Thus I
> propose that the charter explicitly require a single editor per
> deliverable to be responsible for decisions and finding compromises.

While it may be preferable to have a single editor in many cases, I  
think there may arise occasions where a small group of editors can  
work effectively and cohesively so I would rather the charter didn't  
precisely specify number of editors per spec.


> Of course, having a single editor leads to the possibility that he  
> will in
> fact ignore feedback and do his own thing. To avoid this, I propose  
> that
> the charter also have an explicit process for overriding the editor.
>
> This would, IMHO, be a much more agile solution than the current  
> proposed
> process, namely requiring the chair to record a resolution and  
> objections
> for each decision. Given the magnitude of this work, having the  
> working
> group explicit make a decision on every small thing would  
> jeapordise the
> entire effort.
>
> I propose the following text to replace the Decision Policy section:
>
>   The Working Group will assign a chairman. The chairman is
>   responsible for deciding when to publish snapshots of the
>   deliverables (as described under "Expected Milestones" above), and
>   for resolving conflicts, as described in this section.
>
>   The Working Group will assign an editor for each deliverable, who
>   has editorial control over that deliverable. Editors must base their
>   work on the technical feedback of all the Working Group members.
>
>   W3C Member Companies and W3C Invited Experts may request that a
>   decision made by one of the editors be reversed. If this occurs, the
>   chairman must post an e-mail to the Working Group's mailing list
>   asking the other W3C Member Companies and W3C Invited Experts that
>   are members of the Working Group to state their opinions. Each W3C
>   Member Company and W3C Invited Experts may vote once, by sending an
>   e-mail to the list stating their position. If a majority (more than
>   half) of the votes collected in the week following the posting are
>   in favour of reversing the editor's decision, the editor must make
>   the required change or relinquish the editor position.
>
>   This process is not expected to be used often. If it is used, the
>   Working Group's charter should be re-examined by the W3C.

I like this proposed appeals process. However, I'd make a few changes:

1) The person requesting an appeal must clearly state what they  
disagree with and why; the editor should respond in a timely manner  
(or may cite a previous email response). Both should be available to  
the WG members when asked to consider the appeal by the chair.

2) I'm not sure if it is necessary to restrict who may ask for an  
appeal. I would say anyone can ask but some minimum number of WG  
members must agree to consider it (this does not commit them to  
agreeing with the person making the appeal). Otherwise, for your  
average lay contributor, the only avenue of appeal beyond the editor  
will be to ask the activity lead and such, which is much more  
heavyweight.

3) I don't think use of the appeals process should automatically  
trigger re-examination of the charter. If there is a regular failure  
to reach consensus, then the editor should first be called to task.  
Even given this, it is possible there may be serial objectors who are  
not satisfied and this should not throw open the whole future of the  
group.

> The last two paragraphs would consist of the only difference  
> between being
> a W3C Working Group member and a non-W3C Working Group member.  
> Obviously
> if the entire community disagreed with the W3C members this would  
> be very
> noticable; I believe this transparency would be enough to prevent this
> process from being abused.

To be compatible with terminology of the Process Document, how about  
saying "Working Group participant" for the more official kind of  
member, and "Working Group contributor" for the more general  
category. Or we could say this Working Group will, like an Interest  
Group, have public participants, and then the term for the more  
official kind of member could be "Working Group member". Sorry to  
nitpick on the terminology but I'm hoping to prevent future  
terminology debates.

> As it happens, this process matches the WHAT WG process, which has  
> so far
> been quite successful (in fact, the "overriding" clause has never been
> invoked, and the community has done nothing but get stronger).  
> Having a
> similar process for the two groups would also enable the groups to  
> share
> an editor, thus saving significant time and effort. (I would  
> volunteer to
> have that role if the other working group members were happy with  
> this.)
>
>
> TIMETABLE
>
> The milestones in the charter are somewhat unrealistic. I would  
> suggest
> the following timetable would be far more likely, based on past  
> experience
> with HTML4 (which is still not fully implemented by any two UAs),  
> DOM, and
> CSS2.1 (which is the only large W3C specification to have attempted a
> serious disambiguation period):

I agree the current timetable is overly agressive - it's hard to  
imagine reaching REC in 2009 without major process abuse. But on the  
other hand, plotting the future out to 2022 has little predictive or  
planning value. I would prefer if the charter simply did not include  
a milestone for REC. Let's leave five-year plans to the soviets.

>
>     First Working Draft in October 2007.
>     Last Call Working Draft in October 2009.
>     Call for contributions for the test suite in 2011.
>     Candidate Recommendation in 2012.
>     First draft of test suite in 2012.
>     Second draft of test suite in 2015.
>     Final version of test suite in 2019.
>     Reissued Last Call Working Draft in 2020.
>     Proposed Recommendation in 2022.
>
>
> TESTING
>
> I also think it is critical that the volume required of the test suite
> deliverable be quantified. The term "comprehensive test suite" is  
> vague at
> best; the working group is likely to steadily reduce its opinion of  
> what
> is "comprehensive" as the work progresses. It is far better, in my
> opinion, to have a very specific goal in place, for example, "an  
> average
> of 2000 tests per chapter". This gives the working group an  
> unambiguous
> goal. The goal is somewhat arbitrary, and, after discussion, could be
> changed by rechartering, but this would require a clear intent, rather
> than it being a subconscious change over time.

Numeric quantification doesn't seem like a good way to go to me. It  
simply moves the vagueness to defining "what's a chapter" and "what's  
a test case". I would rather say the test suite should cover all  
mandatory conformance requirements, including good coverage of edge  
cases.

Regards,
Maciej

Received on Wednesday, 22 November 2006 03:46:42 UTC