- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Wed, 03 Oct 2012 00:11:53 +0100
- To: public-coremob@w3.org
Hi, During our F2F meeting today, I mentioned that the current organization of coremob-2012 by spec was creating problems that I think we could avoid by instead taking a per-feature approach (I have some experience with this based on the work I've done for the roadmap document). A per-feature approach would in particular avoid the issues we've hit in reviewing the current editors draft where some sections are about a given spec (even if the spec covers a lot more than what we actually require), some others are about hypothetical specs, and others again are about a potential spec on which we have doubts. To give a bit more flesh to what I have in mind, I think that for each feature that has been identified as an important enabler for mobile web apps development we should establish what needs to happen before it is indeed available. In many cases, this would lead to specific action items that hopefully members of this group would be ready to take on. In particular, I think the following decision process might be applied to each feature: * identify whether there are specifications that allow to provide the said feature ** if no specification provide the said feature, the action plan should be to refine the requirements for the said feature, find a candidate Working Group for the said feature or try to gather momentum around the creation of a new one, and push for raising the priority to work on the said new spec ** if a specification exists for the said feature *** if it doesn't match the requirements we have identified for the said feature, the action plan should be to refine the requirements we have, advocate them to the relevant working group, and try to push the said group to raise priority on fixing the spec *** if it matches requirements but is not gaining much traction in terms of implementations, the action plan should be to get views from implementors on where they stand on the proposed spec to understand whether they don't like the approach, or whether they don't think this is a priority; further action would be defined depending on the outcome of that investigation *** if it matches requirements, is being implemented, but the implementations are not functional (either because they're buggy, or because their performance are too poor), the action plan would be to investigate the source of these problems, and either use a "name-and-shame" approach, or circle back to the spec if that is deemed to be the problem *** if it matches requirements, is implemented and has functional implementations, declare victory! and simply reference the relevant spec We could also usefully include a step in that process to search for existing test cases, and even include "provide new test cases" as part of an action plan. We could also include in that action plan the push for modularizing specs in ways that make our references to them (and implicitly, our reliance on the implementation the relevant stuff) more logical, easier to track and to test. But I think the steps I identify above are already quite a bit of work to push through, so I would probably leave the others to a later phase. Note that ideally the analysis of whether the specs match our identified requirements would be done formally by reference to our would-be use cases and requirements document, but I think we can also get a first good approximation without that formalism, and thus keep the two work items progressing in parallel. Dom
Received on Tuesday, 2 October 2012 23:12:22 UTC