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]

Reply via email to