- From: Robin Berjon <robin@robineko.com>
- Date: Tue, 13 Oct 2009 17:07:08 +0200
- To: David Rogers <david.rogers@omtp.org>
- Cc: public-device-apis@w3.org
Hi, On Oct 9, 2009, at 16:24 , David Rogers wrote: > Chairs, please could you give some direction on the next steps? I'm > concerned that a lot of parallel activities are going to start, then > stall. I'm not a big fan of top-down prioritisation. Consider the case in which the WG decides (all other things being equal) to prioritise APIs for Unicorn Control and Pony Training, but there's a smaller handful of people who are only (or mostly) interested in the Shiny Donkey API. It seems unproductive to keep them from working on it. We have tools to deal with that. First of all we can simply let that group work on it, conducting its business on list, and taking a slice (but not the majority) of the agenda. If it stalls, the WG can either decide that it was a good idea to prioritise it anyway and redeploy resources, or figure out that we'll get to it as originally planned. If the volume of work on Shiny Donkey becomes overwhelming, then obviously it's not stalling, but we can run into a situation in which it is taking too much of the WG's bandwidth. For that we have Task Forces, which we (the chairs) can charter at will. TFs can have their own phone (and even f2f) meetings, their own list, their own (informal, delegated) chairs. It's not ideal in that it tends to split the WG somewhat, but sometimes WGs are split de facto, and since the situation has cropped up before there is a body of experience in handling it. What concerns me is that we seem to be spending more time going meta than actually putting MUSTs and NOTs into HTML specifications. I think I would summarise the direction in which I'd like us to go as follows: - The WG has a scope, outlined in the charter, outside of which we won't go. - The WG has priorities, but won't stand in the way of people wanting to get work done. - v1 specifications need to be as simple as they can be, and v2 needs to be thought about. - People need to have read http://www.w3.org/TR/html-design-principles/ - In addition, Java has very clearly demonstrated that theoretical straightjackets don't produce quality APIs. Primary concerns in API design (in addition to those listed in the HTML DP) are therefore: . Vernacular (grown around usage) . Idiomatic (fits in the language and the way in which it is used) . Ergonomic (looking at it should tell me what it does, i.e. unlike Node.insertBefore()) - Consistency is less important than the three previous aspects, but usually flows from applying them. Finally, code speaks louder than words and solutions louder than principles. We can agree on a zillion and one a priori top-down ways in which work should be conducted, if six months down the line we have the choice between a solution that sticks to them, and a better solution that breaks them, we'll have no option other than to break them. So, given that we're aware of all the exiting input, why not just build the good solution based on that experience that we're chartered to build? The CVS repository is open to all WG participants, and HTML is reasonably straightforward to handle (at least, it should be for people working in this WG!). People are always welcome as editors, and editors are always welcome to dump their brains in there so that we can pick them apart. -- Robin Berjon robineko — setting new standards http://robineko.com/
Received on Tuesday, 13 October 2009 15:07:39 UTC