On 15/06/2011 19:50, Martin Hollmichel wrote:
On 06/15/2011 07:59 PM, Sam Ruby wrote:
On Wed, Jun 15, 2011 at 1:17 PM, Martin Hollmichel
<[email protected]> wrote:
On 06/15/2011 12:45 AM, Raphael Bircher wrote:
Am 15.06.11 00:15, schrieb Ivo Hinkelmann:
Hi Christian,
good idea to remove it, preferred the whole module. It saves us a lot
of build time!
Build time no matters in this case. No user will understand this
argument. And the question is for wath we are here. To make a good
product for end user, or to play around with code?
this raises a good question: how to make Product Management decisions ?
The past has shown, that decisions driven by one main contributor are
not necessarily the best ones. I'm wondering how can we establish
something like a voting system for doing the right or at least good
decisions. I also think, the one contributor - one vote thing also don't
work out in this user centric matter (I think it will work well for
engineering centric questions). We need something to identify good
representatives of user communities to be able to do good decisions.
As QA I can't accept to remove samething to save Build Time, sorry.
Byside you can dissable binfilters if you build samething who does not
afffect the binfilter.
It's important to bring the interests of all groups, engineering, QA,
marketing and users to a common ground. This raises also the question
which priorities are driven by whom, and how they get represented by whom,
Short answer: don't vote! Yes, we want to include everybody!
I canot agreed more, ...
Here's a few links:
http://s.apache.org/H8J
http://s.apache.org/D16
http://community.apache.org/committers/
... but these links don't really help me, since the OOo community and
it's ecosystem(s) are much more than committers.
Perhaps you didn't read the resources mentioned carefully enough. None
of those talk about committers making decision, they talk about
consensus in the community. Everyone is a member of the community: e.g.
From http://community.apache.org/committers/lazyConsensus.html:
"Sometimes a member of the community will believe a specific action is
the correct one for the community but are not sure enough to proceed
with the work under the lazy consensus model. In these circumstances
they can state Lazy Consensus is in operation."
From http://community.apache.org/committers/consensusBuilding.html:
"In some cases there is no obvious path to take, or you might be a new
community, or a new member of an existing community. In these cases
people will often need to build consensus by making proposals and
eliciting responses."
"Once there is a clear consensus members of the community can proceed
with the work under the lazy consensus model."
Ultimately it is committers who have the power to commit patches or make
a given proposal reality, but that's doesn't mean that the committers
(alone) make the decisions.
Now that we are out of the proposal phase and the mud slinging is
(mostly) done with I'd like to remind the community here that *all* ASF
projects have end users who are not committers. OO.o is not unique in
this, despite what some might have said during proposal stage.
The processes adopted in other ASF projects have been shown to work for
a very long time. They are deliberately loose in their definition to
allow individual projects to develop their own personality, but they do
work.
The main objective is to bring as many developers as possible into the
projects, many small and some big players in the Ooo market are able to
do this. The key is, how do we listen to all the small players in the
OOo market to enable them to contribute to OOo via committers ?
Yes - that's exactly what The Apache Way is designed to do. One of our
motto's is "Community before code".
If, after reviewing the items linked above, you have a specific concern
please raise that specific item. Generic statements like those linked
above won't cover every circumstance you are going to encounter, but
chances are one or more of the mentors will have been there before.
There are now a few big ones (IBM, SuSe, Redhat, RedOffice, etc) in the
arena, but how will we enable the thousands of small catalysts (see
http://bizdev.openoffice.org/consultants.html) around the world to
become part of the community. I think we shouldn't ignore them,
We most certainly should not ignore them. If they come to this list and
participate then their voice will be a part of the consensus building
process.
Voting has the opposite effect. It allows power structures to build. At
the ASF we really don't like power structures.
Ross
