- From: Charles McCathie Nevile <chaals@yandex-team.ru>
- Date: Mon, 17 Jun 2013 23:01:26 +0200
- To: "Jeff Jaffe" <jeff@w3.org>, "Arthur Barstow" <art.barstow@nokia.com>
- Cc: "public-w3process@w3.org" <public-w3process@w3.org>
Hi Art,
(I still have in my backlog to answer your questions. Unfortunately there
is a bunch of discussion tied up in AB minutes which are member accessible
- so I presume you have read them - but not available to this CG, and
other random places).
Some of the problems I wanted to solve:
In Last Call and CR especially
* Going LC->CR->LC->CR... seems bad.
* It strikes me that LC is a very important step for the patent policy,
yet trivially easy for working groups to enter, with the only real check
being the threat of returning. That threat is considered a certainty by
many people and is therefore empty.
* On the other hand, CR has a real check on entry, yet most of what it
requires should already have been done, or will happen later.
* I don't want to have a change that can only take effect by getting a
change in the patent policy. (I think the patent policy should be updated
to fix bugs, and maybe even changed, but having that as a dependency is
something I only wish on a select few acquaintances)
(These four reasons are behind merging CR and LC)
Other things:
* Getting WGs to get their testing story in order earlier would be good.
But trying to do it with rules isn't a great idea IMHO.
* A process that enforces either a waterfall model, a "super agile living
standard", or something else, or prohibits any known model of development,
seems like a bad idea. I've aimed to make them equally feasible under the
same process (modulo the formal requirements of the patent policy - FPWD,
LC, Rec).
* There is no assumption made about versions, and whether there will be
later versions of specs. I have tried to enable that as easily as possible
without requiring people to do it.
* AC review is sort of a member benefit that shouldn't entirely disappear
- but often review would be useful earlier, especially positive statements
of things the AC *like* in a spec.
* The Process document is too long. Removing informative text may make the
requirements clearer.
* There are implied requirements, or requirements where there is nobody
actually responsible for them happening. I have tried to clear that up.
* the "post-rec" process is very unclear. Apparently groups can (and MUST)
define errata, which can be normative and more or less anything. Tidying
that seems helpful
* The only mentioned use of a Note is for work that has been abandoned (at
least "for now"). Yet in practice Working Groups and Interest Groups
publish Notes for other reasons, and that should be clear.
* Keeping the rules relatively short and simple reduces the odds that
people will try "lawyering them" instead of actually making reasonable
quality specs.
On Mon, 17 Jun 2013 15:39:11 +0200, Arthur Barstow <art.barstow@nokia.com>
wrote:
> On 6/17/13 9:09 AM, ext Jeff Jaffe wrote:
>> I'd be interested in your sense of the highest priority issues.
>
> The main pain point for me is the dependency "policy" blocks progress as
> I already mentioned in
> <http://lists.w3.org/Archives/Public/public-w3process/2013May/0020.html>.
This is something that is in pubrules, not in the process. I agree it is a
problem, but I doubt solving it in the process is the right place. In
particular, I don't want to make the process as restrictive as the current
pubrules, but I also recognise that the pubrules restrictions are there
for reasons that are not just arbitrary. I also don't think the so-called
"living standard" model is nearly as valuable as some of its proponents
claim - there are serious problems with using it in situations beyond just
patent lawyers counting angels on pin heads.
I think there is work to do to describe the issues clearly, more to
describe a solution which I expect to be something that covers both
Editors' drafts and more stable releases of various kinds. And more work
to get some reasonable level of consensus.
Getting people to stop mixing politics with documents would be good for
the Web.
> I also provided information re the Process Document in
> <http://lists.w3.org/Archives/Public/public-w3process/2013May/0015.html>.
> To expand on section 7 a bit ...
>
> * One change I think would be useful is to be able to go from CR to CR
> if no new features are added
Yes. My proposal effectively allows this.
> * It seems like PR could be eliminated if the Call for Implementations
> included a clear statement to AC reps that it was their last chance to
> submit comments. (For example, something like "this spec will advance
> directly to Recommendation after the group has satisfied the Director
> the spec has interoperable implementations".)
I have more or less done this. There is still a period for AC review when
the spec is "provisionally approved as a Recommendation" but that phrasing
and some other stuff notes that there needs to be a pretty serious reason
to overturn a spec at the end of an AC review.
> Anyhow, it appears to me that combining LC and CR eliminates important
> checkpoints
Can you explain which ones?
> and creates too many other issues
You mean because about 20 issues were raised by the AB?
FWIW I don't think that's much of a basis for judgement. The AB managed to
address them all and either reach resolution or outline a clear basis to
do so in less than a day, which might show they are super-efficient but
seems to indicate to me that the issues were simple clarifications.
I agree that the whole exercise could have been done in a more ideal way.
This group was set up 18 months ago to enable that, but nobody took the
opportunity to use it, and as a member of the AB I have felt generally
bound to follow its processes first.
> (to address a problem space that isn't entirely clear to me and
> apparently some others as well
> <http://lists.w3.org/Archives/Public/public-w3process/2013Jun/0021.html>).
(I suspect there is stuff I forgot still...)
cheers
Chaals
--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
chaals@yandex-team.ru Find more at http://yandex.com
Received on Monday, 17 June 2013 21:02:05 UTC