Personal observations of working group style and process

All,

I have repeatedly noticed that my position on various issues seems to be out of 
step with that of other active WG members.  I have found this is slightly 
surprising, as I don't see any fundamental respect in which our goals and aims 
are different.  It's more a matter of style and approach.

I thought it might be worth surfacing how I think this affects our discussions. 
  I must make it very clear that what I write here is not in any way critical of 
any other people's approach, just trying to understand our differences.  I 
particular, I fully support the chairs' desire and approach to address the 
issues in terms of concrete small pieces on which we can (or should be able to) 
make progress.

In responding to Luc's recent comments about the proposals for access and query, 
I realized that what I'm proposing as a broad approach looks very like an Agile 
Methods style of working.  By contrast, the groups approach seems more like a 
waterfall style:  define the entire problem space, then work on the designs for 
solutions.  But this is an exercise in standards creation, not software 
development, so it's interesting to consider if this distinction is applicable. 
  On reflection, and considering my past experience in standards work, I find my 
personal view is that an agile mindset is actually more relevant to standards 
creation than it is to software development.

So what do I mean by "Agile" here?  I mean a process that proceeds in multiple 
incremental cycles, delivering complete end-to-end solutions in small 
increments, with reflection and review of each such deliverable.  In the context 
of what we do, I'd like to identify a simplest possible solution that deals with 
a majority (or significant minority) of requirements, document that, review it 
to identify errors and omissions, and iterate.

What I perceive the group currently trying to do is construct language in order 
to define the complete problem space.  This is to my mind more of a "waterfall" 
approach, which IMO is leading to a "bikeshedding" effect 
[http://en.wikipedia.org/wiki/Parkinson's_Law_of_Triviality], in which we 
discuss details of word meanings rather than grasp the main problems (no less 
myself than any others).

We have agreed to be driven by user scenarios, which is a Good Thing, but I 
think something is missing in that process: prioritization.  We have agreed some 
scenarios, but what we have not done is highlighted some simple features in 
those scenarios that would, if implemented, have the greatest beneficial impact 
on users who want to capture and use provenance information.  For my proposals, 
I have done this implicitly by assuming what I perceive to be a common style of 
web interaction, focusing on small changes that augment existing practices.  I 
recognize this not the same thing as prioritization of user desiderata, but in 
the absence of real user input it's the best I can think of.  (And I do not 
count the scenarios as real user input here.)

I hate to articulate a problem without at least attempting a solution.  So 
here's what I'm thinking:

If we can quickly pull together the simplest possible set of specification 
drafts that we can possibly imagine as addressing at least some of our goals, we 
can publish them and solicit feedback.  That way, we stand a chance of learning 
what we're missing that other people really want.  By keeping the drafts really 
simple, we minimize the risk of describing something that no user really wants 
(and in the same stroke, we maximize the chance of their being read and actually 
getting feedback).  Then iterate.

...

In conclusion, I would suggest a possible goal for the F2F might be to identify 
a *minimal* set of technical requirements upon which we can agree to focus our 
efforts make progress.

#g

Received on Monday, 20 June 2011 10:12:29 UTC