Draft SVG Community Group charter for discussion

Welcome to the SVG Community Group!

But what does that mean? What is the group supposed to do? How will it work? Who gets to decide?

A group charter answers these questions. As your chair (for now, anyway) I’ve written up a draft charter for the group, which you can read at: https://w3c.github.io/charter-drafts/svgcg-2019.html

But that’s just my take. I hope to receive comments and suggestions about the charter from both experienced W3C folks and from community members who have signed up to be part of the group.

Please post feedback as GitHub issues (using the tag [svgcg-2019] in the issue title), so we can have all the comments in one place. If you’re not yet on GitHub, this would be a good time to set up an account — we’re planning to use it for all community group work

The draft charter is based on the W3C charter template for community groups. The template ensures that our charter works with the
 Community and Business Group process and contributor agreements that govern all W3C community groups. If you want to see all the changes that have been made, compared to the template, use this diff against the initial commit.

The draft charter also incorporates some of the discussion we’ve had in the SVG working group, where the original plan for the community group began.

The rest of this post summarizes some of the reasons behind the charter. It will hopefully answer some questions before they are asked.

Why have a SVG community group at all?

In the SVG working group, we know that many people who care about SVG get frustrated with us. Development of the SVG specification is too slow. Or maybe we’re working on projects that are less important to you. Wouldn’t it be better if you could just jump in and show us how things should be done?

But in the past, when people have made proposals for SVG outside the working group, those proposals have remained isolated. People working on similar ideas don’t know about each other. Other people don’t want to waste their time working on an idea without “official” support. And without an organized record of these proposals, they can get lost as people move onto other projects.

Even when new features have made it into a draft SVG standard, that’s been no guarantee. Major features have been dropped or overhauled because the web browser teams weren’t implementing them, and we want the SVG standard to reflect features that people can actually use in browsers.

The working group itself has no power to order software developers to support a proposal — we need to convince them. And the most convincing argument is a large group of people demanding support. Which means official proposals with examples & software tools to support them, so that other developers can try it out.

In the past few years, the SVG working group has narrowed its focus to only features that already have existing or planned implementations from the teams that make web. That way, we can focus our work where it will make the most difference. And we won’t disappoint people by announcing a new SVG feature and then pulling it back. But if we’re only focused on ideas which already have support, where do new ideas come from?

That’s what the community group is for. To explore new ideas related to SVG, test them out, get people excited about them, debate over how they should work in their details, and in general: create a convincing package that SVG needs this new feature.

Why not use WICG?

The Web Platform Incubator Community Group, WICG, has many of the same goals as the SVG CG. It’s designed to make it easy for people to propose new specifications — without having to create a separate working group for each proposal — and with guidance and support from people with experience in web standards.

But WICG is only for new web platform specifications, which means it isn’t a perfect fit for SVG. Many uses of SVG aren’t about web browsers! And many of the SVG-related projects we’d like to support aren’t new specifications — they are software and tools, or best practices guides, or many other things. (Check out the Deliverables section of the proposed charter for some ideas.)

Of course, if you have an idea for a specification that is related both to SVG and to the web platform in general, you could still work within WICG to develop it. But in the SVG community group, hopefully there will be more SVG experts to offer feedback on your idea.

Why do we have to use GitHub?

Switching from email lists to GitHub for discussion has been a huge help for those of us working on web standards. With a proper issue tracker, you can make sure that brilliant ideas or serious concerns don’t get lost over time. And having the issue tracker integrated with the source code makes it easier to connect the changes that are made with the discussion that led to them.

Yes, there are other services that host code repositories and issue trackers in one place. But GitHub is used by the W3C, the SVG working group and other web standards groups, so it makes it easier to coordinate.

Can I create a project for my Super SVG Idea?

That’s the plan! We still need to set up the organizational details, but the intention is that it will be easy for anyone to create a community group project. It has to be about SVG, it can’t directly overlap standards being developed in the working group, and you need to make the relevant licensing agreements. But beyond that, your imagination is the limit.

Or at least, that’s how I see it. Remember, this is a draft charter — if you think we should be more picky about what gets to become a SVG community group project, you can always file an issue!