Responses below: On 3 Jan 2003 at 16:34, Jordi Salvat i Alabart wrote:
> Dear co-contributors, > > I've been thinking about some non-technical JMeter issues which I'd like > to share with you. It's mostly issues that have been raised into this > list during the recent weeks and have been only partially addressed. I'm > just exposing them here because I think they need further discussion. > > 1/ Committers > > We all agree that we need to keep the ball rolling (in my case, because > I use JMeter for work and need it getting better as fast as possible, > others will have their own reasons). My (our?) current strategy is to > get as much people on-board as possible: if they don't touch at CVS, > makes no harm, if they touch, it makes progress. Of course this was > absolutely necessary at the recent stage of the project, where it was > getting stalled, but can become a problem in the future. Would be nice > to discuss where we want go to in this matter. For example, I would > propose a consensus policy requiring any committer to relinquish his > rights before unsubscribing from the dev mailing list -- if we ever > suspect someone has "disappeared" from the project, we can ping him on > the list. If we do this, we will know how many active committers there > are, and we can react if it gets below a certain threshold. The more people one board, the more trouble we might have making big decisions for JMeter's future. I think that should be kept in mind. Now would be a good time to make certain decisions before we get too big to make them effectively. After those decisions are made, then more people can be added safely. > > 2/ Contributions > > We want to encourage the people who use JMeter to contribute. I believe > the best way to do this is to make things easy for them. In my opinion, > there's some technical aspects of JMeter which place a too high > threshold on this. The relationship between GUI and test elements and > this Avalon configuration stuff were the most important for me. Poor > JavaDoc documentation is another. Absence of nightly builds is probably > the worse. Even sloppy indenting contributes to the difficulties. Is > there any non-technical issues we should address on this matter? I think documenation is the place to start. I'd be happy to do some work here, both in javadocs and in "developer docs", but I need help knowing what you guys have questions about. I've tried to do this in the past, and it didn't help people much - I'm just not very good at it. > > 3/ Long-term development plan > > We lack a long-term development plan. JMeter is still far from being a > mature product, yet its development is mainly driven by bug-fixing and > small functional enhancements. At the very least, we need to agree on a > loose high-level end-user requirement list [I think I already have a > document of this kind somewhere -- the one I used to select JMeter among > other tools quite a few months ago]. I have thoughts in this area. I would like the GUI itself improved (currently, the tree has a confusing mixture of ordered elements and unordered elements - I'd like these separated somehow). I would like function parsing to be fully recursive rather than the complex 2-pass method currently in place. I'd like jtl to be changed to a simpler format (eg CSV). And useful developer docs made. > > Opinions? > > Salut, > > Jordi. > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- Michael Stover [EMAIL PROTECTED] Yahoo IM: mstover_ya ICQ: 152975688 AIM: mstover777 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
