Re: F-Spot: goals and milestones

[Warren Baird <photogeekmtl gmail com>]

Stephane Delcroix wrote:
> Hi list,

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
> welcomed !).

Here too!   If any of you ever want to visit Montreal - we've got a 
spare bedroom!

> 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 
as possible.

> * 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 
question.

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
> =============================
> (http://catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html)
> 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
> audience.

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
> same.

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 
be valuable.

Warren