Re: Thoughts about future pubrules

[snip]
>>
>> Comments?
>>
>> Philippe
>
> ReSpec is a red herring here.  It's not part of the problem or part of
> the solution to the webmaster bottleneck.  It does help reduce the pain
> of complying with pubrules, but it does that already, without any
> changes to the current system.
>
> What we need is a web form (aka web service) like this:

A Web form won't save you from mistakes.  We'll still need to compare
the data provided in the form with the data extracted from the spec,
to check if they are aligned.

With ReSpec, you already have metadata in the document.  The tool
would just show you the extracted data and ask for your final
approval.

To summarize, all the informations at the top of the spec should be
generated from this data.  This would prevent errors.

>     Shortname:
>     Publication date: (today, or any date in the future)
>     Publication time: (maybe you want it to appear at 2pm or something)
>     URLs to fetch:
>         (each of these is fetched and put into the new dir;
>         the part after the last slash remains the same; one of
>         them must be Overview.html)
>
>         (it would be nice let people just name a CVS or HG directory, too.)
>
>     Spec Groups:   (like they ask us now)
>     Suggested Home Page Announcement:   (for the comm team to use or rewrite)
>     Maturity:   (unless pubrules-checker can be fixed to guess it right)
>
>     [SUBMIT]

There are other bits to be provided and/or checked:

* Markup Validator, CSS Validator, Link-checker, etc.
* history of the spec
* patent policy
* ...

>
> After you press SUBMIT, and the information is queued, you'll be
> redirected to
> http://www.w3.org/2012/pubstatus?user=...&shortname=---&date=....
> where you can see how it's progressing.  You'll be told how it's doing
> on all the checks.   If it passes them all, it'll wait in the queue
> until the given time is reached and then immediately appear on /TR.
> Hopefully comm can keep up with the home page announcements, but that's
> a separate issue.
>
> How's that sound?
>
> If it gets stuck, you ask webreq.    Webreq becomes tech support for
> publication, with nothing to do on days where things are going well.

I don't think people really understand why things are slow... There
are two main reasons for this to happen:

1. getting a spec pubrules-compliant

Most editors don't know the full W3C process.  They don't read the
main document explaining it.  And they shouldn't, because it's
complicated and error-prone.  They should rely on tools that work, but
the current ones (pubrules checkers and other validators/checkers)
fail at explaining simply and precisely why things are not ok in some
cases.

In that regard, I believe that Philippe's proposal goes into the right
direction, as the idea is to remove as much checking as possible, and
to generate the missing bits from some precise data (much easier to
check).

2. non compliant specs need interaction with the Webmaster

That's actually the biggest issue, as it involves back-and-forth
between humans working on other projects, under different timezones,
etc.

Because of these constraints, W3C has put a schedule in place
(Tuesdays and Thursdays) to get people more organized, asking them to
submit *checked* documents at least one day in advance, in order to
fix the remaining failing parts.  Even the most experienced editors
make mistakes...

That's why the editors are asked to make an appointment with the W3C
Webmaster. So if the proposal makes point 2. being still mandatory,
then I believe that we haven't improved the situation.

> One cool feature might be that xmlspec and respec input files could be
> submitted and the system would do the right thing, as if it were a Web
> Browser.  That would be nice.   Not sure whether to use something like
> selenium, or xsltproc and node+jsdom.

Please remember that there will be people implementing the fully
automated checker.  And there will be people using it as well.

Because of these reasons, I would propose to go for *only one way* to
do things.  Accepting alternatives in specs is one of the main reasons
for the current tools not to work very well.  JSON is a viable option
here.  There is nothing preventing us from generating metadata in
other formats during the actual publication, if we feel the need for
it.

>
> For permissions, there are several options.  Maybe only W3C staff can
> press SUBMIT.   That would be easiest (and you could do without the
> "user" parameter), but read on.

That will depend on the requirements that W3C will put on the
documents.

> What I'd really like would be that
> ANYONE can press submit -- but it remains in the queue until
> appropriately endorsed.

I guess we all want that :-)

> If it's a FPWD, CR, PR, or REC it would need approval from a chair,
> staff contact, and a w3m'er.   (The people are not so much approving the
> document, as certifying that correct process has been carried out.  The
> chair is saying the WG has resolved to publish, not saying they
> personally approve of the document.)
>
> If it's an OWD or LC or NOTE (after prior FPWD), it would only need
> approval from a chair and staff contact.

I agree on the principles, but this will need to be fully documented.

And tested.

> I suggest that ED be allowed, too.  That would need no approval.   I
> suggest ED's appear at a URL based on the submitters userid and the
> shortname they suggested, like:
> http://www.w3.org/editors-draft/21507/my-pet-spec-20120430
> with a "latest version" at
> http://www.w3.org/editors-draft/21507/my-pet-spec

Adding nice-features-to-have won't help people to implement the
tooling, I'm afraid.  We need to stay pragmatic and think about a
system that would get *all* the editors on board.

Anyway, I believe that Philippe's proposal is a pragmatic start.

Alexandre.

>
> Cool, eh?  No more Editor's Drafts in a hundred random locations, with
> no change tracking or anything.   Maybe the system can offer convenient
> diffs.
>
> Ideally, everything would start as an ED.  The WG would approve
> publication of a given ED and the system would do the necessary
> transformations to turn it into a TR, with no need for human hands (or
> human error).  That would be cool, but would require more getting into
> the guts.  (In particular, the system would need to be able to change
> the publication date on several documents that all link to each other.
> Also, there would need to be an allowance for small changes being made
> even after some approval stages, vetted by someone.)
>
> That'd be nice, huh?
>
>       -- Sandro (who handed the webmaster three more TRs today, one
>                  respec, one xmlspec, and one hand-written html)
>
>
>
>
>

Received on Wednesday, 2 May 2012 17:40:26 UTC