From Open Friendly To Open Habits
Almost three years ago, after I’d been elected, but before I officially started my term, I started the Advisory Board’s public wiki page:
In that time the page has grown, had sections moved around, but in general is being edited by nearly every member of the AB. In three years we have achieved a new level of acceptance of opennness in the AB. I would say the AB is now both as individuals, and as a whole, "open friendly", that is, friendly and supportive of being open.
That being said I’m still doing much more editing than others, which is not by design but by habit and necessity.
On any given discussion it still takes some careful thinking on the part of the AB about if we can make the discussion public, how should we make it public, what is a good summary, etc. There’s rarely any obvious answers here, so the only way to get better at it is by practicing, so we practice in meetings, discuss / decide how to openly communicate, repeat.
My role is still very much one of taking the initiative and encouraging such open documentation (sometimes doing it too).
My goal for the next period is to effect cultural transfer so that I’m no longer doing more/most of the edits on our open wiki page, and instead have us all collectively reminding each other to publicly document decisions, priorities, summaries.
My goal is to eliminate my specific role in this regard. So that it just becomes accepted as the way the AB works, as a habit, both as individuals, and as a whole.
I don’t know if such a cultural change is possible in two years time, but I think we have to try.
Open Priorities
Any group of people with as broad a mission as the AB can potentially spend their time on any number of things. To both operate more affectively as a board (not just a set of elected individuals), and to help the broader W3C community provide us feedback, we publish our priorities openly, as we re-evaluate them annually (potentially semi-annually with new members joining in June / July)
https://www.w3.org/wiki/AB#Priorities_2016
I think this is pretty important as it communicates what is it that we, the AB as a whole think is most important to work on, and with our initials, what we as individuals feel we can most effectively contribute to.
I am going to touch on the few that I see as both important for the AB, and areas that I am bringing my personal skills and experience to help solve:
Maintenance
Maintenance is about how specifications are maintained, making sure they are, and frankly, obsoleting dead specs. It is perhaps the most important longterm priority for W3C.
This gets at the heart of one of the biggest philosophical disagreements in modern specification development.
Whether to have "living" specifications that you can depend on to always be updated, but you’re not sure what parts are stable, or to have "stable" specifications that you can depend on to not change from underneath you, but not be sure if are seeing the latest errata, the latest fixes incorporated.
Or worse, a stable specification which "those in the know" know to ignore because it’s been abandoned, but which a new developer (market entrant) does not know, wastes time trying to implement, and then eventually gets frustrated with W3C or standards as a whole because of the time they wasted.
Right now there are unmaintained specifications on the W3C’s Technical Reports (TR) page. And there are also obsolete specifications as well. Can you tell quickly which are which? I doubt anyone can. This is a problem. We have to fix this.
Best practices for new specifications
Best practices for rec track. Yes we have a maintenance problem we need to fix, but that’s only half the equation, the other half is getting better at producing maintainable specifications, that hopefully we won’t have to obsolete!
The biggest change happening here at W3C, instigated and promoted by many of us on the AB, is a focus on incubating ideas and proposals before actually working on them in a working group.
This incubation approach is fairly new to W3C, and frankly, to standards organizations as a whole.
It completely changes the political dynamic from, trusting a bunch of authoritative individuals to come up with the right ideas, design etc. a priori and via discussion, compromise, consensus, to instead forcing some amount of early implementation testing, filtering, feedback, iteration.
The reality is that this is a huge philosophical change, and frankly a huge shift in the balance of power & influence of the participants, from academics to engineers, from architects to hackers. So if you were an idealist academic that had a perfect design that you thought everyone should just implement, you’re going to find yourself facing more challenges, which may be frustrating. Similarly if you were a high level enterprise architect, used to commanding whole teams of people to implement your top-down designs.
Incubation shifts power to builders, to implementers, and this is seen as a good thing, because if you cannot convince someone (including yourself and your time) to implement something, even partially, to start with, you should probably reconsider whether it is worth implementing, its use-cases, etc.
By prototyping ideas early, we can debunk bad (e.g. excessively complex) ideas more quickly. By applying the time costs of implementation, we quickly confront the reality that no feature is free, nothing should be included for completeness sake. Everything has a cost, and thus must provide obvious user-value.
Incubation works not only to double-check ideas, but to also provide secondary, tertiary perspectives that help chisel away inessential aspects of a feature, an idea. Aspects that might otherwise be far too easy to include, for politeness sake by those seeking consensus at the cost of avoiding essential conflict and debate.
I bring a particularly strong perspective to the incubation discussions, and that is from my experience with IndieWebCamp where not only do we strongly encourage such incubation of any idea, we require it by the person proposing the idea! And not just in a library, but deployed on their personal website as part of their identity online. We call this practice selfdogfooding, and it has helped reduce and minimize many a feature, or whole specifications.
Security
Lastly but perhaps most user-visible, security (and privacy), in particular fear of losing either, is perhaps the number one user-visible challenge to the open web. Articles like this one are being written fairly frequently:
Privacy Concerns Curb Online Commerce, Communication
Some of this is perception, some of it as a result of nearly monthly "data breaches" of major web site / data silos, and others from fears of mass involuntary surveillance, from both governements, and private corporations seeking to use any information to better target their advertisements.
The key aspects we can work on and improve at W3C are related to the very specifications we design. We can, at a minimum work to minimize possible security threats from new features or specifications. On the up side, we can promote specifications that provide better security than previous works. There’s lots to do here, and lots of groups are working on various aspects of security at W3C, including the W3C Technical Architecture Group (TAG).
The AB’s role in security is to help these groups both coordinate, share approaches, and to provide encouragements in W3C processes to promote awareness and consdieration of security across the entire web platform.
Looking Forward
That is a lot to work on, and those are only three of the W3C AB’s priorities for 2016. I hope to continue working on them, and help make a difference in each over the next two years.
Thanks for your all your feedback and support. Let’s keep making the open web the best platform the world has ever seen.
Update: 2016-06-01
Update: I’ve been re-elected to the AB for another two years, starting 2016-07-01. Congrats to my fellow elected AB members!
View
on Twitter