RE: Organizing Coremob-2012 per feature

Dominique, all,

This is a great suggestion. IMHO the value of an independent CG specification is unclear to me. Ultimately, I would rather see high quality and  implemented WG specifications than a high quality CG specification that is not referential.  So if I may summarise:

Minimum identify, Maximum provide full solution:

a) Present and emerging  spec features that are poorly implemented because they have not been well specified
b) Features that  should be specified but aren't

best

Vidhya
> -----Original Message-----
> From: Dominique Hazael-Massieux [mailto:dom@w3.org]
> Sent: 03 October 2012 00:12
> To: public-coremob@w3.org
> Subject: Organizing Coremob-2012 per feature
> 
> 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 Wednesday, 3 October 2012 10:41:51 UTC