Re: SVG working group mailing lists

Hi Amelia.

(re-arranging your points to deal with email vs. GitHub first)

On 13-Dec-17 14:45, Amelia Bellamy-Royds wrote:
> According to the charter 
> <>, www-svg and 
> GitHub should be the primary means of all group work.

Yes (and I wrote most of the charter). One of the comments we got in the 
various rechartering rounds was to use a workflow like the CSS group.

Of those, GitHub should be the primary method. This is based n 
experience with CSS, where previously www-style was the main means and 
was a total firehose of information. It totally put people off from 
commenting who were interested in just a few issues, and it was a pain 
to find and track down every comment made on a given subject.

We then switched to GitHub, which has made issue tracking vastly easier. 
People can comment on a few issues, bookmark those issue pages, and just 
track those. Editors can use filtering based on tags to see what issues 
are on their specs and to do dispositions of comments.

www-style is still used, but not that often. The weekly agenda is sent 

There is also a member-only list, which is lightly used for things like 
sending regrets, f2f meeting arranging, and so on.

> As the working group gets running again with different administration, 
> there seems to be confusion about all the different SVG-related W3C 
> mailing lists.
> This is the purpose of the mailing lists as I understand them:
>   * www-svg <> is the
>     public list for discussing anything related to SVG
>     standardization; anyone can sign up, and anyone can post, but we
>     now encourage most discussion of specific proposals/spec issues to
>     happen via GitHub issues <>, so
>     this list is more for meta-discussion and planning.
Yes. Publicly archived and anyone can post, so good for sending agenda 
and minutes. Substantive discussion should be on the appropriate GH issue.
>   * public-svg-issues
>     <> is a
>     mailing list that sends out notifications for all GitHub issue
>     discussion, to create a permanent W3C-hosted archive of the GitHub
>     discussion; I think anyone can subscribe to it (as an alternative
>     to watching the GitHub repo), but it's not for posting.
Yes. This is primarily as a back-up of last resort if the GitHub 
organization goes away. git is a distributed version control system, but 
all the value-add is in the issues and those are not in git. So we need 
an archive of them.
>   * public-svg-wg
>     <> is a
>     publicly visible mailing list for discussing working
>     group-specific business. It should be used for discussing
>     scheduling and administrative details that wouldn't normally be of
>     interest to people not active in the working group (but it's still
>     publicly visible, because the SVG working group is supposed to
>     work in public).  It should not be used for anything about SVG
>     itself (use GitHub or www-svg), or for anything that is confidential.
Correct. Publicly archived but restricted to people in the database of 
SVG WG members.
>   * team-svg is a new-to-me list;
It has been around for some years, but most people don't need to use it. 
W3C has a bunch of these lists; they have the chair or co-chairs and the 
team contact or team contacts.
>   * I think it goes to the chairs and staff contacts, but if anyone
>     else sends a message to this address they get a bounce warning
>     about not being subscribed & their sent email being held for
>     moderation.  (I like the idea of having a single point of contact
>     for the chair(s) and staff contacts, but it would be nice to
>     suppress that warning email.)  I don't know if the archived list
>     is available to other W3C members; it's certainly not visible to me.
There is an archive and it is team-only.
>   * Liam mentioned on the call last week that he was going to look
>     into setting up a private mailing list that would be visible to
>     all participants of the working group (including Invited Experts),
>     for doing things like sending out WebEx passwords or other
>     confidential contact information.
I don't think that is needed, myself. A page with access control set to 
team+SVG WG members can be set up for that sort of thing.
> Minutes for teleconferences should be made public, and following 
> practice that means that a notice with a link to the minutes is sent 
> to www-svg.  In past we've also copied the text-formatted minutes into 
> the body of the email, to make it easier to find in the mailing list 
> archive. I don't know if that's as important now.

The text formatted thing was because the old Tracker system could only 
read plain text email body, not follow links or understand attachments. 
Nowadays, just a link to the minutes is fine.

> I think we're set up to use the new GitHub bot 
> <> 
> to copy relevant sections of minutes into GitHub issues, which 
> provides a more useful record than the email archive. (We'll need to 
> test it out next time we actually discuss a specific issue.)
Yes, that is a fairly new and super useful feature. David Baron wrote it 
(to learn Rust). It means that the relevant minutes discussion on each 
issue ends up in the actual issue, which is where it belongs.
> I'd also recommend sending out announcements of future telcons and 
> requests for agenda items to www-svg, so members of the public can 
> know when it's important to get their comments in before a discussion.
Yes, absolutely. And those should be 2 or 3 days in advance, so people 
have time to prepare/read up and so we know in time if someone critical 
to a given topic can't make the call that week.
> More mundane scheduling discussion and "regrets" should probably be 
> sent to public-svg-wg.  This means that telcon announcements should 
> probably be sent to /both/ lists, so that you can reply to either 
> depending on whether it is a substantive matter about the agenda 
> (www-svg) or a scheduling and logistics matter (public-svg-wg).

Hmm, maybe.

> Private mailing lists should only be used when absolutely required.

If you mean team-svg, then yes, it is only used when required. For 
things like 'hey, you didn't send out an agenda, don't forget' or 
'co-chair A can't make date X, checking co-chair Y can cover that week' 
or 'hey guys, remind me where the documentation is for updated Candidate 
Recommendation with substantive changes'.

In general is is for the chairs and staff contacts to talk, WG members 
should not need to post to this.

> Any concerns with the definitions and divisions I've given here?

Chris Lilley
Technical Director @ W3C
W3C Strategy Team, Core Web Design
W3C Architecture & Technology Team, Core Web & Media

Received on Thursday, 14 December 2017 15:14:09 UTC