W3C home > Mailing lists > Public > spec-prod@w3.org > April to June 2013

Re: Publication Request Form / System

From: Alexandre Bertails <bertails@w3.org>
Date: Thu, 20 Jun 2013 12:07:00 -0400
Message-ID: <51C328A4.9050105@w3.org>
To: Gregg Kellogg <gregg@greggkellogg.com>
CC: Doug Schepers <schepers@w3.org>, spec-prod@w3.org, Philippe Le Hegaret <plh@w3.org>
On 06/20/2013 12:03 PM, Gregg Kellogg wrote:
> On Jun 20, 2013, at 8:36 AM, Alexandre Bertails <bertails@w3.org> wrote:
>> On 06/20/2013 10:37 AM, Doug Schepers wrote:
>>> Hi, folks-
>>> I have a suggestion for our publication workflow that I think would
>>> provide clarity and consistency: a publication request form.
>> Already in the pipe, partially implemented and Webmaster-only for now
>> as development is making progress and priorities are sorted out. But
>> that's clearly the plan for the future.
>>> This would be a form that contains all the fields needed for each stage
>>> of the publication process, including spec name, shortname(s), URLs of
>>> Editor's Draft and TR draft, abstract, WG name, WG approval to publish,
>>> planned publication date, news-item blurb, optional list of changes,
>>> notes (for anything out of the ordinary), etc.
>> Believe me, you don't to fill these values by hand, it's highly
>> error-prone. There is currently a service that "extracts" some of the
>> informations from the spec, but it's a bit buggy and does not capture
>> everything. The long-term alternative is to make the metadata
>> available directly in the spec, could be generated by ReSpec and other
>> tools directly. That's fairly easy, except for editors which must be
>> bound to the database. This one would be easy if people can agree on
>> using URLs to speak about the editors, though.
> If the doRDFa variable is set (to "1.1", I believe) in the respecConfig, it ends up generating good RDFa for all of this stuff in the spec. It's been optional, and only included in a couple of specs from RDF-related specs AFAIK. It seems to me that there's really no downside to making this the default (perhaps with an option to turn it off). This would make extracting such information from the specs themselves much less error prone.

That's interesting. I've never looked carefully at what is generated
by ReSpec there. Can you please point me at a recent spec embedding
some RDFa? I can have a quick sense about how much work there would be
to make it usable on our side.


> Gregg
>>> Anyone could fill out this form, though typically it would be the staff
>>> contact's responsibility; once submitted, the publication request goes
>>> into the DB, and emails to the appropriate people and lists (chairs
>>> list, domain lead, staff contacts, marcomm, webreq, etc.) are sent out
>>> automagically.
>>> In addition, it's queued up in a list/tool (maybe team-only, but with a
>>> public view) that lets the domain lead and/or director click a checkbox
>>> to approve the publication if necessary; this would also generate the
>>> correct emails. This list would include crucial status information, to
>>> make it easier to track what stages have been done for the publication,
>>> and what is blocking, making it consistent and easy to review and
>>> approve without hunting through email lists.
>>> Some odd cases would need to be done by regular email, of course, but
>>> the vast majority of spec publications would be handled by this.
>> That needs some reflection. In practice, we've seen people asking for
>> exceptions (whether they are legitimate or not is another question :-).
>> The system must take that into account, it's not that easy,
>> unless we enforce the rule "no exception, follow the process".
>>> This would be an optional tool, though staff contacts would be
>>> encouraged to use it; if the pub requests came through email, the staff
>>> contact or webmaster could just make sure they are filed in this system
>>> correctly.
>> Someone once suggested to have a transition period (something like a
>> year) so that existing specs can be migrated, then it would become the
>> norm. The Webmaster's time would be more useful helping for these
>> migrations rather than having to deal with the exceptions forever.
>>> This would empower WG participants, and could free up some of the more
>>> tedious time from staff contacts.
>> +1  oh and Webmaster's time as well, let's not forget it :-)
>>> This may already have been suggested elsewhere or elsewhen (I thought of
>>> it years ago), but I think it'd be useful.
>>> Anyone like this idea?
>> /me likes
>> Alexandre.
>>> Regards-
>>> -Doug
Received on Thursday, 20 June 2013 16:07:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:18 UTC