On Tue, April 25, 2006 1:17 am, Craig McClanahan said: > 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.
Please don't infer the word broken, I never used it :) Broken has a negative connotation. I'm talking about an improvement. Unless you believe the way things are today is 100% perfect, then there is always room for improvement. Something doesn't have to be "broken" for a change to be reasonable. Also, I'm not talking about all of Apache here, I'm talking only about Struts. Granted I'm not a member of every community at Apache, but of the ones I am (even as just a lurker), Struts seems to be the only one that evokes these types of criticisms (rightly or wrongly so). I'm not suggesting trying to change the way all of Apache works, and in fact, I'm not trying to change the way Struts works. Just build on top of it a little bit. If this idea were to work, and other projects saw and liked it, maybe it would change all of Apache eventually. That's not one of my goals here today :) > 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. That depends entirely on your meaning of the word "closed". You make the argument that the number of new committers means it isn't closed, and I agree with you to a degree. But that's not the only meaning of "closed"... the invitations to those people came *soley* from the PMC AFAIK... the community had no say in it. That's the thing my proposal seeks to address, that the initiation of someone being invited doesn't necessarily have to come from those already there (although they would still have the final say-so). > 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. That's the way it *should* work, but I don't believe it is the way it *has* worked. There are a number of other names that would have been invited as well if that is all there was to it. My proposal seeks to remove that "something else"... no, actually, it doesn't seek to remove it, it only seeks to bring it into the light, so to speak. If someone were nominated and ultimately not invited to join, the community could look and see if they believed that person met the criteria you list above. If they did and still were not invited, it would be obvious that something else was at work. Perhaps it was something completely legitimate; it probably would come out in discussion during the vote period then. Maybe it isn't something legitimate (as judged by the community). Either way, we'd know, and could form our opinions accordingly. > 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. Perfectly fair observation IMO. > 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. Again, I never said anything was "broke". If I were to describe it, I would probably say "sub-optimal". Unless you are prepared to say that you think everything is absolutely perfect just the way it is, then there is *always* remove for improvement, it doesn't have to be broken. The "getting it" comment... if this equates to "you have to see things the way I see it", then I think it it problematic. I totally understand there is a certain set of underlying principles that Apache runs on, and someone should generally believe and adhere to those principles. I think most of us around here do, or we probably wouldn't be around! :) But, how easy it is to take the phrase "getting it" to an extreme that is unproductive... does one not "get it" if they question how things work? Does one not "get it" if they propose changes? Does one not "get it" if they mostly agree with the principles but think one or two could be tweaked a bit? I for one would very much appreciate a concrete definition of the phrase "gets it"... Because if it can't be concretely defined, that frankly plays into the "closed club" preception IMO... if it's an arbitrary determination made by those who already "get it", is it really a legitimate reason? > 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. Thank you Craig, I do appreciate you taking the time to react. That last sentence sums up your feelings I think. I would only ask you to consider once again that something does not have to be "broken" for there to be a way to improve it. You may still not think that the proposal has merit, but at least come at it from the right perspective :) > Craig Frank --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
