F-Spot: goals and milestones

[Stephane Delcroix <stephane delcroix org>]

Hi list,

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 !).
Once again, these are my views, and I'll be pleased to discuss them with
you, maintainers, developers, beloved users. Everything is only
proposal, and I'll be happy to listen to yours.

* Goals, milestones and enhancement acceptance
==============================================
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 ?

Let's see first how F-Spot development works those days (or appears to
work, viewed from my desk)(I do not speak here about bugs, only new
features):
- Peoples submit ideas or needs, mainly on b.g.o. about things missing
or things to enhance in F-Spot.
- Some of those bugs are completed with a patch, either by the original
author or by another developer
- Some of those patches are reviewed
- Some patches, reviewed or not are committed by the CoreDevelopers in
CVS HEAD.
- Some brand new code (without enhancement request or review) also ends
up in CVS HEAD

What's wrong here, how to improve that?
- Some enhancement requests will never be filled. Mainly because the
request is way too far of the F-Spot goal, or aimed to fill a need for
only a minority (the bug reporter). Those requests needs to be closed by
the CoreDevelopers early or after a small discussion. There's 10th of
bugs like this in b.g.o. Don't let the developers waste time proposing
patches that will never reach CVS HEAD.
- Some enhancement requests are pretty cool. Fix this as a GOAL to
achieve. Even if there's no patch to fulfill the request.
- Some brand new code ends up in CVS. This means two things to me:
   1) the CoreDevelopers have plans about how to gear F-Spot up. If such
plans exists, let's share them and involve other developers
   2) Some code reach CVS without sufficient reviewing. Sometimes (but
it's very rare), the same code proposed first in b.g.o. will never reach
CVS as-is.
And finally:
- Patches needs review !!! There's not a lot of big patches to review,
and apparently we are something like 10 guys spending some hours every
weeks in the F-Spot code. If all developers could spend 1 hour a week to
test and review ONE patch, all patches in b.g.o. will have at least 2
reviews before the end of September (I don't speak about one-line bug
fix).

How to make it rocks !
- the CoreDevelopers had to define goals. It's already done with the
ToDo, Specs, UseCases and NewFeatures on the website.
- aggregate goals into milestones, and try to focus the developers to
achieve this milestone. An example of milestone could be 'Focus on
Export' with 314559 335935 321298 336161 345123 329685 336178 345098 as
goals...
- and, as all of this is quite a big job, extend the CoreDevelopers a
little bit (CVS write access, weekly IRC meeting, ...)

* Keeping the bug count low
===========================
What about the other bugs, the real ones, the annoying ones (not the
enhancement) ?
- Fix them.
- Fix them quick !
- Submit in CVS
- Close the bug.
There's more than 10 patches that fixes bugs with one or 2 lines of
code ! Those one or 2 liners probably don't need to be discussed and
reviewed and everything. But they need to be fixed in HEAD!

Take care of the users, waste 20 minute of your morning time to reply to
one new bug reported in b.g.o. Most of the time, it's well rewarded and
helps having a good day at work.

And what about fixing a meta-goal ? like reducing the bug count to less
than 200 for the end of the year (or quicker) ???

* 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.
No, I'm speaking about the patch acceptance speed. If a patch is good
enough and if the feature request is reasonable and accepted (see
upper), commit it to the CVS HEAD. this will de-facto increase the
number of testers and probably reduce the time to the feature completion
(opposed to the same patch living in bugzilla, reviewed, commented,
modified, ...)

* Have fun
==========
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.

Best Regards,

Stephane
-- 
Stephane Delcroix
stephane delcroix org