xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shane_Curc...@lotus.com
Subject Re: [VOTE] Proposal: new xml-commons subproject for standards-based files: comments to Dirk
Date Tue, 24 Apr 2001 22:01:24 GMT

Thanks Dirk - but I didn't see your vote!  Don't we at least get your +0
show of support? 8-)

---- you <dirkx@covalent.net> wrote (in several parts) ----
> Looks like a very good inititiative; just some general points/reminders:
(blush) Gosh, thanks.  Copied the structure from the jakarta-commons
proposal, so I can't take all the credit.  8-)

---- you <dirkx@covalent.net> wrote (in several parts) ----
> 1-       It is easy and good to create such sub projects - but they
>          need to be staffed. People need not to be only behind it, but
>          also actively work on it.
> 2-       Generally, (and historically in the httpd workd - where those
>          voting things come from) if you give something a '+1' (rather
>          than silence, a 0 or  a +0) you are expected to carry some of
>          the burder of what you voted for - and some responsibility
>          for keeping that project alive.
(Excellent point: I'm looking forward to seeing each and every person with
a +1 vote putting commits in soon!  ;-)

> So think carefully as to where you want things to go. Each extra
> components meeds a thinning of the pool of developers, not only to work
> code, but also building, qa, testing and release engineering.
----and wrote----
> What makes a project fly are a couple of things
> -        People behind it; to write code, manage CVS, manage
>          mailing list, foster a comminity, do release engineering.
>          -> this is really the responsiblity of the people driving it,
>          (and your '+1' vote makes you a little part of that :-)
This is definitely a concern, I'm glad you raised it.  This is especially a
concern here, where the first code 'donation' will really be some
externally defined standards that aren't really meant to be changed much/at
all.  While normally this might not be a very active project, I firmly
believe this will be successful for a number of reasons:

- We've had a bunch of people clearly and heartily in support of it, and I
know many of them will be active in forming this community.
- Looking at jakarta-commons and seeing traffic on general@xml and other
xml lists, it's clear that we'll have more stuff to add and design in
xml-commons in the very near future.
- This project should return obvious benefits to multiple other xml
projects, both for internal development and external users; this will help
drive more xml committers to spend time on xml-commons to help even more.
A significant part of this project is also about driving better
cross-xml-subproject coordination as well, which will keep us in all
xml-ites minds regularly.  This is clearly an itch, and we have a good
scratch for it here.
- Oh, and I'll clearly be there to get things started.

I guess one of the first big wins for me will be forming the community
itself: I'm hoping that having this focused area to talk about common xml
tools/utilities/packaging will make it much quicker and more effective to
develop good stuff and good cross-project coordination.

---- you <dirkx@covalent.net> wrote (in several parts) ----
> No worries - This is the right approach. Anyone can propose projects -
> general@ is the right place (with perhaps a Cc/warning to the appropriate
> existing lists which are potentially affected).
Yup, we'll need announcements, and then we'll need to get some consensus
from the various xml projects once we have common packaging proposals and

---- you <dirkx@covalent.net> wrote (in several parts) ----
> -        If there is overlap or interaction with other projects -
>          some consensus amongst all involved that there are no
>          conflicts and that any fragementing of the developer
>          base and other collateral damage is overcome by better
>          focus or synergy. I.e. the whole XML project needs to
>          be a little better afterwards.
>          -> this is something for everyone to flag - and for the PMC
>          to bear in mind.
It will certainly be a new challenge, but I hope this will be a cleaner way
to get better cross-xml coordination.  It seems like the dedicated
xml-commons community will be able to hash through some common internal and
external packaging issues to get to good, solid proposals (with code to
show them); we can then take these as concrete proposals to each of the
other xml communities in turn.  Hopefully this will both result in better
proposals to start with, and make it much simpler for the individual
communities to see the ideas more clearly and to be able to reach their own
consensus with the commons more quickly.

(Hmm, I'm getting a bit wordy here.  I guess one way to look at it is this:
it's like when you have a really big team trying to get 10 things done.
There's no way you can have an all-team meeting to discuss all the issues
at once.  Instead, you form 10 smaller task groups (or whatever) of smaller
communities to propose specific plans for each area.  Each small group has
the focus to really dive into their issue and come up with focused
proposals that can be brought back to the whole group in an organized and
targeted manner.  Make any sense?  Basically xml.apache.org is the whole
team, and xml-commons is a task group to work on packaging and coordination
between them all)

---- you <dirkx@covalent.net> wrote (in several parts) ----
> -        The project needs to fit within the charter and scope of the
>          XML project - which is to provide commercial-quality
>          standards-based XML  solutions that are developed in an open and
>          cooperative fashion, to provide feedback to standards bodies
>          as IETF and W3C) from an implementation perspective, and  to be
>          focus for XML-related activities within Apache projects
>          -> and this is something where you run into the ASF board  when
>          you grossly overstep those bounds.
Certainly fits within the charter, IMO.  It should actually make it much
easier to provide the feedback, since some of the standards-related code
will be focused in one place, so not only can individual teams provide
implementer feedback (i.e. Xerces can comment to W3C about how DOMs are
built) but also to provide a wider
standards/packaging/implementation/integration level of feedback
(xml-commons will be able to provide feedback about using DOM in several
different apps simultaneously).

---- you <dirkx@covalent.net> wrote (in several parts) ----
> When proposing a new project (and preferably before calling a vote) make
> sure that you have a list of 3-5 people who will sign on, who are the
> initial commiters, mailing list managers, etc,etc. As that is what the
> needs to carry things further, get the logistics done etc.
The current vote indicates that we'd like all existing xml-subproject
committers to be the initial committers, which seems a little unusual but I
hope the PMC will approve it.
Of all the xml committers, I feel confident that we have a good half-dozen
people who will be active and can help manage mailing lists, etc.,
including myself.  But perhaps I shouldn't assume - maybe some of those
people who gave this proposal their +1 will step up again and assert
they'll help out with the organization, etc. explicitly...

- Shane

In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

View raw message