- From: Ivan Herman <ivan@w3.org>
- Date: Wed, 16 Oct 2013 10:44:38 +0200
- To: Charles McCathie Nevile <chaals@yandex-team.ru>
- Cc: public-w3process@w3.org
- Message-Id: <4D691E9E-2266-487A-99E3-B03092DBB66E@w3.org>
On Oct 16, 2013, at 02:07 , Charles McCathie Nevile <chaals@yandex-team.ru> wrote: > 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). Thanks. > >> ---- >> >> 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)... Well, I understand that not calling it a PR may make it look less of an administrative hurdle, ie, I would not fight for it. But maybe spelling out even more explicitly would be helpful. It is also not clear to me how it exactly works in practice: - would a Rec-to-be become automatically a Rec unless it is objected to, or is there a formal step - would somehow the status section (or something else) reflect the situation I think the second item is important: it should be clear, when reading the document, that it is still not 100% accepted. Maybe not the status section, maybe something on top of the page showing a warning... anything is fine, really:-) > >> ---- >> >> 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 :) ). I certainly had to look it up on Wikipedia > > Again, if you would like us to seriously consider a change please say so or raise an issue. Actually, I think it should be seriously considered. As the issue above on PR shows, much of the complexity of our process may be a perception issue (not all!:-), and the terms used add to this perception. I like Candidate Recommendation because it is etymologically clear and shows what it really is in the new process. But I am not attached to a particular term. > >> (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. > Actually, I do like what is there, ie, that even #2 changes can be done in situ. Let me give a typical example: we have a document in the making (JSON-LD), that has a dependency on Promises (or whatever the name in vogue is these days). We would really like to publish this as a Rec today, but the reference to the Promises document cannot be normative. Say in 6 month the Promises document, in its current format, becomes final and cast in concrete. That means that a new JSON-LD document should be issued with the reference changed to normative. This change would not affect conformance of implementations, but it is not a broken link or invalid markup change: ie, it falls under category #2. On the other hand, it looks like madness to go through the whole hoopla and contacting the AC over this change, so I would like the team or the WG to make the change in situ, announce the change and go on with their lives... > 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. Sure. Thanks for doing this Ivan > > 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 ---- Ivan Herman, W3C Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 FOAF: http://www.ivan-herman.net/foaf.rdf
Received on Wednesday, 16 October 2013 08:45:07 UTC