Last week following in tradition, TAG had an unofficial teleconference introducing old and new members and discussing the future and focus of TAG itself. During this discussion (and prior to the election) the idea of bringing TAG closer to/making it more known in and relevant to the development community was raised (and seemingly supported by the co-chair). Given this, I have offered the input of one developer (me) and expand on some of those points and their relevance here for anyone who cares to understand why I think these are important or relevant.
Read “build concensus” in the charter as “in the larger community”
Convince us. Get us interested, excited and involved. Given it’s very small size and makeup it provides (or can provide) a unique bully pulpit that has been under-utilized. One of the few things explicitly within TAG’s charter is to build consensus and I think that that has to read (though it seems to historically not been read as) as within the larger community.
Foster a More Direct Relationship With The Community
In order to use the bully pulpit, first people have to care. Most developers didn’t even know that TAG existed until very recently. The connections/credentials that the newly elected members have in the developer community is just one reason I actively campaigned on their behalf. TAG members should hear, if not experience first hand, the pain and feedback that comes from the wider development community. We don’t ask that they solve each issue, merely that we feel that they understand them and aren’t off in an ivory tower somewhere saying “Let them eat cake” while we all starve.
A more public presence of TAG / members
One of the most interesting and effective things to happen in semantic web, in my opinion, was when TimBL did a couple of Ted Talks. We need representatives that lots of people are willing to listen to, and I think we’ve just elected some good ones. I for one would love to see blogs and talks by members (taking their TAG hats off if necessary) just to let people know that they are out there, involved and thinking deeply about significant issues whether those issues necessarily get picked up and addressed formally by TAG or not.
Back in the late 1990’s and early 2000’s TimBL wrote a series of thoughts on design issues (http://www.w3.org/DesignIssues) including one that I love called “The Evolution of a Specification” (http://www.w3.org/DesignIssues/Evolution.html) which contains a lot of great insights and thoughts. With a decade and a half in retrospect, I’d love to hear updated thoughts from him and others.
Consider how W3C process/policy affect long term health
Noah (the TAG co-chair) said, “The TAG’s charter is to focus on the long-term architectural viability of the Web, but we need to do a much better job of having impact year-by-year. My perception is that these goals are sometimes in tension. How do we help a community that’s implementing “early and often” to also build an architecture that’s clean and will scale for decades?”
Historically within W3C at at large it does seem that those two things are often (maybe always) tension, but it doesn’t seem that they inherently need be and I think that that is something I would love to see TAG discuss. A healthy architecture requires a system/processes that promotes health and I feel that there is currently a lot that doesn’t.
An inordinate amount of fuss and time and energy is spent at what really amounts to bike-shedding and formalities that are taken because of some other obscure formality which – at the end of the day, to many of us it seems at best silly and at worst confusing. I’d like to see TAG comment on whether fixing some of this is actually part of creating a stable and healthy architecture – I think it is.
I think that you can sum up a lot of my thoughts on this as: Paving cowpaths implies that cowpaths can be created in the first place and really, they often can’t, and I think that is unhealthy and leads to an inordinate amount of missteps.
Layers, layers, layers
If TAG deals with helping to create layers and fundamental principles that allow, maybe even encourage evolution, then it’s work (and W3C’s) will be relevant for decades to come, and we will be able to collect data to show it. Even if certain layers are improved or replaced, we will no more mourn them than we do the loss of manual typesetting when we read a book.
What we can learn from phone numbers?
The co-chair also cited the phone number system created 90+ years ago as example of something that has stood the test of time and a kind of model of what TAG needs to do as one of its larger goals “… part of the TAGs role is to help the community build a Web that will be viable in growing in 50 years, and maybe 100.”
Here are what lessons I think are worth drawing from that:
- Like much of the success of the early Web it’s success appears to be largely because it is really about a targeted and small thing that wasn’t necessarily technically the best – it was the best that they could sell.
- The inventors never imagined, or tried to imagine, all of the myriad of things that telephone numbers would be used for 50 and 100 years out – and if they had, you can bet they would have missed the mark substantially.
- While it was created in 1923, it wasn’t really the world-wide standard until it beat out all of the competition much later. It is entirely plausible that in the intervening years something better could have come along and displaced it.
- It was decoupled from the larger system enough in design to allow that phones, transmission lines, and wholly new ideas using this infrastrucuture could all evolve more or less independently.
I am earnestly looking forward to hearing/reading more from this group and hope that other voices in the community (like you?) will contribute to the conversations and help make our collective future a better place.
briankardell 