W3C home > Mailing lists > Public > public-w3process@w3.org > October 2013

Re: small comment on the AB draft process document

From: Charles McCathie Nevile <chaals@yandex-team.ru>
Date: Wed, 16 Oct 2013 02:07:57 +0200
To: "Ivan Herman" <ivan@w3.org>
Cc: public-w3process@w3.org
Message-ID: <op.w40tbjyky3oazb@chaals.local>
Hi Ivan,

On Thu, 10 Oct 2013 16:50:30 +0200, Ivan Herman <ivan@w3.org> wrote:

> I had a look at the draft AB process document:
>
> https://dvcs.w3.org/hg/AB/raw-file/default/tr.html
>
> First of all, thanks for doing this...
>
> I also have some minor questions/comments.

Thank you for taking the time to make them...

> 7.2 says that there must be a Director approval as part of the general  
> requirement for advancement.
>
> 7.4.1.a, FPWD publication, refers to 7.2. This means that we need the  
> Director approval for a FPWD. This is heavier requirement than currently  
> (at this moment, transitions that require Director approval mean  
> transition calls, and they are only CR/PR/Rec...).
>
> That being said, the current practice (process?) is that FPWD is  
> approved by the domain lead, ie, he/she may have the delegated power of  
> the Director in that case. But that is not documented in the process  
> document as far as I could see. If this is the intention, it is worth  
> specifying it.

Good catch. In my understanding, "director approval" is delegated for FPWD  
without going through a careful transition call, while in other cases the  
director tends to require a more detailed analysis.

I agree that it would be worth mentioning this detail, since I see little  
evidence that it will change in the near future. I'll add some informative  
text to the next draft (which should be done tomorrow sometime).

> ----
>
> 7.4.3 says, as a first bullet item (to publish a W3C Rec)
>
> "- must republish the document, identifying it as the basis of a Request  
> for Recommendation."
>
> First I presumed that what was meant here was the availability of an  
> up-to-date editor's draft, which must be produced for the transition.  
> But that is not considered as 'publishing', formally, so I am not sure.  
> But then... here is what it says later in the section for all  
> recommendations:
>
> [[[
> • The Director must announce the provisional approval of a Request for  
> publication of a W3C Recommendation to the Advisory Committee.
> • The Advisory Committee review of the technical report must continue at  
> least 28 days after the announcement of provisional approval to publish  
> the Edited Recommendation as a W3C Recommendation.
> ]]]
>
>
> Does it mean that a document is published that is, for all good and  
> purposes, the final recommendation, but the AC has a month to object?

Basically.

> In which case the document's status on the Web should say something like  
> "this document has the provisional approval of the director but the AC  
> may still oppose it", as opposed to the final document that says "this  
> document has the approval of the AC". Meaning that the two documents are  
> not identical before and after the AC approval. Isn't it what the  
> current PR is all about? So why not calling a cat a cat?

The AB (before explaining themselves in public in any detail) felt that  
removing the formal step of PR was a Good Idea. I'm ambivalent.

> The only difference seems to be that there is no need for a formal  
> transition call to publish a Rec in the new process, which sounds fine  
> to me although, truth must be said, that transition is usually a matter  
> of an email these days, it rarely means a really heavy administration.  
> Ie, the simplification is not significant...

Agreed, but I don't think it is harmful, and I would prefer not to do the  
work of putting it back in. If you think it should go back in, feel free  
to say so (or raise an issue)...

> ----
>
> Just as a bike-shedding remark:-): I hate the term "Last Call Candidate  
> Recommendation".

So do I. Having the words "Last Call" is meant to make a clear link to the  
Patent Policy, since I didn't want to depend on changing anything there  
for this new process to be implementable.

> Our process is already a bit opaque, but using such a term would make it  
> even worse... Maybe some of you native anglo-saxons can come up with a  
> better term! Of course, we can just call it, surprise, surprise,  
> "Candidate Recommendation" :-)

I'd personally prefer "Last Call". (I like Aloysius as a name too, but it  
might be too confusing for this particular bike shed :) ).

Again, if you would like us to seriously consider a change please say so  
or raise an issue.

> (Do not take me wrong: I am all in favour of merging the current LC and  
> CR in one step as a simplification of the process, I am just annoyed by  
> the name...)
>
> ----
>
> 7.6.2, classes #1 and #2 of changes: does it mean that the Working Group  
> (or the team) is allowed to make changes on the documents directly, in  
> situ, on the TR pages? Or does it mean that a new document is created  
> (with a new dated URI) by the Working Group, which is then silently put  
> up on /TR (maybe with a home page announcement)?

This text was inherited from the existing process document. I believe the  
practice is that in the first case the changes can be made in situ  
(although there is a difference between changing the invisible content of  
markup and the actual text of a link, IMHO). I am not sure when the second  
class of change would be made, but my inclination is to either remove it,  
or require an Edited Recommendation rather than allowing in situ editing.

I will probably raise an issue on this tomorrow morning (I'm in Europe  
time), because I think it should be clarified.

Again, thanks for your comments.

cheers

Chaals

> ----
> Ivan Herman, W3C
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> FOAF: http://www.ivan-herman.net/foaf.rdf
>
>
>
>
>


-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com
Received on Wednesday, 16 October 2013 00:08:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:35:09 UTC