DevRel and the Web Education CG
A few people have asked me to provide some background for this community group, and to explain how it’s different than the Web Education CG. I’ll try to capture some of the motivation, background, and initial ideas behind this group.
Some of you may know that our new CEO, Jeff Jaffe, is serious about transforming W3C to meet the needs of the Web community and our membership, and has an ongoing series of blog posts about this. As part of this effort, W3C management (W3M) introduced a new program in 2012, called Headlights, in which the W3C staff proposes “big ideas” for W3C, including new ideas for standardization, a change in focus on existing efforts, or even new structures within W3C itself. All these ideas were discussed, and the ones that seemed most viable were selected for further development; we will flesh the selected ideas out with help from the community, prioritize them, and ultimately fund those which will give us the biggest bang for our buck. By May, we want to discuss them with our members more formally; by July, we want to finalize the proposals and pick the ones that we will commit to.
One of the Headlights proposals I made was to get serious about doing developer relations systematically at W3C. This ranges from bandaids like creating more attractive and compelling presentations and slide decks, to more serious efforts like giving Web practitioners a stronger voice in the development of standards, and improving the state of Web development education. This proposal, which I dubbed “Strategic developer relations”, made it into the second round, and as the project lead, I chose to create a community group to further explore the idea in public.
Why Developer Relations at W3C?
Why “developer relations”? Why not “developer outreach” or “evangelism”? And why a dedicated activity at W3C, rather than just relying on W3C’s members that already have DevRel departments (or the equivalents)?
I want to create a developer relations activity, specifically, because I feel like outreach and evangelism are too one-sided to solve the problems we have in standardization; I don’t want us to preach to a developer audience, I want us to work with developers to build the Web together. W3C staff doesn’t have all the answers, and we have a lot to learn from the wider community and from our members on how best to serve Web practitioners.
For example, I recently met up with Jon Williams, a local developer, who had made some comments about W3C process on Twitter (yes, I meet personally with everyone who comments about W3C on Twitter…). He had some insightful suggestions, including an idea to do a developer survey about identifying pain points in the Open Web Platform; we’ve done surveys before, and had thought about similar efforts, but the manner in which he presented the idea, and the way he tied it back to the excellent Web Design Survey by A List Apart while still dealing with standards, crystallized the idea for me and inspired me. I even spoke briefly to Jeffrey Zeldman and Eric Meyer about it at SXSW, and hope to talk to them more soon. This was a case where a smart Web developer not only knew what they wanted, but could outline a path to get there, and that kind of help is invaluable.
And it also explains why we would want a dedicated, systematic, direct approach to developer relations at W3C, rather than relying solely on our members. The kinds of issues and challenges W3C has are somewhat different than those of the software vendors and service providers that make up our membership, and might call for different questions and different answers.
And as with government, there should be a way for our constituents (in this case, developers and designers, rather than citizens) to speak directly with their own voice, not mediated and filtered by the market needs and preconceptions of the browser vendors and authoring tool makers. Even the developer relations folks in those companies confirm this when I talk to them. It’s like the game “Telephone”, where each person whispers the message to the next in the chain, until the message changes beyond recognition; a Web developer makes a request to a salesperson, who reports it to their manager, who turns it into a use case for the product development folks, who hand it to the software architects, who rework it for engineers to prototype, who bring it to W3C for standardization… by the time we see it, it may be a completely different idea, and may not meet the original need from the Web developer. It would be useful to also hear directly the original idea from that Web developer… there are a lot of creative individuals and teams out there, and we could use their suggestions and feedback.
What Would a W3C Developer Relations Activity Do?
That’s a great question. I have a few answers, but I’m also interested in hearing from the wider community, especially those of you who work in developer relations in your own organization.
I’ve spent almost 6 years at W3C trying to get more people at the table, soliciting more contributions to the standards, but very few people have the time, energy, or patience to get involved long-term, and many simply don’t have the interest; I understand this… they are trying to build something today, and while everyone knows that you should exercise and eat your vegetables, we don’t always do what’s good for us long-term when there are short-term problems to solve.
My current thinking is that if Muhammad won’t come to the mountain, then the mountain needs to be better distributed. We should find methods of participation that better fit the development cycle of real-world Web practitioners. Here are a few notions:
This Week in Standards: there are a few people out there blogging about what the current news is in their browser, or their Working Group, or in the Open Web Platform as a whole; we could be more systematic about this, to better communicate what is going on in standards, so that people can make an informed choice about what they will experiment with or use in production code, and to increase the accountability on different specifications.
Polyfill prototypes: when a specification is based on an experimental implementation in a browser, as with vendor-prefixed CSS extensions, designers and developers have a chance to kick the tires, to see what they like and don’t like about a proposal. In some cases, this can be done just as effectively with a polyfill—a Javascript library that emulates new browser functionality—and with less permanent implications. Creating a prototype implementation, even a rough one, also provides great insight into holes in the specification itself. A developer relations team might work with Working Groups to identify likely candidate specifications, and work with the community to create and distribute a polyfill, and bring the feedback back to the Working Group.
Scenario triage and advocacy: when you go to the doctor, the nurse is the one who collects your information, does some initial checks, and communicates this to the busy doctor and other staff; this saves everyone time. A developer relations team might do this first round of triage, serve as the go-to for developers and designers who have questions or suggestions, collect scenarios (e.g. use-cases), formulate requirements, investigate how widespread the support for the idea is, and represent the busy developers and designers on the appropriate Working Group for the most popular ideas, reporting back progress to the community.
Crowdsourcing testing: Everyone complains about how long it takes to finish a specification; at least months, and sometimes years. Implementations are a big part of that, but for the Working Group itself, testing is often (in my experience) a third to a half of the time and effort it takes to bring a spec to Recommendation status, and it’s often the part that gets put off the most… yet it’s the part that best insures interoperability from the start. A good developer knows how to write a minimal test case, and sometimes they even submit bug reports to their browser of choice (or the browser that’s given them the most trouble); how much more effective would it be to submit a single test to W3C’s test suites for a spec, so that it will be tested by every browser, not just one? If we put a crowdsourcing infrastructure in place, and 100 people write 2 tests each, and about 1/3 of those are good tests, that’s almost 70 tests… which may represent about 20–30% of the tests needed for a smaller specification. These are tests that the Working Group doesn’t have to write, so they can spend more time writing the specs, tests that the implementers don’t have to write so they can spend more time implementing features. Obviously, not every test is a good test or the right test, so we’d need to allow the public to also review tests (which is a lot of work itself) to separate the wheat from the chaff, but the potential for increasing the speed of standardization is enormous. And it directly in the best interest of developers and designers to help out in this way. A developer relations team could set up that infrastructure, and help coordinate it.
These are just a few ideas, and they may not even be what we end up with in the final proposal, but I hope it gives you some ideas of your own that you’ll share. Some other obvious things that we’ve already started, and which we can put more energy into, include holding conferences—like W3Conf 2012—or other events, and working closely with our members on specific promotional or educational efforts.
What About the Web Education Community Group?
The WebEd CG is focused specifically on one aspect of the larger challenge: creating and maintaining documentation on Web development and design, and more specifically, docs and other resources for educators and trainers to help teach the Open Web Platform (aka “HTML5”). It provides a home and a framework for Web practitioners to help themselves and help others.
This is a useful—and in my opinion, vital—project, but it’s only one part of what we could and should focus on with a developer relations activity, as you can see from some of the examples above.
What Will it Take?
Ideally, we would have some additional funding dedicated to this effort, including funds allocated to a dedicated staffer (planning W3Conf while still doing my regular staff contact duties was pretty grueling), and maybe even an additional new W3C staffer, and some travel and promotion budget. If we do our jobs right, the effort could pay for itself with revenue from conferences, events, sponsorships, and so on, but it will need to be bootstrapped to get it off the ground.
Creative thoughts about how to fund this, apart from W3C general coffers, would be most welcome.
Is this Definitely Going to Happen?
Nope. But you can help make it happen.
It’s an idea we’re exploring, and I personally believe strongly in it, but there are other potential projects, and only so much money to go around. If you think this is a good idea, please get involved and help us make this proposal as strong and compelling as possible, to clearly demonstrate the return on investment that this will make.
TL;DR
The DevRel CG is about next steps… not just the things we already know we need to do, and know how to do, and are doing, but finding and reifying new ways for W3C to become more relevant to everyday Web developers and designers.
