On Mon, 2007-10-01 at 17:07 +0200, Stefan Matthias Aust wrote: > Joe, > > 2007/10/1, Joe <[EMAIL PROTECTED]>: > > [...] > > And this is the biggest disconnect between Django's team and the > > business world. If I went to my bosses and told them "It's done when > > it's done" about our upcoming product releases, I would get fired. > > Your response should be, "It's really hard to estimate, but here is my > > best guess and a target for us to shoot for." And, you know what? > > Most of the time our estimates are pretty close. And by tracking how > > we do on our estimates, we can make them even more accurate. > > [...] > > You explained my points much better than I could (in plain English at least ;)
Throwing in my 2 cents here... I basically agree with all that has been said, as in: it would be great to have a stable, predictable timeline - but it's unrealistic to achieve that without at least one full-time person to do the housekeeping. Since that full-time person doesn't exist I'd like to propose something in between that I have seen implemented successfully even in very small projects: 0. Realize that creating a roadmap takes zero time and only very little effort. You get it for free, from your ticket-system. 1. Get sorted. Take advantage of the trac milestones and, more importantly, ticket relations (does trac have them nowadays?). The future will become *much* clearer once you have added hierarchy to the ticket swarm. It forces you to decide which things to do first (Milestone 1) and which to delay for a later date. At the same time a roadmap emerges naturally because the "almost-done things" bubble up and become more visible. 2. Don't bother with actual calendar dates. An occassional rough estimate "could be ready at" never hurts but "70% done, ticket-wise" gives a much better indication of progress anyways. Better yet, instead of picking randomly, people can then specificially choose to work on tickets that are relevant to the next milestone or to the particular feature that they're after. 3. Maybe investigate on a better ticket system. The trac ticketing sucks very hard in all regards and is beaten hands down by http://mantisbt.org or http://redmine.org. I hate to say but even the dreaded JIRA does it better. Well, long story short, you want custom workflow/ticket states, so your tickets can't be "ready for checkin" and "new" at the same time. You want a clean UI and a working search that doesn't hurt everytime you use it. You want to draw clear parent/child relationships all the way up to the milestones. Ofcourse a new ticket-system is not a must but having fought my own share of uphill battles against trac I can tell from expirience that many trac-users don't that they're missing a fair share of essential features. In summary, I think this whole discussion should really be about transparency, not about fixed dates. Programming schedules don't work with fixed dates. "It's done when it's done" is not an excuse, it's a honest summary of the situation. So all we need to do is add more transparency to the state of affairs and that's simply a matter of using better tools or using the existing tools better. I don't think the call for a roadmap would have appeared if somewhere on the django site it read like: ---snip--- Milestone 7 (16%, 40 of 240 tickets open, aggregate eta: 01-Apr-2009) - Sub-Goal 1: old admin to new admin (66%, 14 of 21 tickets open, eta: 01-12-2007) - Sub-Goal 2: enforce winnie-pooh.css for all sites (0%, 1 of 1 tickets open) - etc. ---snip--- Ofcourse the ETA doesn't really mean anything (just some numbers magic that a good ticket system can do) but the above view is imho the closest to a "roadmap" that an OSS project can get. And, believe it or not, towards the end of a Sub-Goal those figures often converge to surprisingly accurate estimates. Last but no least, don't underestimate the motivational factor of more transparency. People like the feeling of actually causing an impact on something (the fame-factor). With the current trac there's just an anonymous sea of tickets, not really inviting to give or take yet another drop. A little more structure and clustering would provide much better positive feedback to the contributor here. It just *feels* better to close ticket 6 of 10 on a Sub-Goal, pushing it from 50% to 60%, than to close one random ticket out of hundreds without knowing what other tickets may be interacting with or even blocking the issue at hand. Well, this is getting too long but I hope some of my ideas don't sound too far fetched to some of you. :) -mark --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
