Chairing

From SVG
Jump to: navigation, search

From HeyCam, at https://public.etherpad-mozilla.org/p/svg-chairing

Telcon scheduling and chairing

  • Typically Erik and I have rotated chairing of calls week by week. 48 hours before a call, I send out a mail to w3c-svg-wg to remind people to add items on to the Agenda page (otherwise people don’t remember do it until the actual Agenda gets sent out). I try to encourage agenda topics being announced in advance, rather than agenda+ed at the start of the meeting, so that people have a chance to think about the issue/topic before the call.
  • 24 hours before a call, I send out the Agenda mail with any items from the Agenda page plus other administrative topics that might come up.
  • I have not been good at this lately, but gathering topics from www-svg that require discussion and putting them on the agenda would be good, so that we can be responsive to public comments/issues.
  • Finding a scribe is always difficult. :-)
  • I usually wait until at most 5 minutes past the meeting starting time to get going, as not everyone tends to be on the call right at the starting time. Finishing on time is also important!
  • One thing I’m also not good at, but which might also important, is to ensure discussions don’t go too long. Otherwise it’s easy to run out of time for the scheduled discussion topics. Setting explicit time limits in the agenda mail, like CSS does (or did, with the old chairs) might help?
  • As a general meeting-running principle, it’s always good if topics conclude with an obvious next step: an action for someone to investigate or to implement a resolution, for example.
  • After the call, it’s good to update the Agenda page right away for the next call’s date and to remove the topics that got discussed.

Mailing lists

  • I’m still waiting on Doug to decommission public-svg-wg. :-) In the meantime encourage people to use w3c-svg-wg for administrative things and www-svg for issue discussion.

Chairs list

  • You’ll be subscribed to the chairs@w3.org mailing list. You might see requests for spec reviews from us there (although usually the request also goes to our mailing list). I think it's good to get one or two specific people to commit to reviewing the spec, and to write up their comments so that they can be signed off by the group and sent, before the deadline. Leaving it to just whoever wants to look at the spec is a recipe for it not getting done. :-)

Spec publications

  • Publshing drafts of SVG 2 is still a bit of an involved process, since the new automatic spec publication mechanism (which we haven't used yet for any of our specs) still doesn't support multi-chapter specs. There is a bunch of information at http://services.w3.org/xslt?xmlfile=http://www.w3.org/2005/08/01-transitions2015.html&xslfile=http://www.w3.org/2005/08/transitions2015.xsl and http://www.w3.org/2005/07/pubrules that describes how to get publications ready. While I generally do all of the things required by the Document Contact, I don't have access to upload things directly to www.w3.org/TR/, so I usually just zip up the document files like http://mcc.id.au/temp/WD-SVG2-20150915.zip and include a link to that in my mail to the webmaster.
  • In terms of turning the ED into something publishable, it's a matter of:
    • changing the <maturity> to WD in publish.xml
    • uncommenting the <publication-date> and putting the target publication date in there
    • updating the dates in the <versions> for the soon-to-be-published date and the soon-to-be-the-previous-version date
    • updating the link in changes.html to what will become the previous draft
    • changing all class="ready-for-wg-review" to class="ready-for-wider-review" in the document (as in theory each time we resolve *to publish we're resolving on those yellow sections being ready)
    • checking through the commit log to see if anyone's missed any changes.html entries, and adding them
    • building the spec
    • uploading the spec somewhere so that you can run the pubrules checker and the link checker on it, and fixing any issues it brings up (this is a tedious process that takes hours of my time, unfortunately, although with the spec linter that runs there are far fewer broken links these days); I usually just run the checkers on the single page version, rather than rely on the checkers recursing down to the chapters properly
    • once you have a final built spec, copying the contents of build/publish/ to a directory named WD-SVG2-yyyymmdd/ and then zipping up that directory to give to the webmaster
  • once the publication has been done:
    • change the <maturity> back
    • comment out the <publication-date>
    • remove all of the class="added-since-last-wd"s in changes.html

Topic database

Tools

  • There are obviously a bunch of tools that I'm either still running or have knowledge of (like the build scripts/system). I will keep those running -- any questions or bugs let me know.