Call for votes: Developer Membership Board restaffing
Dan Streetman
ddstreet at ieee.org
Tue Mar 29 13:19:31 UTC 2022
On Tue, Mar 29, 2022 at 8:57 AM Robie Basak <robie.basak at ubuntu.com> wrote:
>
> On Tue, Mar 29, 2022 at 06:14:27AM -0400, Dan Streetman wrote:
> > Where are the rules/policies written down about how elections should
> > be handled?
>
> The first time I ran an election I couldn't find much documentation at
> all, so I tried to follow what I could see of what had been done before,
> fixed up the voter email gathering code, and documented everything at:
>
> https://wiki.ubuntu.com/DeveloperMembershipBoard/KnowledgeBase#Running_a_DMB_election
>
> Note though that I documented what I considered to be best practice,
> based on what had been done before as well as feedback. It's not a rule
> or policy as such. Nor do I think it's necessary to be that.
>
> This time I'm mostly following that documentation, adapting as I think
> appropriate for the current situation (eg. three seats vacated, not
> because their terms expired, etc, required changes in wording).
>
> > We should have the process written down somewhere so there
> > is not ambiguity like this.
>
> In this case I don't think it would necessarily be appropriate to
> blindly follow a written rule or policy.
>
> The goal is to ensure that everyone considers the outcome to be fair and
> appropriate. It's not possible to have a written policy to cover every
> possible exceptional case. This situation is exceptional, and may
> warrant taking some exceptional action to ensure that we don't
> inappropriately exclude anyone. Ideally, if we did decide to handle
> something differently as an exception,
It really concerns me that so many of our processes are so ad-hoc.
Blindly following rules is obviously bad, but it's equally bad to have
to discuss every action and gain consensus. We shouldn't have to carry
on a discussion every time something unexpected comes up, and we
should have someone who is willing (and empowered) to handle minor
administrative decisions. I don't think most people actually care
about process administrivia, and IMHO introducting too much
administriva only serves to turn people off of contributing.
For example, in this situation; carrying out an election really
shouldn't be an exceptional event. The rules/policies for how to do
that should be clearly documented and one person should be able to
carry out the election without needing to guess about things, or
needing to have a discussion about how the election process should be
modified while the election is going on.
> we would all be unanimous about
> the appropriateness of doing that. This is why I'm asking for feedback
> here.
My feedback would be that this election should stick to the process
already in place at the start of the election. There should be no
changes to the process while the election is ongoing. If you think the
election process should change, that should be discussed, agreed on,
and documented. Then the next election can use the new process.
Can you imagine if a government decided to change the election process
during an election?
>
> On Tue, Mar 29, 2022 at 06:17:23AM -0400, Dan Streetman wrote:
> > On Tue, Mar 29, 2022 at 6:14 AM Dan Streetman <ddstreet at ieee.org> wrote:
> > Also, I think we should probably remove ubuntu-devel-announce from
> > this discussion?
>
> Agreed. I mistakenly included it in my previous reply and cancelled the
> post there after it was held for moderation. I've now cut down the Cc:
> list. I think it's fine to limit the discussion to ubuntu-devel@ as all
> nominees and the electorate are expected to be in here. Nonwithstanding
> deliverability problems, but I don't expect that to affect any other
> Ubuntu lists differently.
>
> Robie
More information about the ubuntu-devel
mailing list