Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (herse.apache.org: domain of nbubna@gmail.com designates
 66.249.82.233 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=BZtr9/pi/1wTE2MIWygiaqSxgAiVyLqmSPYEIx9x537UhwGVOHcBCb2qkIXiMHMT8JJysjIBoICb3lW3uNpatqU17wv0uznaof+Uj7q8N7vMjnZo++JLp5BkDVQvcdTYr1NTYMQoy/VtY4J6Jg7teOvuUt5HIWT5+FtEcAL0ehU=
Message-ID: <4d651da50611281039k11ec8b4di59ff075afe81b5ff@mail.gmail.com>
Date: Tue, 28 Nov 2006 10:39:16 -0800
From: "Nathan Bubna" <nbubna@gmail.com>
To: "Struts Developers List" <dev@struts.apache.org>
Subject: Re: Graduation Options (was Re: [PROPOSAL] Updated Tiles Graduation
 Proposal)
In-Reply-To: <456C768E.2030809@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4569A649.2090800@apache.org> <456C2F0D.9090509@apache.org>
	 <8b3ce3790611280509s4d9f9a31q2748cd2c71c5a863@mail.gmail.com>
	 <adba96190611280523u7d325d7cj4905a1e24691f5d@mail.gmail.com>
	 <8b3ce3790611280548p56c80be8mea5e2bce16d10eeb@mail.gmail.com>
	 <456C3FE4.40405@apache.org>
	 <F3C55671-9FE8-4FC1-86AA-3F5516E09E32@apache.org>
	 <456C59DB.1010305@apache.org>
	 <F3C57D0B-7CB4-410F-BF43-1CD33B833EBC@apache.org>
	 <456C768E.2030809@apache.org>

On 11/28/06, David H. DeWolf <ddewolf@apache.org> wrote:
...
> Perhaps I'm looking at this too selfishly, but I'm thinking that if
> nothing else the teams can help each other with the infrastructure and
> burden of being a TLP.  For example:
>
> - Moderating Mail Lists
> - Board Reports
> - Managing Jira
> - Community Oversight
> - etc. . .

and the burden of all of these grows with the size of the community.
true, it's not a linear curve, but i think the benefits of shared
interest in a codebase are superior to those of size.

> It seems to me like those types of tasks can take a lot of development
> time away from a small team. I've heard of PMC Chairs that are consumed
> by all of this overhead and stop committing code.  I don't ever want to
> get to that point and it seems possible considering the fact that there
> are only 3 of us - 2 that currently commit code.

this is especially prone to happen when the scope of the PMC is too
big.  too much to oversee and keep track of.

> That said, I do think there's much more potential for commit overlap
> than you give credit. Simply having access to the repo of a sister
> project might spawn some interest.  I know that I'd be apt to dive into
> FileUpload or WebParts if I had commit access.  I've used both before
> but haven't contributed because the burden was too much for the benefit.

it might, but i'd advise against counting on cvs access alone to spur
involvment.

> At the same time, while I'm sure Dimensions or Scopes are great, I just
> don't have the need for them right now.  And because of that, I'd be
> less apt to contribute.

true, but those interested in dimensions or scopes (i'm assuming
they're Tiles-dependent here) are much more apt to contribute to
Tiles.  and those who already know Tiles should be much more capable
of jumping in on dimensions or scopes (being closely related projects)
than they are on FileUpload.  consider email: it should be easier and
quicker for a Tiles committer to follow email about a closely
related/dependent project than it is to follow emails about unrelated
ones like FileUpload.  lack of focus will cost all the developers
time, not just the PMC chair.

> In other words, I don't think it's "dependency" that makes people
> contribute, I think it's weighing the benefit against the burden.  If we
> lower the burden for key people, they may come to play.

in both cases (Dimensions/Scopes vs FileUpload/WebParts) you are
talking about lowering the burden equally from an infrastructure point
of view, so that's a moot point.  and the conceptual burden of
contributing to a dependent project (Dimensions/Scopes) is already
lower than that of an unrelated project (FileUpload).

so, it's only the benefit side that is really in question here.  as to
that, investment in a project dependent on Tiles leads to investment
in Tiles much more often than investment in FileUpload would.  yes, in
the other direction (starting with investment in Tiles, like you, and
looking at Dimensions/Scopes), the benefit is highly personal and thus
essentially arbitrary, but it still seems more likely (due to the
lower conceptual burden).

take the umbrella metaphor itself:  umbrellas are much easier than
tarpaulins to manage because they have a specific, central pole to
which all the rest is firmly connected.  likewise, putting Tiles,
FileUpload, etc together in one project may have some benefits but is
going to be hard to manage effectively and move forward together
(Jakarta Commons and Jakarta itself are examples of this).

>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org