Board Single Point of Failure

[Toshio Kuratomi]

On Wed, Apr 18, 2012 at 5:10 PM, Toshio Kuratomi <a.badger at gmail.com> wrote:
> The draft is here:
>
> https://fedoraproject.org/wiki/User:Toshio/Board_single_point_of_failure
>
> Although not exactly a work in progress, this is by no means set in stone.
> Feel free to read, comment, and suggest alternatives to address the issues
> brought up on either of the two pages.  Depending on how much people want to
> change here, the Board will discuss and possibly vote on adopting those
> guidelines at their next week's meeting.
>
We discussed this in the meeting last week and in general were not
happy with it in several ways.

* There was a general feeling of getting over-bureaucratized
* It was mentioned that these guidelines are largely things we think
we should be doing anyway -- and it was countered that we all feel
that yet aren't succeeding.
* Some people were nervous about allowing votes of less than quorum in
these cases.  Other people countered that we generally trust Board
members.  Other people noted that the inability to get quorum when
there's not explicitly a meeting is the problem we're trying to solve.
* If we aren't committed to making this happen, it probably won't
happen despite having it as policy (see what happened with the
commitment the Board made to update all of its tickets once a month,
for instance).
* I raised the possibility of just keeping the procedure for making
quick followup decisions as a means of putting more power into the
hands of those who are working on the implementation and desire to get
things done and striking the rest of the draft.
** It was mentioned that doing this in the Board ticketing system was
less than ideal due to Board tickets being private by default.  The
idea was put forth that the ticket submitter would need to alert
people to the outcome.

No one had concrete ideas for changing the draft other than reducing
it to only the procedure for quick followups and we decided to ponder
the problem and proposed solution some more.

We'd appreciate constructive discussion on this -- treat it as a
strawman to start generating ideas but see if you can come up with
something better/more likely to succeed. We'll be discussing this at
next week's meeting (hopefully with some better ideas by then :-)

-Toshio