comments on board reorg ticket comments so far....

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Just collecting and responding to some specific thoughts from
<https://fedorahosted.org/board/ticket/9>, rather than cluttering that
ticket with discussion. Note that these aren't by any means all of the
comments -- please see the ticket for that.
  
   
Eric Christensen (sparks):
----

> * Flock proposal with members coming from the projects within the Project.
> * FPL does not have final say.

Can you elaborate on this? It sounds an awful lot like "C" to me, but you
voted -1 to that.

> * Concern: SIGs can be negated and could mean that change could never come
> to Fedora as those in power have the choice to not reduce/remove their
> power.

As I understand this, the worry is that a model where seats are tied to a
specific "Fedora org chart" could make it hard for new groups to get a
voice. I think there are number of ways we could deal with that formally,
including at large seats or even a council position focused on "emerging
interests". But I'm also not strongly concerned about this as a problem: as
always, the most power in Fedora comes from working with other people to get
things done, and the council/board *should* be flexible based on where this
is happening. (So, yes, let's make sure we make that adaptability part of
the plan.)


Neville Cross (yn1v)
----

> * B: I think that two bodies may not be the ideal solution on the long
> run, but I see it as a very good step in the general direction that we
> want to achieve: productivity. Is good because is a small step and will
> give us something to try out without disrupting too much. It will be
> easier to balance elected and appointed people toward long term
> perspective and the task at hand. So the way of selecting who will fill a
> given position can be decided later. Two bodies means split the different
> resposabilities, but this also can be decided later. 

I don't actually have anything to respond to on this but I think it makes
the case well so I'm quoting it. :)

> C: I have the concern that this proposal need much elaboration on how
> people will be selected (to avoid words elected/appointed). FPL and the
> team will have all responsabilities. Having a good way to achieve the
> right mix of meritocracity and democracy will need to be resolvd before
> this option be pushed forward.

I agree that it needs that to be worked out — it's less inherently clear
than the other proposals. I also agree that meritocracy and democracy are
crucial ingredients in the mix, but I don't think that they are opposed on
an axis.


Garrett Holmstrom (gholms)
---

> * Proposal C needs to explicitly mention that someone can say "-1" when he or
> she believes an unannounced change needs review. Rollbacks are often not
> straightforward when one is not working with code.

Yes, definitely. And we should clearly set expectations towards open
communication as the default — situations where something is _suprising_ and
gets a -1 should be cause for reflection and better communication the next
time.


Christoph Wickert (cwickert)
----

> * A: Council should not only be advisory to the FPL but members should vote
> about issues. FPL strives for consensus, has the casting vote and veto
> powers. Basically just like today; I don't want to change the role of the
> FPL but I'm afraid the wording or the proposal makes it sound too
> powerful. 

To go back to some of the earlier discussion: I think governance decisions
work well with committee voting, when there are different options for
division of resources to be decided on. (Approving a budget, say.) But for
more active proposals, it ends up being focused on the bureaucratic process
of getting the vote to happen rather than on _doing_.

> * C: I think lazy consensus will work most of the times, but for a
> community of Fedora's size, 72 hours probably is not enough time to
> speak up. I'm afraid it will lead to a stronger dominance of people
> working on Fedora full-time (a.k.a. Red Hatters). 

Yeah, I think the time depends on how big the action is — 72 hours is just
an example. Some things need to be discussed and communicated over weeks or
months. On the other hand, I would hope that council members would be able
to at least say "Hold on — I need to think about this one some more" within
a few days.

> Last but not least a new and possibly crazy idea: Today the board is half
> elected and half appointed. How about a new body, that is half elected as
> today, but the other half is elected/appointed on a committee level? I
> think this would combine the advantage proposals the council (having all
> stakeholders in the group) with the board (democratic legitimization
> through election) and at the same time minimize the problems of lazy
> consensus (dominance of a few). 

Part of the problem here is number of seats. If we try to represent a
significant portion of Fedora's subgroups with group-selected positions,
we're probably _already_ at a council as large as the current board. Adding
an equal number of elected positions makes the council huge. (On the other
hand, with a lazy consensus model, this _might be okay_ — I notice that many
of the Apache PMCs are gigantic.)

Also, thinking kind of along those same lines, there's also the category of
"fixed positions" — like the FPL role, and a possible new OSAS liaison
position (working with the ambassadors and user community and the community
budget), and the example of a diversity chair we talked about at Flock —
these should be merit based (because.... that's better!) but in some cases
we might want to select them in a way other than soliciting subcommunity
representatives.

-- 
Matthew Miller
<mattdm@xxxxxxxxxxxxxxxxx>
Fedora Project Leader
_______________________________________________
board-discuss mailing list
board-discuss@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/board-discuss





[Index of Archives]     [Fedora Users]     [Fedora Outreach]     [Fedora Desktop]     [Fedora KDE]     [KDE Users]     [Fedora SELinux]     [Yosemite Forum]     [Linux Audio Users]

  Powered by Linux