- From: Robin Berjon <robin@berjon.com>
- Date: Wed, 12 Nov 2008 14:13:13 +0100
- To: Jose M. Alonso <josema@w3.org>
- Cc: Kjetil Kjernsmo <Kjetil.Kjernsmo@computas.com>, eGov IG <public-egov-ig@w3.org>, Steinar Skagemo <sskagemo@gmail.com>, Kjetil Helberg <kjetil@helberg.no>, John Sheridan <John.Sheridan@nationalarchives.gov.uk>, Kevin Novak <kevinnovak@aia.org>
On Nov 12, 2008, at 13:46 , Jose M. Alonso wrote:
> El 12/11/2008, a las 10:29, Kjetil Kjernsmo escribió:
>> This also implies that some distillation is needed, that Use Cases
>> admitted to
>> the note are issues where IG members find common ground, unless one
>> member is
>> deeply committed to something that other members also find
>> interesting but is
>> not assigning resources to.
>
> Do you have an opinion on how we should conduct this process? Would
> you choose out of the ones in the wiki or would you try to identify
> overlap and develop more generic ones based on those for the Note?
One issue here is goodwill creep. Use cases and requirements work
often sees people violently agreeing that this or that use case would
be absolutely wonderful to address, but when time comes to actually do
something about it no one is willing to commit the resources to do so.
I'm not pointing fingers here, I myself am finding it difficult to
find the time to participate in the IG, and couldn't even make it to
the f2f even though I was on site. The idea is simply to avoid wasting
too much time discussing things that will get dropped because no one
will work on them.
One potential way of addressing this, which will be familiar to some
of you, is to distribute beans around. Each participant gets a certain
number of beans (say five) that they can use to support use cases.
They can give all their beans to one, or they can spread them out.
Only use cases that get a certain proportion of the beans get to go
into the Note. This can be kept simple, or made more complex (people
get extra beans for putting in editing work, lose some for not
attending meetings) and will never be absolutely perfect (which is
where chairs can step in ex machina) but it has two advantages: 1) it
encourages people to merge use cases that are similar since that
increases their viability; and 2) it forces people to put their mouths
where the beans are rather than gleefully supporting everything that
sounds nice. The implementation isn't necessarily complex, a wiki or
someone with a spreadsheet can suffice.
I'm not entirely convinced that we're at a stage at which we
absolutely need such a mechanism, but since we're looking at a
distillation and filtering process I thought I'd point out this
option. In general my experience is that anything that can help reduce
use cases creep early helps a lot down the line.
--
Robin Berjon - http://berjon.com/
Feel like hiring me? Go to http://robineko.com/
Received on Wednesday, 12 November 2008 13:13:52 UTC