incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: [discuss] remove of binfilter module
Date Wed, 15 Jun 2011 19:11:28 GMT
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
>> <martin.hollmichel@googlemail.com>  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

Mime
View raw message