Mauro wrote on 08/11/2007 13:02:04: > Dan North wrote: > In general, my understanding of it is that there a trust network, and > that in essence applies to non-distributed development too. In this > sense, all committers should be able to commit (or apply patches in the > distributed sense - will they be renamed appliers? ;-) and not just despots. > > And for the nature of despotism, I think that a sledgehammer approach > for a small development team is not a good one - as it does not > contribute to a community spirit.
Maybe I should explain why I'm playing up the despotism this time round, and feel I have the right insights to do so (and share most of them with Dan). I'd rather have a few badly-needed features, done well, than a bloat of partly-done features, some of which will never be used. With respect to Mauro, the code generator is an example. I can't use it in its current form on any project, even toy ones like the Game of Life. I don't believe that it should have been checked in to the stable download (distributed SCM would help solve this problem, and I do have faith in Mauro's ability to finish the feature. It may not be needed in JBehave 2.0.) I have great respect for my own time, and yours. I believe that breaking the build and expecting other people to fix it, or introducing features without showing why they're needed and how they work, is disrespectful and contrary to the community spirit. It's stopped me from contributing as much as I'd have liked to in the past. Having the right to revert a revision or veto a change will allow us to work around each other more easily. It doesn't mean we _have_ to revert the build, and it doesn't mean we can't play with changes and make suggestions. It _will_ make us all think before we check in. I have so much respect for my own time because I remember how much I spent of it on JBehave 1.x - yet it seems that JBehave 1.x doesn't solve the problems. I'd like to change the way we work so that JBehave 2.0 does. I have spent some time looking at the take-up of various projects, and noted my own frustrations when trying to use new features in other open-source frameworks. The best frameworks - and the ones which get used - are not even necessarily the ones which solve the problems best. They're the ones which allow _users_ to solve the problems best. Our lack of decent documentation hasn't helped JBehave's case. HowTos and explanative models make a difference, and will also save the dev team time. We may be a small team, but we've generated a huge amount of code. Let's generate the _right_ code this time. This is my sledgehammer. There are many like it, but this one is mine. Cheers, Liz. -- Elizabeth Keogh [EMAIL PROTECTED] http://sirenian.livejournal.com http://jbehave.org
