TB: Urgent Escalation of DMB Member Removal / New Vote Decision due to DMB Stalemate

Tue Feb 8 09:06:52 UTC 2022

Hello!

It simply feels to me that the new attendance regulations need to be
modified to take pre-notification in mind. I personally don't think
it's good if we're relying on something being 'obvious' or 'implicit',
since interpretations of words can vary, feelings can vary and
attitude to given circumstances can vary. I agree that removing
someone without notification might be a breach of CoC, which is why I
think the DMB should re-visit changing the rule-set. It's not that big
of a deal, sometimes one misses certain cases and it is good to
re-iterate and evolve a concept.

I would propose that the DMB votes on adding a paragraph about sending
out a warning e-mail to DMB members that are about to be removed from
the team, similar to the regular membership expiry handling - possibly
a week before that happens. After that, if there is no answer, the
expiry would happen automatically as mentioned in the current rules.
Maybe an additional paragraph about sending out an e-mail that the
person which membership in the DMB expired so that there is nothing
that needs to be interpreted 'implicitly'. So this would be my
proposed way forward.

As for the current 'stalemate', if I'm asked for an opinion: the truth
of the matter is that the ratified rule regarding attendance does not
include any mention of e-mailing DMB members that are to be expired,
as I do not consider implicit meanings having power in such
situations. With this in mind, I understand Dan's position on
proceeding with the elections, as the DMB is currently 'low' on active
members it seems. I also agree that the current ratified rule is not
very 'respectful' (which is also a bit of a rule that carries multiple
interpretations, making it quite implicit), but then again: the
attendance rule was *publicly* discussed for a longer period of time
and officially voted on. Any members that could have any reasons to
disagree had the time to disagree and discuss at that time. Sure,
there might be legitimate reasons for their absence, but if there were
they could have reached out to other members earlier after the rule
has been ratified. Maybe only now they have time, yes, but as you see
it's just a moving timeframe that can always be moved for reasons. As
we see for automated expirations via Launchpad, even with earlier
notifications people just miss those and can simply get back to us and
'request re-adding' - happened to each of us. I consider this a bit of
a similar case.

Either way if a DMB member has been inactive for 12 weeks, 6
consecutive meetings, this sadly shows lack of involvement in the DMB.
What I would propose, before any policy amendments (as recommended
above) are done, is to send out an e-mail to the 'expired' DMB members
about what happened and then proceeding with steps as outlined (so
starting the election). In the way the policy is formulated, if a DMB
member does have concerns and reasoning that they would like to share,
they can do so in the period when the call for candidates to the new
election is started. If one of the expired members comes back to us
with a very strong reason for still staying in the DMB, the election
preparations can be halted and re-discussed. Otherwise, if the expired
members had other reasons and would like to still 'try and continue',
they can re-apply for election, and can be re-elected if the community
feels they should.
An e-mail informing them of the situation, the policies that have
applied and ways to go forward feels to me like a good way to still
stay 'respectful' while abiding the policies and respect to our
community (as having inactive DMB members feels disrespectful to our
community in a way as well).

I think this situation is a bit unfortunate. I basically understand
both sides of the argument and personally, as a member of the DMB, I
wouldn't mind either way really. But since there is such a *strong*
disagreement between the sides and I *have* to make a call, I go with
following the explicitly defined policy. But as said: it's not a
strong statement. Other TB members should probably chip in their 5
cents, if possible.

Cheers,

On Mon, 7 Feb 2022 at 23:06, Robie Basak <robie.basak at ubuntu.com> wrote:
>
> Thank you Thomas for stepping in to mediate in the meeting and for your
> time in writing this up.
>
> On Mon, Feb 07, 2022 at 12:34:07PM -0500, Thomas Ward wrote:
> > Robie Basak is against any action until both aforementioned individuals have
> > had a chance to respond before we remove them. He is also of the position
> > that any response from the absent members would not necessarily affect any
> > decision on their removal, however Robie is of the opinion that all
> > individuals must be contacted first and must have a chance to respond before
> > we simply remove any absent members.
>
> Wearing my DMB hat:
>
> I'm simply saying that it's inappropriate and disrespectful for someone
> to find out that they've been removed from the board by reading a call
> for nominations for their (now vacated) seat, or from an automated email
> from Launchpad. Therefore we must contact them privately first. This is
> particularly important in this case since it's their very absence that
> triggered this action, so they're more likely to be unaware of it.
>
> I didn't think that the DMB's (passed) motion ("...shall be considered
> inactive and removed from membership in the DMB") meant that this would
> happen with no other contact with them. I had assumed that a requirement
> to do this respectfully was implied. And procedurally, the DMB can't do
> anything that violates the CoC anyway, so *if* you agree that removing
> them without further contact is not the respectful thing to do, then how
> the DMB's passed motion is to be interpreted is moot. So I think the
> only question that needs to be answered here is: "what is a respectful
> way to proceed?"
>
> I don't think contacting them is hard; nor that giving them time to
> respond (say a week) makes any difference in the grand scheme of
> progress[1]. It's simply the respectful thing to do. So I'm surprised
> that Dan pushed back so hard on this that it had to be escalated. I do
> appreciate his impatience, since DMB absenteeism has been a practical
> problem for many years. But I don't think that excuses our duty to treat
> everyone well, especially members who aren't being paid to support their
> activities in Ubuntu. It turned out that they weren't able to contribute
> the time. We should be grateful and thankful for what they could
> contribute, not treat them badly now.
>
> To be clear, I am in general in favour of the principle of having
> absentee DMB members be required to step aside. It is just the
> disrespectful manner it is proposed to be done that I am objecting to.
>
> Wearing my TB hat:
>
> I was asked if I was going to recuse myself and abstain from any TB
> decision. I'm not sure that makes sense here. This isn't about me. I'm
> involved only because I object procedurally. I don't stand to benefit,
> nor have any friends or associates benefit, from any TB decision. Were I
> not also on the DMB, I'd still object to Dan's proposed course of action
> wearing my TB hat only. So for now I am not recusing myself, and
> obviously I am in favour of my own position. However if anyone wants to
> argue that I should not participate further, I will consider that
> argument carefully.
>
> Robie
>
>
> [1] I say that they should be given the opportunity to respond because
> 1) people make mistakes; and 2) there may be a valid procedural
> objection they wish to make. This gives an opportunity for that to be
> considered, and corrected if necessary, before damage to personal
> reputations is done. It is not my intention to extend an invitation for
> them to remain on the board despite their previous absence; that time
> has already passed.
> --
> developer-membership-board mailing list
> developer-membership-board at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/developer-membership-board

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