commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <mart...@apache.org>
Subject Re: Problems...
Date Sun, 05 Mar 2006 19:00:50 GMT
On 3/5/06, Dennis Lundberg <dennisl@apache.org> wrote:
>
> Henri Yandell wrote:
>
> <snip/>
>
> > We have a very noisy set of mailing lists. Need to ask how the Jive
> > forum is going for Struts (I think I heard that was in place?).
> > Watching how the Maven-dev move to separate lists for commits, jira,
> > dev, ci goes.
>
> Here are some views on mailing list noise from someone who has only
> recently become a commons committer. I am also somewhat involved in
> Maven without being a committer.
>
> I think that the sheer volume of traffic on commons-dev is a big hurdle
> for people wanting to get more involved with commons. This is from my
> own experience. The lists that we have today are suitable for users
> (commons-user) and committers (commons-dev). As i see it, there is a
> couple of more steps in between, in the natural progression from user to
> committer.


The important thing to bear in mind here is that, to a very large extent,
commons-dev *is* the Jakarta Commons community. Meddling with that, for
example by breaking up the list, is walking a tighrope.

1. Someone becomes interested in using a commons component, we'll take
> commons-lang as an example. The user starts using it and maybe has a few
> questions, so the user joins the user-list.
>
> 2. The user realizes that this is good stuff and starts to wonder how
> they accomplish this, so the user joins the dev-list. Note: this is
> where it usually ends because the user can't handle the volume of mails,
> so he/she just unsubscribes from the list and continues to be a happy
> user.
>
> 3. If we had a list where discussions on organization, methodology and
> design issues were available the above user might become more interested
> in the Apache way and stay if the traffic was reasonable. This would be
> the current commons-dev list without some extra baggage, see more below.
>
> 4. As the user becomes an involved user he or she might want to create
> an occasional patch for StringUtils or something. The involved user
> files an issue, attaches a patch and feels warn and fuzzy inside when
> the patch gets accepted. The involved user wants this feeling to last
> and joins the issues-list, where all bugzilla and jira issues are sent,
> looking for more to do.
>
> 5. The involved user is starting to wonder how those committer do their
> coding and joins the commits-list to see what everyone is doing and how
> they do it.
>
> 6. Time passes and the person gets more involved and is elected as
> committer. This means more responsibility and the person now has to
> worry about things like CI (GUMP) and subscribes to the ci-list or
> build-list (haven't got a good name for this one)
>
>
> Where does that leave us? If we create a couple of more lists I believe
> that we would attract more involved users. So my suggestion is to have
> these lists:
>
> commons-user
> commons-dev (includes the wiki stuff)
> commons-issues
> commons-commits
> commons-ci (perhaps with a better name)


Breaking out these pieces is trivial to do with mail filters, which, as you
mention below, people will still need to master anyway. If someone wants to
be only partly a part of the community, they are free to filter whichever
pieces they don't want directly to /dev/null. I'm not in favour of splitting
the list this way as a solution for people who can't grok their own mail
filters.

--
Martin Cooper


Subscribe all current commons-dev subscribers to the new lists
> commons-issues, commons-commits and commons-ci. Then announce the
> separation of lists on commons-user and invite folks to join in.
>
> Subscribers will still need to master their mail filters though.
>
>
> <snip/>
>
> --
> Dennis Lundberg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message