The burst in the number of committers has nothing to do with Struts. For the most part it is Craig bringing in people who had nothing to do with Struts out of JSF to work on Shale and give him voting power. Has Gary ever done anything with Struts? And, he is a Struts committer. That is the Struts-Apache Way. The Apache Way and the Struts-Apache Way or Way Different.
On 4/25/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > On 4/25/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > On 4/24/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > > > > > * Rationale > > > One of the issues that a number of people seem to have with the way > > > Struts has progressed is the seeming inability (or difficulty at > least) > > > of getting "new blood" involved. There seems to be a perception by > many > > > that there is a bit of a "closed club" mentality with regard to being > > > invited in as a committer and that the Struts community at large has > no > > > say in the matter. > > > > > > The latter statement is, as mentioned in my previous response, the way > that > > *all* projects at Apache work -- it is not unique to Struts. Any claim > that > > all of Apache is broken in this regard is going to be, umm, unlikely to > be > > agreed with :-). What's more interesting is to examine the former > > statement, and compare it to the facts. > > > > The "Who We Are" page[1] lists the current folks who are on the PMC (and > > also have committer privileges), and who are committers not on the PMC. > > There's 14 and 13 names, respectively, giving a total of 27 (and this > > doesn't count the 10 previous committers who are now on the emeritus > list, > > for a total of 37). That's a pretty good size number, compared to the > > average at Apache. But what is really interesting is to look at the > timing > > of how we got from one committer (me) six years ago, to where we are > today > > -- and focus especially on the more recent changes. > > > > In just the last year there have been quite a number of new committers > > added[2] ... six independent of the WebWork merger (Wendy, Gary, Greg, > > Shawn, Laurie, and Richard), two more (Jason and Patrick) directly > because > > of the merger, and five more who have commit rights to the WebWork > incubator > > code and will become Struts committers as soon as it graduates. There > is > > also one outstanding invitation that, for personal reasons fo the > individual > > involved, will be accepted later rather than now. That is a pretty > large > > percentage increase for a single year, even discounting the merger -- > and > > have you ever seen other "competing" communities come together like > this? > > Hmm ... doesn't seem like the existing community is particularly > "closed" to > > new blood to me. > > I agree that we have been pretty active in bringing people into the > Struts project but although the numbers look good, in terms of > action1, it hasn't translated into much activity in terms of moving > action1 code forward. > > > Examining how the new folks got themselves nominated and elected is also > > interesting. In every case, it was based on continuous contributions of > > code, documentation, user list help, build script maintenance, or > whatever > > made a *positive* difference for everyone. Indeed, if you go back to > the > > days when folks like Ted and Martin were added, a lot of it was being > tired > > of applying all the patches they were contributing :-). All of these > folks > > "get it" -- so it is not just a couple of dictatorial snobs sitting on > top > > of the mountain dictating who is in and who is out :-). > > > > There is also another interesting observation here -- you don't have to > be a > > committer to initiate changes to the Struts code base. What you have to > do > > is justify your bugfix or RFE to the point where an existing committer > is > > willing to take responsibility for cleaning up any messes that > committing > > the change might cause. So, you only have to convince one of the > various > > folks to get your patch in. Failure to succeed in that goal *could* be > a > > close minded community, but it also just might be that the proposed > change > > doesn't fit with what the committers as a whole have in mind (it only > takes > > one commiter -1 to make a committed change get reversed, so we pay > attention > > to this as part of the decision process on accepting a patch). Just in > the > > little time I have had to spend on Struts in the last year, I've > committed > > patches from at least 20 different people. Spread across the six years > that > > Struts has existed, and all the committers who have done the same thing, > we > > are talking many *hundreds* of people who have contributed at least some > > code or documentation to what is now Struts. > > Looking at bugzilla we have 312 open enhancement tickets for action1 > and if someone did submit a good enhancement patch to bugzilla for > action1, from my perspective, the most likely outcome is that it would > be ignored. The situation is different for Shale and ww/action2 - but > if I wasn't a committer and was interested in working on action1 my > main concern would be that if I did bother to submit anything theres a > good chance it would be a waste of time. > > > I just don't buy the presumption that the current system is broken. I > won't > > presume to convince *you* to think that way -- it's your perogative to > think > > whatever you want -- but I will certainly take into account whether > someone > > "gets it" before I would ever vote for them to be a committer. > > I agree its not broken in general and there is much to back up that > when it does work, it works well. However it doesn't mean to say it > always works. IMO when ASF projects get into a situation where the > committers on that project are no longer active then I think the > system can stop working. Clearly we are not in a completely inactive > situation on action1 - but this is mostly re-organisation, > changing/fixing the build system and some bug fixes, which I would > characterize as "maintenance mode". Unfortunately I think this has a > downwards spiral effect - since if people see less activity and > bugs/patches being left ignored then they are less likely to > contribute, which makes us less likely to get new blood for action1 > and so on. > > While I agree that what Frank is proposing isn't currently "the Apache > way" and other projects may look at it with suspicion - I don't think > thats a reason for not considering something new. If it turned out to > be a big success then it could become the Apache Way. Seems to me that > the way for Apache to evolve is by projects trying out new approaches > like this. > > I also don't think that what he is proposing actually goes against > anything that is "the Apache Way" - the same procedures for a new > commiter being elected still apply - this just adds a new dimension. I > think where Frank's proposal has the possibility to do something good > is that a provides a way which encourages community members to get > involved and gives them some hope by having a mechanism in place. If > we can reverse what I perceive as the spiral down wrt to community > involvement in action1 then this would be really good. > > Ted in another post in this thread raises the point about voting > publically on new committers. I used to be in the same camp, thinking > its better not to embarras people, but I've changed my mind on this. I > think one reason why some people believe its a "closed club" is the > fact that we do the votes privately. Also I think the way to get round > this issue is to contact the person first asking them if they mind or > want to be nominated. > > > Fortunately for those who either don't, or don't want to, buy into this, > the > > Apache license gives you the freedom to take the code and go start your > own > > community, operating according to your own rules, if you don't like the > way > > things work here. But you are starting from a rationale that does not > match > > the objective facts, so I'm not even going to be interested in trying to > > hash out details of how to change something that does not need to be > > changed. > > I agree in theory this is the case, but the reality for most people is > that forking something like action1 as a non-Apache project is not a > realistic option. For all the reasons why people/businesses are > attracted to use an Apache project - having a non-official fork of an > Apache project is unlikely to attract enough of the community to make > it viable. I would be interested to know if there are any Apache > projects where this has happened successfully? > > Niall > > > Craig > > > > [1] http://struts.apache.org/volunteers.html > > [2] http://struts.apache.org/announce.html > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
