httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Ralf S. Engelschall)
Subject Re: guidelines
Date Wed, 01 Apr 1998 09:58:29 GMT

In article <> you wrote:

> The only way the Apache Project can make decisions without bursting
> into flames is if EVERYONE abides by the project guidelines.  If the
> guidelines aren't working in the best interests of the project, then
> propose a change.  

I think the guidelines are ok in general, Roy, except these two points would
be good IMHO to be included (to avoid misunderstandings in the future):

1. The statements that really everyone has the equal right to veto in general.
   Although my coders heart says something like Dean said (~ "those who do not
   code should be a little bit more quiet then those who do") I think it is
   needed because it's just fair teamwork. I always hope that those who to not
   actively contribute code are a little bit less restrictive to the users who
   do, without the need to express this. They should think for theirself if
   they make the others life harder then it should be.

2. The statements that although a veto can be done at any point if it gets
   done more then approximately two weeks after some stuff already went in or
   was changed, the guy who vetoes really  _HAS_ to provide a reasonable
   alternative solution idea _AND_ at least someone (not really the guy who
   vetoes) who wants to volunteer for this alternative solution.  Or the veto
   will not make much sense IMHO at this stage and always just creates
   flamewars! I think only this way it's fair.

3. The statements that although there are strict guidelines about
   how we do development and releases we _NEVER_ should forget that not these
   guidelines are the fact why we create Apache releases; we create them for
   the _USERS_ of Apache. As a consequence when we have something at hand the
   users really want, expect or at least would really like (e.g. APACI) we
   should not follow our guidelines too strict as long as we gain more by
   giving the stuff a chance instead of following the guidelines.  It's clear
   that guidelines are important to coordinate our development and to ensure
   that our releases are stable, etc. But sometimes (perhaps this time again
   for the symbol renaming!) we should realistically weight about the actual
   advantages and disadvantages. 

                                       Ralf S. Engelschall

View raw message