Joe Germuska wrote:
Well, that was me, actually. And there had been lots of prior discussion, as cited by Hubert in three URLs in a message which motivated me to finally do it. That prior discussion dates back more than a year.

Yep, I found it in my trash folder. Sorry for the confusion! :)

It's fair that there was discussion, but an obvious problem is still apparent... I've only been on the lists for a couple of months. I would certainly think no one expects a person to go through the entire list archives to catch up :)

I think we really need something that cuts through the "noise" on the list, meaning that we have a repository where the discussions on the list are boiled down to actual action points for people to reference. This is kind of basic project management stuff I'm talking about. You debate in a meeting, then someone draws up a list of what is being done by who, *referencing* the discussion thread if it is needed. I don't see where we have anything like that at this point. I don't believe the Wiki nor Bugzilla is it.

But no, I didn't beat you to the punch, if you feel that a solution is necessary which works with Struts 1.2 without using struts-chain.

That's true, but only to a point... since I've now been told that "no new features will ever be added to anything but 1.3 and beyond", there is no hope of my work ever being incorporated into the core *if* a different direction is used in 1.3. Therefore, in a sense you *did* beat me to the punch because there was no chance for me to explore doing it in 1.3


Now, you could say that was my fault for not starting my work with 1.3, and I couldn't really argue that :)

But look at SSL/Ext, or Struts Test Case. Or Hubert's FormDef project. Or AppFuse. These are all things which help people use Struts. There are others.

Your right of course, and like I said, if there is a way to do this as an extension to the framework, and especially if someone wants to suggest such an option, I am willing to listen and do the work. I will explore some possible approaches on my own.


But I still feel this is something that *should* in fact be in the core. I don't think anyone is going to change my mind on that point. Unfortunately, if I can't convince any of you, then it's just an opinion, and everyones' got one :)

I remember the proposal, although I don't remember how it was meant to stay accurate and up to date.

The part where I saw my proposal really differing from the Wiki or Bugzilla (and in that way be more accurate and up-to-date) is that in an automated fashion it would "tickle" for status the assignee of a particular enhancement (note that I only intended for it to cover enhancements). In other words...


(1) You go to the site and see an enhancement proposal that interests you (I could imagine a list of requested/suggested enhancements and a separate list of what is actually being done). No one else has stepped forward to work on it, so you volunteer. That task is then assigned to you.

(2) At some regular interval (every week?) an automated message goes out to you asking for an update on your progress. If no response is received within some time period (48 hours?), then that task is unassigned, and someone else can pick it up.

In this way, we would always know who is working on what, and at least a rough idea of their progress. True, they could just do a quick "I'm working on it" update every week, but one has to assume some level of commitment to at least write brief *real* update of they were interested to volunteer in the first place. If someone drops something, someone else can pick it up. In many ways its just a slightly more automated version of what exists now, but I think it would make a big difference,

There is more that could be done of course, but this was the starting point I suggested and offered to build.

To be honest (and hopefully not appearing rude), I don't see how having this site would help me have the time to put stuff there, or anyone else who is working on various features.

Not appearing rude at all because clearly it wouldn't :) But someone could at least know that what they are working on isn't being done by someone else concurrently. At least you wouldn't find out that all your hard work was already done by someone else, and they released before you.


Also, we could allow for things like multiple assignees, so that if two people had a competing approach to something, we'd know it and both would know that their solution may not be choosen. At least they could know that up-front instead of only after they did the wasted work.

I'm not meaning this email to be the final word, or to imply that there the problems you raise are immaterial, but I think those problems are inherent to a community like ours, made up of a bunch of distributed volunteers. I don't even have the bandwidth I'd like to cut code and participate in all of the discussions on the Struts lists, let alone having extra bandwidth for community engineering.

I agree, I'm not pointing out any problems (assuming one agrees they *are* problems) that are unusual for such a community-driven project.


I don't however see the sense is saying "that's the way it is, deal with it", which is kind of what we're saying, isn't it? I believe community-driven development in general suffers from a general lack of real project management, and I think we should all strive to introduce some. Because its a distributed environment, the issues are different and the solutions will be different than in more "typical" environments (like an enterprise for instance).

I've tried to offer some solutions, and even if you disgaree (meaning Joe or anyone else), I believe there should be discussion on the issue, some brainstorming, and see if we can't make it better for all involved (or all who *want* to be involved) instead of just being satisfied with the status quo.

As much as I hate to say it, sometimes engineers being project managers is a bad idea. Perhaps open-source community-driven development projects should come to that conclusion and separate the project managers from the developers. Just a thought (not even sure *I* would agree with it yet).

Joe


-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to