Berin Lautenbach wrote on Thursday, May 20, 2004 4:16 AM:

> +1 - with some reservations/questions.
> 
> 1.  I tried to find it, but I couldn't find a definitive answer to
> Noel's question RE mailing lists?  (I'd note that it is very easy to
> add more mailing lists and split things out at any point - hint hint
> :>) 

I replied that I completely agreed about the user list, but I wanted
to check with the other committers about the dev list.  I'm going to
recommend that we start with one list on that too, even though I do
suspect that we will grow to three dev lists within 2-6 months.  I'll
follow-up with the definitive answer shortly.
 
> 2.  We seem to be adding a *lot* of initial committers. Have all of
> these people been actively involved in getting Beehive to its current
> state?  I'd be a bit uncomfortable giving all these people write
> access to repositories unless we have some comfort that they are
> actively involved in development to date.  Or are non-involved people
> already active Apache committers?

Keep in mind that the initial committers are spread across three 
subprojects.  There will be some overlap, but for the most part,
committers will be focusing on just one of the areas.  

As far as being actively involved in development, I've made a few 
exceptions to that rule that I hope you will agree with:
- two testers (although that probably fits the definition of 
active involvement)
- a few people who have actively built extensions for the beehive
code base, but haven't been building the core code.
- two people primarily focused on web site, docs, project management
issues, and community issues.  This is something I shied away from in 
xmlbeans - I thought there should only be devs at apache,
but I've changed my opinion on that.  I think Apache could be a better
place with a little more diversity in committer skills/focus.

> 3.  I'd imagine we are going to have the same thing around BEA vs.
> non-BEA involvement as with XMLBeans?  (I.e. focus on building
> community outside the initial BEA startup.)

I don't think it will be the same at all, because we are older and
wiser now. ;-)

Seriously, I've really tried to do some things differently specifically
to improve the areas that I thought were weak areas for us in XMLBeans.
For instance, early contact with the Struts and Web Services 
communities has attracted a lot of interest -- I expect there will be 
more than a handful of contributors from those communities in the near
future.  Also, we've started the project with a much smaller ratio of
BEA committers this time (I think XML Beans started with 2/3 BEA 
people).

However, another thing I've learned is that there can be a difference 
between the ratio of BEA/non-BEA committers and the ratio of 
BEA/non-BEA overall involvement.  In XMLBeans, it's been slow to get a 
good balance of involvement from non-BEA people, although I think that 
community has really improved a lot in the last couple months. 

So, this is an area I'm really going to be concentrating on from the 
beginning with Beehive.  There will still be the bias associated with 
starting with a bunch of code that the BEA devs are already familiar 
with, but I'm hoping the BEA folks (and eventually others) will help 
get people figure out the code base as early as possible by creating 
more docs, specs, and being responsive on the dev and user lists.

In the JSR-181 area, I expect that non-BEA folks, like Davanum and 
Ias, will be contributing roughly as much as the BEA folks.  In the
NetUI area, I think that we'll get contributions from members of the
Struts community fairly early on.  Controls will probably be the 
slowest area to catch on, since it doesn't map as cleanly to other
things being used at Apache (other than its use of Velocity for code
generation); so, we'll have to focus on that one.


> Having said the above - looks like a great idea! I also hugely
> appreciate the work that went into the proposal.  It makes things much
> easier to understand :>.

Thanks - that was the hope!

Cliff

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to