----- Original Message ---- > From: Martin Hollmichel <[email protected]> > To: [email protected] > Sent: Wed, June 15, 2011 2:50:46 PM > Subject: Re: [discuss] remove of binfilter module > > 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.
At the ASF being a committer takes on a more general meaning than simply being another code developer. There are lots of ways to contribute meaningfully to the non-coding aspects of a project in areas of the ASF that are only available to people with committer karma. > 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 ? > > 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, The primary focus at this particular point in incubation is to create enough effective "feedback loops" so we can say the project has the ability to construct a self-sustaining development community. (The "dev" in [email protected] is short for development, not developer. There are lots of additional "development" roles in a project of this size than the traditional coding role of a committer.) Since much of the basic infrastructure of the project is already operational on the openoffice.org site, we can continue to use that as additional resources come on line at the ASF. Over the course of incubation I trust we'll be able to migrate all of the "collaborative" services to ASF hardware, so things will only improve over time. But to Sam's earlier point, it's up to the people on this dev list to drive and steer the overall activity thru consensus. At some point mentors will try to take a back seat and let the community take full control over its destiny.
