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 Tuesday, 2 October 2012 23:12:22 UTC