(Inline.) On Fri, 11 Mar 2005 16:06:19 -0500, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > 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.
The closest thing we have right now are the Roadmap and Versions page. Other than that, we all just follow along on the list. I know there are other open source projects that are run more like a in-house team, but, to date, this hasn't been one of them :) Unfortunately, most of us are so swamped with our regular jobs, we can't agree to do something until we are ready to sit down and do it. If we try, then someone becomes a bottleneck. If anyone wants to start maintaining something on the wiki, or provide patches for the Roadmap or Versions page, please have at 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 I think the meaning here is that no one is eager to open up the 1.2.x branch for active development, and we are hoping to start shipping the 1.3.x series soon. Once upon a time, we talked about a 2.x revolution, where we could break some of the API contracts. But, the general consensus was that backward compatibility was vital, and we should just evolve 1.x. We can *evolve* the API contracts, but the expectation is to do it in depreate/replace/remove series. A good example is the DataSource, which we evolved out of the API over 1.1 and 1.2, and are removing 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 :) If any extension was sufficiently popular, it could find its way into the Core. But, the key is that the extension has to be popular within the Community. A good example is the Nested Taglibs. When these came out, none of the Committers where using them, but there was a groundswell of support on the User and Dev list. So, we accepted the extension into the Taglibs package (which was then part of the Core). > > 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. Except for the nags, Bugzilla and the other issue trackers come close to this. If there is a ticket open for something, people often note any progress being made. And if progress stops, people have been know to post a nudge. (Happened to me last week.) The trick would be to open Bugzilla tickets for the Roadmap items, and encourage people to log their progress. Realistically, someone with an itch might have to do the logging themselves at first, to encourage people to get into the habit. Sadly, in a volunteer environment, it's hard to insist that people do some things a certain way, unless you are willing to do it yourself. JIRA is particularly good at Roadmapping, but until Commons switches over, we're probably better off wth Bugzilla. :( > > 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). Oh, I don't think anyone would mind a hands-on project manager being involved with a project. The operative phrase being "hands-on". It would be wonderful if someone could keep the Roadmap and Versions page up to date with the latest list discussions. It would also be wonderful if someone could open Bugzilla tickets for Roadmap items and update the comments with any peritennt comments from the Subversion logs or the list. But, that someone like that has to be willing to step up and do the work. Not by telling other people what to do, but by doing it themselves, and leading by example. There are no stupid or lazy Committers. Just some very busy coders already working 50 or 80 hours weeks, helping out the best we can. And, if someone can show us that better use of Bugzilla or the equivalent can make better use of our time, of course we'd go along. But, someone needs to blaze the path. > > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
