commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [DISCUSS] Mission Statement for Commons...
Date Sun, 06 Oct 2013 18:54:48 GMT
On 10/6/13 11:30 AM, James Carman wrote:
> All,
>
> The Apache Commons project seems to be languishing as of late and we
> need some rejuvenation.  Perhaps we should try to define our mission
> as a project.  What are our goals?  What do we want to accomplish?
> Who are our users/customers?  What non-functional qualities do we want
> our software to exhibit?  How do we want to conduct ourselves?  How
> often do we want to do releases?  What else?

I would say the first two paragraphs under "The Commons Proper" on
the home page [1] state what I have always understood our mission to
be - basically to be a place where reusable Java components are
developed @apache.

We have always really been a loosely federated group of
subcommunities around the individual components, with a fair degree
of autonomy among them.  I have always personally liked that.  Other
than things like the commons parent pom and the PMC itself, the
individual components aren't bound by too many rules or
standardization.  What exactly the components need to do depends on
the component and how often releases are cut depends on the level of
activity on the component and/or needs of users.

Our users come from all over the place - inside the ASF and
increasingly outside.  Our main goal should be to attract more of
them into sustained contribution to the components.  This is hard in
some cases because there is little / no activity on some components
and in some cases we make it harder than it should be for users to
get involved even on the components where there is active
development going on.

I think we would benefit most from three things at this point:

0) Agreeing on what components are dormant and marking those as such
1) Getting a clear understanding of what the real and perceived
barriers are for getting involved as a contributor (note this is not
the same thing as "getting patches committed" though the two are
related)
2) Finish fixing and documenting the build and deployment process so
that cutting releases is easy

OK, that is about my 2c worth :)

Phil

[1] http://commons.apache.org/
See also: http://commons.apache.org/charter.html
>
> Sincerely,
>
> James
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


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


Mime
View raw message