Re: Personal observations of working group style and process

Graham,

I realise this is a matter for the WG chairs, but your arguments seem
to affect what the access and query task force does for the F2F
meeting, and understanding concretely what you mean might help clarify
how to resolve the technical differences.

If I understand correctly, in the current ('waterfall') approach we
try to establish agreed principles which cover all cases and gradually
build up a specification, for example "the thing you ask the
provenance of may be mutable", "there can be multiple sources of
provenance data regarding a single thing" etc.

In an agile approach, we would give a complete solution to a tiny case
using existing standards, then adapt the solution to cover more cases.
So we might start with:
  "A webpage downloaded from HTTP URI X has provenance HTTP URI P,
which when dereferenced returns an OPMV/Turtle file. The OPMV graph
includes an artifact labelled opm:pname=X, i.e. the graph says
something about X's provenance. P is included as link somewhere on the
webpage in a manner which implies it is for the page's provenance."
We would then adapt the solution when we find cases where X is
something mutable, there are multiple providers of data on X's
provenance, we want software not people to follow the link to the
provenance, etc.

Is that what you were arguing for/against?

I am not taking a position, just trying to understand better, as I
have not been involved in a standardisation process before.

Thanks,
Simon

On 20 June 2011 11:13, Graham Klyne <graham.klyne@zoo.ox.ac.uk> wrote:
> 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
>
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email
> ______________________________________________________________________
>



-- 
Dr Simon Miles
Lecturer, Department of Informatics
Kings College London, WC2R 2LS, UK
+44 (0)20 7848 1166

Received on Thursday, 23 June 2011 09:55:56 UTC