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

Tue Feb 8 12:51:48 UTC 2022

On Tue, Feb 8, 2022 at 4:07 AM Lukasz Zemczak
<lukasz.zemczak at canonical.com> wrote:
>
> 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.

This is the core of my difficulties with this situation; the time to
raise objections or propose adjustments to the policy was 3 months
ago, not now. Imposing unwritten personal opinions into the written
process is the wrong way to address disagreements with policy. Any
problem with the existing policy should be discussed and voted on, as
with any policy; but until the policy is changed, it needs to be
followed.

> 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.

Just to be clear on my opinion - and it's only opinion - I have
absolutely no problem whatsoever with directly emailing members before
removing them, and if that had been raised during the discussion of
the rule I would have agreed without any reservation and updated the
wording of the rule process. However, I didn't even think to include
such language when I proposed the rule wording, because I find it hard
to believe that members of a team with regular meetings who do not
participate in any way in the team activities for over 3 months,
including public explicit discussion about removing non-participating
team members, would be surprised about being removed from that team.

What I think is truly unfortunate about all this is that both these
members are 100% aware they are not participating, they are both 100%
aware they will be removed and replaced, and this delay and escalation
only serves to publicly highlight their lack of participation. If we
had simply proceeded with the call for nominations to fill their
seats, it's very likely that few people would have even realized the
seats were empty due to non-participation of members.

Once all this mess is decided on, someone else on the DMB can handle
the call for nominations and election for the empty seats. I'm going
to step back from DMB work for a while, and let the rest of you chair
meetings and handle action items.

> 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
>
> --
> technical-board mailing list
> technical-board at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/technical-board