Re: Editor's drafts on /TR/… ftw, was Re: new TR tools and editor's drafts?

On 03/07/2013 15:39 , Marcos Caceres wrote:
> On Wednesday, July 3, 2013 at 2:24 PM, Robin Berjon wrote:
>> To be fair though, in the past few years (before joining the Team)
>> I've never had to wait more than 24h before releasing a WD.
>
> And your 1 week CFCs?

I don't see the point of CfCs for WDs frankly, and when chair have often
done without them. Other chairs may feel differently, but that's an
issue of group organisation — it has nothing whatsoever to do with W3C
actually.

>> DAP had its calls on Wednesday afternoons Paris time, and we always
>> made the Thursday publication window. Beyond the advantages in
>> simplicity in letting groups push WDs out by themselves (if nothing
>> else it would free up time for the webmaster to do more interesting
>> things), it might be useful to figure out why some groups seem to
>> need much more time than that. Not knowing those problems, it's a
>> definite possibility that they won't go away if we add automation.
>
> Here are the problems: It's all that process… having to email the
> Chair, having to convert the spec from ED to WD and move it to a
> separate branch on GH, wait for approval from the Chair, wait 1 week
> for some CFC that no one ever gives a crap about because it's just a
> WD, etc. etc. Then being frustrated that one day after you publish
> you fix a bunch of stuff, and they you again have to go through the
> same annoying process.

Aside from converting from ED to WD, which ought to be trivial (in 
ReSpec it's just a matter of adding ?specStatus=WD to the URL and saving 
the output) none of the above is a W3C problem. Publication requests for 
WDs are made by the "Document Contact", a role that can be taken by the 
editor (or in fact pretty much anyone if the group wishes so).

If as an editor you want to be allowed to make publication requests on a 
regular basis in order to keep the TR copy fresh, without consulting the 
group, then that's definitely something that your group can agree to. 
You'll still have to file webreqs, but that's not a huge hurdle (more 
than pressing a button, but only so much).

That leaves "moving things across branches in GH". Well, if you don't 
like that, err, well, don't do it.

I'm not saying that W3C couldn't work on getting the whole process more 
streamlined, and on ensuring that the default process that groups adopt 
is more lightweight. But don't blame W3C for constraints that groups 
impose on themselves of their own accord. You'll get much farther by 
changing the way in which your group operates and then showing everyone 
else just how much more efficient you are.

A lot of what people call "Process" really isn't. Don't just question 
authority; question the lore. Maybe I should make that a blog post or 
something :)

> With regards to CR, LC: we need to see those not as static documents,
> but a as "phases": during the LC phase, which spans some period of
> time, one can make fixes but the process remains in LC. The same with
> CR - which can lead to a violation (normative change), which casts
> you back to WD and again to the LC phase (which is locked in for some
> period of time). It's not that hard.

As a rule I agree, but we do need to be very careful about what gets 
introduced there. A feature change at those steps changes the IPR 
commitments. While I'm all for getting as much IP into RF pools as 
possible, the rules of the game with IP holders is that we don't get to 
play that sort of trick once they've made a commitment. As much as I 
dislike patents, it seems fair.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Wednesday, 3 July 2013 13:56:02 UTC