Fronteers and W3C - first quarterly report
Last week our W3C representative, Rachel Andrew, came to Amsterdam to talk about her W3C work and give an interesting workshop; essentially giving her first quarterly report. This post gives a quick overview based on the notes I took during the discussion.
Rachel first gave a presentation about the specifications W3C is currently working on. Then we seamlessly moved into a discussion of first the details of some specs, then the details of Fronteers' involvement in W3C, and finally the goals and expectations we at Fronteers have of our membership.
The audience loved the idea of a meet-up about upcoming specs, and about understanding those specs. The Friday workshop (see below) was also considered an excellent idea, and there was a clear demand for more of this sort of content, as well as blog posts. Web developers need more skills in understanding specifications.
So we're going to organise more meet-ups and workshops around W3C specifications. Subscribe to our Meetup channel to stay informed. (And don't be afraid of occasional Dutch texts; all W3C-themed activities will take place in English.)
Communications and discussions about our W3C membership take place on our Slack channel. Although most of our channels are in Dutch, the W3C channel is entirely in English. Rachel participates in the discussions as well. Non-members are explicitly invited to join - the more people we have, the better we can function.
We spent part of the time on outlining how our membership is going to work in practice.
Rachel will notify us of interesting upcoming specs, or important changes to existing ones. Also, she will spend time figuring out what's going on at W3C, and identifying issues that Fronteers should have an opinion on. Fronteers opinions count as web developers' opinions, and W3C loves feedback from the field. Therefore it could be that our opinions carry more weight than our formal vote would suggest.
We have one vote out of 451 at W3C. Rachel will cast that vote, but Fronteers members can instruct her how to cast our vote. The issue here is that there isn't all that much voting going on. Rachel is going to find out how much there actually is.
Occasionally there appears to be a vote in the Advisory Committee, where Rachel is our representative as well. The AC discusses policies for W3C as a whole, but the details are unclear at this moment. Fortunately there is a course for new AC members, and Rachel is going to participate. She'll likely have a better understanding of what the AC actually does after she's done.
W3C does not vote on specifications. Instead, it uses an objection-based system. That is, members can object to a spec, or even a feature. If that happens, the objections are discussed and resolved, if possible. If no one has objections (and that's usually the case), the spec moves on. Usually it's browser vendors that object.
Theoretically, Fronteers could raise objections. This is simultaneously a very powerful and a very annoying thing to do, and raising objections over minor issues will get you taken less seriously by other members. Therefore this should be an action of last resort, and not something to be used on a whim. Still, if the situation is just right, Rachel might use our objection to call for a pause in order to get more web developer feedback - but if she does so, we're supposed to deliver good, to-the-point, reality-grounded feedback.
Also, we might use our influence and the formal W3C procedures to stop one browser from being able to define how the web should be - if that should become necessary.
Other than supporting Rachel, Fronteers can do a few more quite important things. We need to gear up to fulfill our role as representatives of web developers. We need a larger cohort of people involved in the spec-creation process that Rachel can warn if something important is coming up. We also need to know what we're talking about, which means studying the specs. This, and not voting or raising objections, is the meat of our membership.
Another important issue is creating test cases and test suites. Theoretically, a specification is supposed to have a full test suite that browser vendors can use to test their implementation. In practice - not so much. The spec writers don't have a lot of time, and volunteers are hard to find because writing good tests is really really hard. (I should know; I've done it for fifteen years.) On tbe plus side, writing tests is an excellent way to really get to know a specification.
Workshop spec reading
On Friday, Rachel gave her first Spec Workshops, where we read the entire Multicol Editor's Draft and gave detailed feedback. (Note that the draft has already changed in order to accomodate part of what we discussed.)
This was very interesting, not only to us participants, but also to Rachel herself, whose attention was called to several problems she hadn't noted before; for instance with terminology, unclear sentences, wrong examples, and so on.
I didn't keep detailed notes during the workshop, so this brief summary will have to do. We did decide that this was definitely something we should repeat, since it yielded quite a bit of good, actionable feedback.
All in all Rachel's first quarterly report was a resounding success that gave us a lot of useful pointers for the next few months. Becoming an influential W3C member is going to be a lot of work, but we've done a tiny bit of that work last week.