DMB nominations, size and quorum

[Lukasz Zemczak]

Hey,

Sorry for replying just now. This was on my plate since a while but I
was just pushing it for later all the time.

As per our discussion on IRC, I would be more keen to just decrease
the number of DMB members instead or changing the quorum system. Also,
what would I really personally prefer being done is making sure that
the current people on the board are available for board duties. e.g.
maybe introducing some practices that would allow deprecating inactive
members and looking for new ones faster.
It's hard for me to put this to words, but my general thought is this:
if we have problems in getting quorum during meetings, the right way
to solve the problem is not changing the rules of how quorum is
counted or even how many board members are there, but the solution
should be searched for in making sure we have active DMB members
instead. So let's say we have a situation like now that usually we
have 3 max 4 people on meetings - in such cases we should instantly
reach out to the people that are not present, make sure they declare
if they're still willing to participate or not and, in cases when
needed, remove them from the DMB for inactivity and start looking for
new nominees.

I know it's just easier to change the rules, but it's really just
absurd that we have to find ways to work better with inactive people
on the DMB. That's not what being part of the board should be about.
Members are either in and participating or should not be in the team.

Cheers,


On 31 July 2017 at 16:17, Robie Basak <robie.basak at ubuntu.com> wrote:
> On Fri, Jul 21, 2017 at 01:31:34PM -0700, Brian Murray wrote:
>> If I'm understanding this correctly right now we have 7 people in the
>> DMB and our new quorum would be 3, with that it is possible that
>> somebody could become an Ubuntu Core Developer with only 2 votes and
>> with 4 people not voicing an opinion at all?
>
> Correct - this is what I'm proposing.
>
>> with 4 people not voicing an opinion at all? Presumably the members were
>> added to the board because other Ubuntu developers value their opinion
>> but with the new system we wouldn't be taking them into account.  I'm
>> not sure how I feel about that.
>
> I understand how this causes you concern, and I agree in principle with
> what you're saying.
>
> With my proposal, I'm putting the need to make progress ahead of this
> concern. If Ubuntu developers are unhappy about this, they should vote
> for DMB members who are more likely to attend.
>
>> That being said if we go down this route I wonder if we shouldn't shoot
>> for a unanimous vote of the 3 people present, for applications only, and
>> if it isn't then take it to the mailing.
>
> If everyone can agree on this, I'd be happy to accept this as a
> compromise. I think the common case is that we're unanimous, so this
> variation would help, except in cases where only one or two members
> attend a meeting, which IIRC is rarer.
>
> Let me try to re-state this to make sure there is no confusion. This
> alternate proposal would be this addition to the existing rules:
>
>     An IRC meeting can proceed in considering applications without
>     quorum. If such a non-quorate meeting votes on an application and
>     the outcome is unanimous and with at least three +1s, then the
>     application shall succeed as if the meeting had quorum.
>
> Assuming we're continuing to define quorum as (n/2) rounded up, do you
> intend the 3 as a constant or as some function on n? Or would you want
> to re-evaluate this amendment if the DMB size changes?
>
> On Mon, Jul 24, 2017 at 11:01:08AM -0400, Mathieu Trudel-Lapierre wrote:
>> I concur, and for that reason I disagree with the proposal. It could
>> already be argued that the decisions are made arbitrarily when only a
>> fraction of the DMB ever shows up to the meetings. I'd be in favour of
>> reducing the number of people on the board (and strive to do better at
>> making it to the meetings), but not making quorum easier to achieve. We're
>> many people on the board precisely so we can reach that quorum of 4; and
>> that allows us to remove one or two people from the total number of people
>> on the board, if all of them do show up.
>
> My understanding is that quorum is defined as (n/2) rounded up, rather
> than by being fixed at 4 with more DMB members on the board to help us
> achieve it. But if you're proposing to change the size of the board
> while leaving quorum fixed at 4, then I'm OK with that in principle.
> I think we'd need to define rules about how we handle a split vote, as
> it would introduce some edge cases which do not exist today.
>
>>                                          Being absent once in a while is
>> fine, never showing up questions your will be sit on the board.
>
> I'd prefer to try and address issues (such as meeting timing) that are
> stopping board members attending first.
>
>> > That being said if we go down this route I wonder if we shouldn't shoot
>> > for a unanimous vote of the 3 people present, for applications only, and
>> > if it isn't then take it to the mailing.
>> >
>>
>> I know it's hard to get people involved in the DMB in the first place, but
>> we should already be shooting for unanimous voting to add a new developer.
>> When the board isn't unanimous, it brings into question whether the
>> prospective developer is involved in the community in general, or in the
>> quality of the contributions (obviously, depending on the actual request).
>> In other words, someone wanting to get core-dev should be an easy,
>> unanimous vote most of the time.
>
> I agree in general with this statement, but I'm unclear as to what
> you're proposing. Are you saing that we should change the rules so that
> core dev applications are only approved if the vote is unanimous?
>
> What's your position on Brian's suggestion?
>
> Robie
>
> --
> Devel-permissions mailing list
> Devel-permissions at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/devel-permissions
>



-- 
Łukasz 'sil2100' Zemczak
 Foundations Team
 lukasz.zemczak at canonical.com
 www.canonical.com