How about a management FAQ? And then... (you'll hate this): For each answer which is emotionally unsatisfying, what are the smallest changes you could make which would allow you to tweak the answer to be more satisfying?
For example: A simple, pretty, easily accessible page that allows voting on bugs and features, and shows the current top-voted items might be a good companion to an "It'll get fixed when it gets fixed" answer. Ok, just an idea, I support your idealistic vision-- but with just minor lip service to the real world of human decision-making I think Django could probably quadruple its user base. On Oct 1, 6:13 am, "James Bennett" <[EMAIL PROTECTED]> wrote: > On 10/1/07, Stefan Matthias Aust <[EMAIL PROTECTED]> wrote: > > > It might be very obvious to you what is missing before 0.97 can be > > released because you're deeply involved with the development and > > exactly know it. However, I cannot easily find the answer on the web > > site. Searching the mailing archive shouldn't be the only way to get > > such kind of information - if that would answer the question at all. > > It isn't the only way, and I didn't claim it was. > > > Well, open source development is (or at least shouldn't be) not that > > different to closed source development. When hacking something, you > > should have an idea on what to achieve and when to achieve it or at > > least for the progress towards the goal. Document that progress and do > > not make it a secret. That is what I ask for. > > Not having copious documentation of everything the dev team is doing > isn't the same as "making it a secret" ;) > > Again, the easy way to see what's going on is to watch the Trac > timeline and the dev list. That lets you see commits, wiki changes and > ongoing discussions of Django development. > > > As a software developer my self, I can understand the "when it's > > ready" mantra, but IMHO that's not an acceptable answer. I mentioned > > the Eclipse project and how they managed to setup an trustworthy > > release process. Not only IMHO, time based releases are better than > > feature driven once, see for example > >http://video.google.de/videoplay?docid=-5503858974016723264 > > We'll just have to agree to disagree. What happens if Eclipse is > coming up on a stated release date with a showstopping bug they can't > fix in time? Do they say "time-based releases are better" and push a > broken product? (rhetorical question) > > > Well, the provided patch seems to work just fine. I understand that > > something like this must be carefully applied because it might break a > > lot of applications if done wrong because nearly everybody works on > > the SVN trunk. However, if there were more stable releases, not > > everybody would probably work on trunk and you could be more > > riskaccepting, having on the other hand more people to check out the > > code, getting quicker to a stable code base. (In theory, this sound so > > easy, in practice, it's of course more difficult ;) > > Regardless of release frequency, we have a history of all but actively > encouraging people to work from SVN checkouts; the rate of Django > development has been such that there's almost always an attractive > feature or two in trunk that's not in the latest release, and we'd > have to switch to a weekly or even daily release schedule to prevent > that. > > > Well, do the people who write those tickets know that they are > > supposed to "defend" their tickets at the "developers court"? :) Right > > now, it seems they are stalled. Would it help to distinguish bugs and > > feature requests? > > It's not a "court". Either somebody gets discussion going on the > ticket and a decision is reached, or nobody does and it eventually > gets closed when it's clear that nobody's actively working on/for the > ticket. And this is pretty much par for the course with open-source > projects: if you file a "drive-by" ticket with any project and never > follow up on it again, odds are nobody else is going to do it for you. > > > Unfortune IMHO, because migrations and semi-automatic deployment > > (capistrano or how it's called) are compelling reasons for Rails. I > > saw that there's a new project split from the Django SVN at > >http://code.google.com/p/deseb/which I bookmarked for further study. > > Is this the one by the Derek you mentioned? > > Yup. It never ceases to amaze me how many people are willing to put > hours or days of time into lobbying for the feature, but never bother > to contribute so much as a single line of code to get it working. More > people should follow Derek's example: code speaks louder than words. > > > Their success of course does not original from a single timeline > > document, but being reliable certainly helps to attract corporations. > > They got a bit of a head start with that, don't you think? > > > It's not that I cannot check out SVN and re-submit it to our own VCS, > > but it just feels unstable. > > OK. That's your feeling and I can't argue with it. It's not my > feeling, but what can you do? > > > I have a different opinion: A road map is a statement of intent, a > > priorization of features and a commitment. Note, that I didn't say > > time line. > > And, again, it's easy to find these things out if you're genuinely > interested; the Trac timeline and the developers' list are both > well-advertised and publicly available. In the case of schema > evolution, there's been quite a bit of discussion of Derek's project > just recently, for example, which would have told you everything you > wanted to know. > > I'm not convinced that, at this point, it's necessary to have a > mission statement for Django releases, or anything more formal than > the process we already have: my personal opinion is that people who > make technology choices based on the sorts of things that appeal to > middle managers are people who I'll happily let turn into some other > project's problem ;) > > > While I agree that developer time should not be wasted and the > > volunteer work should be highly respected, I do not believe that > > nobody has a plan on what to do next. This plan has to be coordinated > > and should follow the "Django vision" of what fits into the project > > and what not. It is my impression that currently, this vision is > > shared by the developers but it is not written down. A road map would > > be a manifested vision (if that's a word)... > > See above. > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
