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 _______________________________________________ F-spot-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/f-spot-list
