| TR automation

TR Publication process Paper Trail

Abstract and Status

This document describes the current paper trail of the TR publication process, that is the different steps, actors and approvals a document must go through before being published on the TR page and then analyzes the ways it could be automated and the potential benefits of this automation.

It's part of the TR automation project, developed more or less in the SWAD framework. It's not the result of any consensus except the editor with himself.

Current paper trail

As a results of the Process Document and the Pubrules, a document ready to be published in TR space goes (or should go) through the following steps:

1. the document editor of the Chair asks for approval of the status section to the Team contact
2. if the document is new or reaches the status of CR, PR or REC, the Team contact requests approval from the Director
3. The document editor, the Chair or the Team contact asks for a publication date to the Webmaster and the Comm Team if needed (press release, AC announcement, ...)
4. The document editor, the Chair or the Team contact sends a publication request for the given at the decided date
5. The Webmaster or the Team contact puts the document in TR space
6. The Webmaster checks the document for pubrules compliance, informs the editors of any issue
7. The Webmaster at the decided date publishes the document (links from the latest version URI to the dated one), updates the TR page and informs the requester and the Comm Team that the document has been published
8. The Comm Team announces the new publication (home page news, AC Representative notice, ...)

Automation plan

To make sure every step is followed as required, but also and mostly to allow a faster and more direct publication process, I describe below some way to automate this process. This automation should obviously use Semantic Web mechanisms as much as possible.

The approvals dance

One of the frequent bottlenecks in the publication process, especially for the new documents, is the need to get Director's approval. Automating this would probably allow to get a better reaction time for this.

Process description:

1. the editor or the WG chair submits the document's URI to the paper Trail machine (Web form)
2. the Team contact is alerted, approves or rejects the status through a Web interface; the Machine requests Director's approval if needed, proposing choices between Tim or 2xw3m-ers
3. the Director or his substitutes are alerted, approves or rejects the publication through a Web interface

Ideally, the alert system would both send an email and update a TODO list for the concerned person. That way, for instance, Tim could get over his publications requests list and approves them once a day.

The hunt for a date

Another factor of delay and source of email traffic is the need for a publication date. Since pubrules require that the published document is dated, that this date influence many parameters in the document, and that the Webmaster is reluctant to publish a document whose date is too far in the past, and forbidden to publish on whose date is in the future, some automation in the date picking process could prove to be useful.

Process description:

1. the Webmaster maintains a list of dates that wouldn't be convenient for publications (other projects, vacations, ...)
2. the Head of Communications maintains a list of dates where no publication is possible (moratorium)
3. the Communication Team maintains a list of dates where special publications (that need Comm Team work, like press release, call for review, ...) is not convenient or not possible
4. the Admin Team or the M.I.T. administration maintains a list of closed days at M.I.T.
5. all these data are gathered by the Webmaster Calendar machine, which outputs a Calendar of possible/inconvenient/impossible publication dates
6. the editor, the Chair of the Team contact can then pick safely a date using this Calendar

Note that to the list of data could be added a set of rules, e.g. if the date is today, it's always inconvenient. Another cool feature would be that the machine accepts input from the Team contact: he could then pick a date in the Calendar; if it's not said as being inconvenient, the Team contact automatically gets a publication slot (the Webmaster and the Comm Team are alerted accordingly); if it is inconvenient, it then needs Webmaster and Comm Team approvals.

Combining both of the above remarks, a rule could say "any date where 3 publications are already schedulded is inconvenient".

The "Publish this" button

Once a document has gone through all this, the Webmaster asserts that the document is pubrules compliant and publishes it in TR space following a predefined process [Team only], which is cumbersome and leads sometimes to human errors.

All of this should be automated to the point where the Webmaster should only have to push a "Publish this document" button, and then have the Machine miraculously creates the link between latest and dated URIs, updates the TR page and as a side bonus, create the different views of this page.

We already have the basis for the different views:

• by date
• by title
• by author