Iteration 5 notes
Norman Gray
Folks,
I've put the notes from this week's iteration meeting onto the SKUA
wiki, at <http://code.google.com/p/skua/wiki/Iteration5>.
The plan now is that we aim for some first release just before the
Cambridge VOTech meeting, which is now two iterations, or four weeks,
away. The aim is that this release is something that can be talked
about at that meeting, and offered to sympathetic users, with the
expectation that they can do something basic with it, and so tell us
very clearly what's missing.
All the best,
Norman
--
Norman Gray : http://nxg.me.uk
Physics and Astronomy, University of Leicester
Ross Gardler
>
> Folks,
>
> I've put the notes from this week's iteration meeting onto the SKUA
> wiki, at <http://code.google.com/p/skua/wiki/Iteration5>.
>
> The plan now is that we aim for some first release just before the
> Cambridge VOTech meeting, which is now two iterations, or four weeks,
> away. The aim is that this release is something that can be talked
> about at that meeting, and offered to sympathetic users, with the
> expectation that they can do something basic with it, and so tell us
> very clearly what's missing.
This sounds fantastic. I hope this release will be something that a
potential evangelist (like me) can install quickly and easily.
I'd be happy to test the install instructions for you when the time comes.
(by the way, I have to congratulate you on the posting of iteration
details. I, as an interested bystander, am still largely clueless as to
what is actually going on - no use of the issue tracker, no SVN commits
and minimal public discussion - however, these iteration notes help me
keep abreast of the situation)
Ross
Norman Gray
Ross, hello.
On 2008 Aug 28, at 22:28, Ross Gardler wrote:
> This sounds fantastic. I hope this release will be something that a
> potential evangelist (like me) can install quickly and easily.
That's the idea. Recall that we're being all XP, here -- release
early -- so we're not promising it'll do a lot...
> (by the way, I have to congratulate you on the posting of iteration
> details. I, as an interested bystander, am still largely clueless as
> to
> what is actually going on - no use of the issue tracker, no SVN
> commits
> and minimal public discussion - however, these iteration notes help me
> keep abreast of the situation)
This, I suppose, is my cue for a brief recap of where we've got to,
methodologically.
Looking at the headings in <http://code.google.com/p/skua/wiki/Process>:
Customers: this remains slightly artificial for us. We have a couple
of folk targeted as potential users, and I'm making sure they're as
involved as possible, but they didn't _ask_ us to do this, and they're
not funded to spend time crafting UserStories, so there's a limit to
how much we can badger them, especially as we don't yet have anything
they can get immediate benefit from. That should change with this
first release. They've phoned in to a couple of the iteration
meetings, and even if they're not there, they're concrete enough to
shape discussion. So: XP-purity=3/5; usefulness=3/5 and rising.
User stories: still a little bit artificial. I do like the
concreteness of 'what functionality is this adding?', and the
refreshing clarity of 'YAGNI' as an answer. The artificiality comes
from the fact that most of the user stories we've implemented have
come from us, and represent infrastructural features that we've had to
twist somewhat into a 'story'. Presumably this will change as the
'customers' get more involved. XP-purity=3/5; usefulness=2/5 to 4/5,
depending on whom you talk to.
Iterations: This is a bit of a stretch, but I believe it's working
fairly neatly. Because our user stories are slightly artificial, and
partly because we're below the lower range of XP project sizes, we
haven't been able to perform the project-velocity calculation in any
real sense. Despite that, I think that the fortnightly meeting, and
its repeated questions (what did we do last iteration?; what are we
going to do in the next two weeks?) give useful reassurance that we
are making progress, and useful concreteness (that word again) to our
plans. XP-purity=4/5, usefulness=5/5.
Informative workplace: not really. The wiki's useful, of course, but
that's not really what this is supposed to refer to. We have the
'whiteboard' at <http://docs.google.com/Doc?id=dcvcvwqp_13cdsm6ch>,
and I've consistently used that to jot down the iteration meeting
notes, but we haven't see this actually used as a 'whiteboard' so
far. Suggestions are welcome. XP-purity=2/5; usefulness=1/5.
Stand-up meetings: OK, I think. We've been having brief skypecons, of
5-10 minutes, at noon about three days a week. We're falling into a
fairly regular pattern. I think this is useful, as a way of all of us
keeping up-to-date on things, and occasionally turning into a brief
discussion of what we should do next. I don't know if Kona and Tony
feel the same way about these. XP-purity=3/5; usefulness=3/5?
Thinking about the specific things you mentioned, I think the absence
of these is partly because we're using an XP-like methodology, rather
than a traditional distributed-OSS one.
> no use of the issue tracker
No, because we're talking to each other. As well as the skypecons,
we're usually on Jabber, so if there's a problem, we can usually sort
it out quickly using that. We haven't made a release yet, so there
aren't bugs from the field. Even after that, however, the bugs would
tend to come from the project 'customers', who would (we suppose, in
principle) raise them via user-stories, or by the (in principle) rich
set of intra-project channels that the methodology aims to set up. I
recall from somewhere in the Shore and Warden book a remark to the
effect that XP projects tended not to have big issue tracking systems.
Having said that, we do plan to make releases beyond the 'customers'
envisaged by XP, and we hope that these will be used by folk more
tangentially related to the project, and the most natural way for them
to feed back would be via the Google Code issue tracker. Thus I don't
plan to be dogmatic about our minimal use of it.
> and minimal public discussion
Not really. There's plenty of discussion in the noon meetings and
iteration meetings, which anyone can come along to -- they're public,
albeit synchronous and not archived. We use Jabber, too. Part of the
XP experiment has been to try to set up richer developer communication
channels, and force ourselves to use them. In consequence, there's no
real _need_ for us to discuss things on the mailing list. This means,
I suppose, that the skua-announce and skua-discuss lists have roughly
overlapping uses -- the function of both (as it turns out) is to pass
information to people with a more passive interest in the project,
rather than to thrash out issues.
Perhaps I should close down the skua-announce list and just use skua-
discuss for everything related to lists.
Separately:
> no SVN commits
Indeed -- I haven't set up a skua-commits list, because I didn't think
anyone would care enough to subscribe to it. The commit messages just
come to me, at present. If you, Ross, would subscribe to a skua-
commits list then I can set it up and advertise it.
Tony and Kona: do you have anything to add here? Does this match your
perception?
Ross Gardler
>
> Ross, hello.
>
> On 2008 Aug 28, at 22:28, Ross Gardler wrote:
>
>> This sounds fantastic. I hope this release will be something that a
>> potential evangelist (like me) can install quickly and easily.
>
> That's the idea. Recall that we're being all XP, here -- release
> early -- so we're not promising it'll do a lot...
Don't worry - we're speaking the same language. I look forward to
testing the install for you.
>> (by the way, I have to congratulate you on the posting of iteration
>> details. I, as an interested bystander, am still largely clueless as
>> to
>> what is actually going on - no use of the issue tracker, no SVN
>> commits
>> and minimal public discussion - however, these iteration notes help me
>> keep abreast of the situation)
>
> This, I suppose, is my cue for a brief recap of where we've got to,
> methodologically.
Thanks, this is really useful. As you know I have an interest from the
OSS Watch perspective, having you take the time to write this mail is
really useful for us.
I'm working on a SKUA case study and an XP/OpenDevelopment paper, that's
why I am watching and learning). I've commented extensively below as a
result this work and thought you may be interested in my thoughts.
Of course comment is welcome, or you can just do whatever you need to do
safe in the knowledge that I'm watching and learning ;-)
> Looking at the headings in <http://code.google.com/p/skua/wiki/Process>:
>
> Customers: this remains slightly artificial for us. We have a couple
> of folk targeted as potential users, and I'm making sure they're as
> involved as possible, but they didn't _ask_ us to do this, and they're
> not funded to spend time crafting UserStories, so there's a limit to
> how much we can badger them, especially as we don't yet have anything
> they can get immediate benefit from. That should change with this
> first release. They've phoned in to a couple of the iteration
> meetings, and even if they're not there, they're concrete enough to
> shape discussion. So: XP-purity=3/5; usefulness=3/5 and rising.
Encouraging. Keeping a low level interest at this stage is all that can
be expected I guess.
Would your customners benifit from feeling more "important" within the
proejct?
I recall I promised to draft a Governance Model for this purpose, but
have not delivered (that was Tony's "fault" as he said there was no
rush). We've been doing work on the OSS Watch wiki towards this [1] and
[2] (remember they are wiki pages, still unfinished or QA'd).
> User stories: still a little bit artificial. I do like the
> concreteness of 'what functionality is this adding?', and the
> refreshing clarity of 'YAGNI' as an answer. The artificiality comes
> from the fact that most of the user stories we've implemented have
> come from us, and represent infrastructural features that we've had to
> twist somewhat into a 'story'. Presumably this will change as the
> 'customers' get more involved. XP-purity=3/5; usefulness=2/5 to 4/5,
> depending on whom you talk to.
Yes, I think I agree. This kind of "artificial" feeling is very common
amongst projects, like SKUA, that are funded to solve a problem that we
*think* needs solving. This is rather different to solving a problem
where a customer *knows* it needs solving.
I wonder if a project, such as SKUA, out to make its early stage
objectives to generate enough interest from potential customers to have
them identify a real story in an iteration. Of course, getting an
release out will help immensely here.
> Iterations: This is a bit of a stretch, but I believe it's working
> fairly neatly. Because our user stories are slightly artificial, and
> partly because we're below the lower range of XP project sizes, we
> haven't been able to perform the project-velocity calculation in any
> real sense. Despite that, I think that the fortnightly meeting, and
> its repeated questions (what did we do last iteration?; what are we
> going to do in the next two weeks?) give useful reassurance that we
> are making progress, and useful concreteness (that word again) to our
> plans. XP-purity=4/5, usefulness=5/5.
I can tell you, from an observers point of view, that the iteration
reports to the mailing list have been *really* useful. They act as a
"heartbeat" on an otherwise quiet list.
They give me an *easy* insight into the current status of the project.
I certainly give them a 5/5 for usefulness.
> Informative workplace: not really. The wiki's useful, of course, but
> that's not really what this is supposed to refer to. We have the
> 'whiteboard' at <http://docs.google.com/Doc?id=dcvcvwqp_13cdsm6ch>,
> and I've consistently used that to jot down the iteration meeting
> notes, but we haven't see this actually used as a 'whiteboard' so
> far. Suggestions are welcome. XP-purity=2/5; usefulness=1/5.
I note that you are making zero use of the issue tracker and svn commit
mails. These are two of the most important communication devices for a
distributed team.
Since the Google Wiki has an SVN back-end the creation of an SVN commit
list will help keep everyone informed of changes to the wiki.
Similarly, a well "stocked" issue tracker, linked to the developer list,
will ensure that the whole team, and bystandars like me, are kept
informed of progress and problems in real time.
They also act as the all important memory for the project. Right now the
vast majority of decision making and actvity is going undocumented. This
makes the future maintenance of the project outputs harder. For example,
on one of my oldest projects a new contributor recently offered to help
with a long planned task. This task was non-trivial and although it had
full community support it had never got very far in implementation (it
invovles rewriting much of the internals of the system).
When this new contributor arrived and made what he thought was a new
proposal we were able to point him at the issue tracker where we had
documented all activity to date on the particular task. The tracker had
links to mail list discussions, SVN commits that were relevant, IRC logs
and a report and photo's from a face to face meeting. All this material
spanned a total period of five years. Most of the participants in those
activities had now left the project.
Without proper use of the issue tracker that potential contributor would
have had to repeat all that work - probably making some of the same
mistakes we had made in our early experiments with solutions.
Finally, the use of the issue tracker will help when it comes to
calculating velocity. Stories can be documented in the tracker.
Cross-referenced commit messages in SVN indicate what code and wiki
activity has occured and the issue can join up all other resources in a
single place to make tracking easier.
> Stand-up meetings: OK, I think. We've been having brief skypecons, of
> 5-10 minutes, at noon about three days a week. We're falling into a
> fairly regular pattern. I think this is useful, as a way of all of us
> keeping up-to-date on things, and occasionally turning into a brief
> discussion of what we should do next. I don't know if Kona and Tony
> feel the same way about these. XP-purity=3/5; usefulness=3/5?
It would be interesting to hear the rest of the teams view.
One important point is that they exclude potential contributors (unless
explicitly invited in). This may, or may not be a problem, in this early
stage it probably isn't an issue. But as customers start to get more
involved these meetings may become more of a problem.
> Thinking about the specific things you mentioned, I think the absence
> of these is partly because we're using an XP-like methodology, rather
> than a traditional distributed-OSS one.
If, by that statement you mean you don't care about community outside of
your identified customers and your project team then OK. I'm unclear
right now whether a community model is part of your sustainability plan
(you mention this below).
>> no use of the issue tracker
>
> No, because we're talking to each other.
Where's the record for when one of you leaves or can't make a meeting?
(see example above)
> I
> recall from somewhere in the Shore and Warden book a remark to the
> effect that XP projects tended not to have big issue tracking systems.
Yes, but they have other tracking mechanisms that work becuase the team
is co-located, such as whiteboards and story boards. You're a
distributed team. Do you all know everthing, if you do do you all
remember it? (rhetorical question given your next comment)
As the project grows in complexity will this informal sharing of
information scale? (rhetorical question given your next comment)
> Having said that, we do plan to make releases beyond the 'customers'
> envisaged by XP, and we hope that these will be used by folk more
> tangentially related to the project, and the most natural way for them
> to feed back would be via the Google Code issue tracker. Thus I don't
> plan to be dogmatic about our minimal use of it.
>
>> and minimal public discussion
>
> Not really. There's plenty of discussion in the noon meetings and
> iteration meetings, which anyone can come along to -- they're public,
> albeit synchronous and not archived.
synchronous = innaccesible to a large portion of the world (if you want
to engage community you have to maximise your chances) and intefering
for those with a casual interest (I, for example, catch up on SKUA
activities by reading the subjects of your mails - plus some extensive
keyword filtering). I don't want to spend up to an hour a week attending
meetings in a project a may never have any real interest in.
not archived = no memory (see above) and no communications beyond those
present
Again, this may not be a problem to your project. But I don't see it as
a defence against my (clarified) charge of minimal *accesible* public
discussion.
> We use Jabber, too. Part of the
> XP experiment has been to try to set up richer developer communication
> channels, and force ourselves to use them.
That's an interesting comment. Your methods have created a richer set of
channels for "ourselves", but they exlude others.
Is this important?
Quite possibly. One reason I am interested in SKUA is that this project
has a greater expertise in RDF than I do. I'm hoping to learn by
watching what goes on here. The best way of learning (for me) is to
watch and then to get involved. That makes me a potential contributor.
Sure, I'm only ever likely to be a casual volunteer, but if I find a bug
in your install scipts (or even fix it) how valuable would I be?
The sad truth is, if it weren't for my day job responsabilities I would
never have bothered with this project because there is no easy way for
me to see what happens, therefore no opportunities for casual interest.
Again, I'm not saying you *should* do it differently. I'm only telling
you how it seems from the "other side" so you can decide if you *want*
to do it differently.
> In consequence, there's no
> real _need_ for us to discuss things on the mailing list.
See all of the above.
The use of the issue tracker as a planning tool would solve most of the
problems as they would provide enough summary information for the casual
observer, whilst not intefering (significantly) with your current processes.
More of the communication that sparked this discussion is what I'm
talking about, not necessarily the detailed design discussion you are
having in your stand-ups (although I would like to see that too).
> Separately:
>
>> no SVN commits
>
> Indeed -- I haven't set up a skua-commits list, because I didn't think
> anyone would care enough to subscribe to it. The commit messages just
> come to me, at present. If you, Ross, would subscribe to a skua-
> commits list then I can set it up and advertise it.
Sure, it costs us nothing and I think I can learn from your code as I
note above. I don't promise to review every commit, but seeing the log
messages go by would be useful (assuming the team write meaningful log
messages that is). I'd be ecstatic if the commits were tied to the
stories too.
> Tony and Kona: do you have anything to add here? Does this match your
> perception?
Ross
[1] http://wiki.oss-watch.ac.uk/GovernanceMode
[2] http://wiki.oss-watch.ac.uk/ExamplesOfOpenSourceGovernanceModels