All,
   Sorry for the long pause on bylaws discussion. It was a result of
wanting to avoid the long US holiday week (July 4th) and my
procrastination, which was furthered by a side conversation that asked me
to consider how to move forward in an Apache way.
  I'd like to thank Jack for moving this to this point. One concern that I
had was there were lots of discussions and decisions that were being made
off of our email lists, which isn't the way that Apache should work.
  For finishing this off, I'd like to come up with a set of questions that
should be answered by multiple choice questions and then use single
transferable vote (STV) to resolve them. STV just means that each person
lists their choices in a ranked order with a formal way to resolve how the
votes work.
  The questions that I have heard so far are:

   1. Should the PMC chair be term-limited and if so, what is the period? *In
   my experience, this isn't necessary in most projects and is often ignored.
   In Hadoop, Chris Douglas was a great chair and held it for 5 years in spite
   of the 1 year limit.*
   1. No term limit
      2. 1 year
      3. 2 year
   2. What should the minimum voting period be?* I'd suggest 3 days is far
   better as long as it isn't abused by holding important votes over holiday
   weekends.*
   1. 3 days (72 hours)
      2. 7 days
   3. Should we keep the section on roles or just reference the Apache
   documentation <https://www.apache.org/foundation/how-it-works/#roles>. *I'd
   suggest that we reference the Apache documentation.*
   4. I'd like to include a couple sentences about the different hats at
   Apache and that votes should be for the benefit of the project and not our
   employers.
   5. I'd like to propose that we include text to formally include censor
   and potential removal for disclosing sensitive information from the private
   list.
   6. I'd like to propose branch committers. It has helped Hadoop a lot to
   enable people to work on development branches for large features before
   they are given general committership. It is better to have the branch work
   done at Apache and be visible than having large branches come in late in
   the project.
   7. Requirements for each topic (each could be consensus, lazy consensus,
   lazy majority, lazy 2/3's)
   1. Add committer
      2. Remove committer
      3. Add PMC
      4. Remove PMC
      5. Accept design proposal
      6. Add subproject
      7. Remove subproject
      8. Release (can't be lazy consensus)
      9. Modifying bylaws

Thoughts? Missing questions?

.. Owen

Reply via email to