Re: F-Spot: goals and milestones
- From: Warren Baird <photogeekmtl gmail com>
- To: Stephane Delcroix <stephane delcroix org>
- Cc: f-spot-list gnome org
- Subject: Re: F-Spot: goals and milestones
- Date: Fri, 28 Jul 2006 13:57:47 -0400
Stephane Delcroix wrote:
Hi Stephane and everyone else.
Here's my (somewhat belated) take on all of this...
Before I get started - a brief history might help explain my viewpoint -
I'm a long-time developer (~12 years C++, Java, Perl, Python, etc.) who
recently moved into product management. I've been interested in
software dev processes for a while, and since starting in product
management I've been doing a fair bit of reading on various agile
processes. I think some of the agile techniques might work reasonably
well on a project like f-spot...
Hereafter, I'll try to share with you some of my views and thoughts
about f-spot and his development. I really do not want to hurt anybody
nor pointing anybody. I'm aware that F-Spot is mainly made from
volunteer and I'd like to thanks each of them personally (and btw, my
house is always open and there's beer in the fridge, you're all
Here too! If any of you ever want to visit Montreal - we've got a
I know that the big goal of F-Spot is to rules the world or be THE photo
manager for my mother AND the semi-pro photographer, but how can we
achieve this ?
I agree that's a great long-term goal... But I think we are quite a
way away from that. I think we need shorter term, more quantifiable
and achievable goals.
In the commercial software world, one way this is commonly done is to
have a 'Marketing Requirements Document" (MRD) that describes the
long-term goals - what the competitve landscape is like, what features
are needed to compete in various markets. For our purposes, this would
be things like - to be usable by 'my mother', we need ..., to be usable
by a prosumer, we need ..., to be usable by a semi-pro, we need ... etc.
Then for each specific release, there is a 'Vision' document that
describes what portion of the MRD we're going to address in that
release. From the vision document you come up with a 'Product
Requirement Document' (PRD) that describes in more detail exactly what
requirements need to be implemented in a release to achieve the vision.
Exactly how you turn the PRD into the release varies depending on what
methods make sense. You could use a scrum-like approach of treating
the PRD as a 'backlog' of features, and implement a subset of those
features in each scrum, or lots of other approaches.
As I said, I've never tried using these approaches on an OSS project -
but in theory I think some variation of it could work.
What I'd like to see would be a commitment to a regular release
structure - say 6 months releases, scheduled so that each release is
complete early enough that it can be included in a release of ubuntu
shortly after it is complete. For each release we pick a particular
area to focus on (our Vision), and try to get as much work as possible
done on that area. This would let us get fresh code into as many hands
* Keeping the bug count low
What I described above doesn't really touch on bugs much - I agree that
keeping the bug count low is very important. How we split the available
effort for each release between new dev and bug fixing is a good
although I did see an interesting article on a blog recently talking
about when *not* to fix bugs... In cases where bugs are relatively
minor, and risk of introducing serious new problems with the bug-fix is
high --- it's often better *not* to fix bugs, especially near a release.
And what about fixing a meta-goal ? like reducing the bug count to less
than 200 for the end of the year (or quicker) ???
I'd rather focus on a target related to the priority of the bugs --- as
I said above, fixing minor bugs isn't always a great idea. something
like 0 P1 and no more than N P2 bugs, for instance...
* Release early, release soon
I'm not speaking here about *real* release. Official releases need to be
well polished and almost bugfree because it's targeted to the largest
Personally, I think we need to work on getting 'real' releases... the
code included in ubuntu is terribly out-of-date... And it's still a
fair bit of work to set up a dev environment and getting it working. I
think getting fresher releases into ubuntu and other distros should be a
fairly high priority...
Last but not least, only do this because it's fun ! and useful. Enjoy
using and developing F-Spot, and let's other users and developers do the
Yay for fun!
what do people think? I've probably got about 5 hours/week on average
that I can put into f-spot... I can put some of that time towards
creating things like MRDs, Vision docs and PRDs if people think it would
] [Thread Prev