On 4/24/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.
Having composed a nice long response, I can now delete it, since Craig says below pretty much everything I was going to say also. ;-) One thing I'll add, though. The problem appears to be perception, and reality doesn't, in my opinion and as evidenced below, match that perception. Therefore the solution should be addressing the _perception_ of the way Struts is working, and changing perception does not require changes to the _reality_ of the way it's working. And one question I would ask: What, exactly, is the end goal? More committers? More nominations? If bringing in a new committer every other month, as we've been doing, isn't enough, what is? As other people have pointed out elsewhere, more committers doesn't necessarily translate to more activity on the code base, either, as we've seen in the past. On the topic of voting in public, I am very much opposed. It's not just a case of saving face for a nominee who is ultimately rejected. A public vote affects the way people vote, as well. In a private vote, someone might object strongly, along the lines of "-1 - that guy's code is a pile of crap". But would the same person voice that same opinion in a public vote on a mailing list of a couple of thousand people, and which will be archived for the world to see, forever? Perhaps a few would, but many would not. They would more likely keep quiet, the end result being that Mr. Pile O'Crap becomes a committer because the only people who voted were the ones in favour. IMHO, that is A Very Bad Thing. -- Martin Cooper 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. > > 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. > > 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. > > 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. > > Craig > > [1] http://struts.apache.org/volunteers.html > [2] http://struts.apache.org/announce.html > >
