Re: Call for votes: Developer Membership Board restaffing

[Robie Basak]

On Wed, Mar 30, 2022 at 01:17:52PM -0700, Brian Murray wrote:
> On IRC we talked about using the "Contact this user" feature of
> Launchpad. Did you end up getting many more votes after doing that?

Thank you for the suggestion!

Yes, although unfortunately I don't know if the votes were prompted by
that message, or just by the general ML traffic here on the topic, or
because it was close to the deadline.

The final count is 48/174 which I think is comparable to the previous
election. I wasn't taking notes, but I think a little over 50% of those
appeared after my "Contact this user" message.


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Call for votes: Developer Membership Board restaffing

[Brian Murray]

On Tue, Mar 29, 2022 at 03:22:25PM +0100, Robie Basak wrote:
> On Tue, Mar 29, 2022 at 10:14:06AM -0400, Dan Streetman wrote:
> > Do you have evidence that has actually happened to anyone in this
> > case? I was able to vote quite easily, and it seems (from your ML
> > comments) that both Christian and yourself were as well, and Christian
> > provided explicit steps earlier in this email thread.
> 
> The low turnout so far suggests that there might be a problem. I've
> additionally had one piece of feedback ending in "...so I gave up. Maybe
> others did too"[1].
> 
> > Can you clarify what will happen at the announced end of the election
> > tomorrow? Will the election end, or will you extend it? What is the
> > criteria you will use to decide to extend or adjust the election?
> > What's the next steps if the election is extended?
> 
> I have yet to decide. Feedback from others appreciated.
> 
> One thing I might try to do is arrange a mailshot directly myself -
> perhaps using my @canonical.com address - since I think that might get
> through to Gmail users OK. This would be just to alert the electorate to
> the existing posts to ubuntu-devel-announce@ and ubuntu-devel@. I could
> just provide archive links. I can't differentiate between people who
> have voted and people who have not, so this would have to go to everyone
> I have down as eligible (for whom I have a valid address).

On IRC we talked about using the "Contact this user" feature of
Launchpad. Did you end up getting many more votes after doing that?

--
Brian Murray

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Call for votes: Developer Membership Board restaffing

[Dan Streetman]

On Tue, Mar 29, 2022 at 10:22 AM Robie Basak  wrote:
>
> On Tue, Mar 29, 2022 at 10:14:06AM -0400, Dan Streetman wrote:
> > Do you have evidence that has actually happened to anyone in this
> > case? I was able to vote quite easily, and it seems (from your ML
> > comments) that both Christian and yourself were as well, and Christian
> > provided explicit steps earlier in this email thread.
>
> The low turnout so far suggests that there might be a problem. I've
> additionally had one piece of feedback ending in "...so I gave up. Maybe
> others did too"[1].
>
> > Can you clarify what will happen at the announced end of the election
> > tomorrow? Will the election end, or will you extend it? What is the
> > criteria you will use to decide to extend or adjust the election?
> > What's the next steps if the election is extended?
>
> I have yet to decide. Feedback from others appreciated.
>
> One thing I might try to do

whatever you decide to do, my feedback is that you should decide it
and announce it, with specific details, before the previously-stated
end of the election. If you feel the election process must change, I
personally trust you to make a good decision on what new
rules/procedures need to be adjusted for this election (but as
previously stated I also pretty strongly feel that the election should
end at its previously stated end date).

After the modified election rules/process are announced, including a
new end date (if applicable), I suggest not making any more changes.

> is arrange a mailshot directly myself -
> perhaps using my @canonical.com address - since I think that might get
> through to Gmail users OK. This would be just to alert the electorate to
> the existing posts to ubuntu-devel-announce@ and ubuntu-devel@. I could
> just provide archive links. I can't differentiate between people who
> have voted and people who have not, so this would have to go to everyone
> I have down as eligible (for whom I have a valid address).
>
> Robie
>
> [1] With my help in identifying the correct alias this person reports
> they have now voted, so that's good.

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Call for votes: Developer Membership Board restaffing

[Robie Basak]

On Tue, Mar 29, 2022 at 10:14:06AM -0400, Dan Streetman wrote:
> Do you have evidence that has actually happened to anyone in this
> case? I was able to vote quite easily, and it seems (from your ML
> comments) that both Christian and yourself were as well, and Christian
> provided explicit steps earlier in this email thread.

The low turnout so far suggests that there might be a problem. I've
additionally had one piece of feedback ending in "...so I gave up. Maybe
others did too"[1].

> Can you clarify what will happen at the announced end of the election
> tomorrow? Will the election end, or will you extend it? What is the
> criteria you will use to decide to extend or adjust the election?
> What's the next steps if the election is extended?

I have yet to decide. Feedback from others appreciated.

One thing I might try to do is arrange a mailshot directly myself -
perhaps using my @canonical.com address - since I think that might get
through to Gmail users OK. This would be just to alert the electorate to
the existing posts to ubuntu-devel-announce@ and ubuntu-devel@. I could
just provide archive links. I can't differentiate between people who
have voted and people who have not, so this would have to go to everyone
I have down as eligible (for whom I have a valid address).

Robie

[1] With my help in identifying the correct alias this person reports
they have now voted, so that's good.


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Call for votes: Developer Membership Board restaffing

[Andreas Hasenack]

Hi,

On Tue, Mar 29, 2022 at 11:15 AM Dan Streetman  wrote:
>
> On Tue, Mar 29, 2022 at 9:45 AM Robie Basak  wrote:
> >
> > On Tue, Mar 29, 2022 at 09:19:31AM -0400, Dan Streetman wrote:
> > > For example, in this situation; carrying out an election really
> > > shouldn't be an exceptional event.
> >
> > Normally it isn't. Previous elections have run smoothly and with no
> > issues that I'm aware of.
> >
> > However we now have an interaction between the following exceptional
> > situations, none of which were predicted:
> >
> > 1) The sudden apparent inability to send out announcements in the usual
> > way.
> >
> > 2) The sudden (for us) change in CIVS to require email pre-approval.
> >
> > 3) Our existing email-gathering system means that people now don't
> > necessarily know their own ballot email alias and figuring that out is
> > particularly difficult.
> >
> > This is exceptional and requires exceptional consideration. Nothing we
> > might have had in rules or policies previously could reasonably have
> > predicted this.
> >
> > You seem to be suggesting that the current situation demonstrates that
> > the existing documentation, process or policy around running a DMB
> > election is somehow inadequate. But since this exceptional situation
> > couldn't reasonably have been accommodated in hindsight, I don't think
> > this is the case.
> >
> > > 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.
> >
> > Thank you for your feedback.
> >
> > > Can you imagine if a government decided to change the election process
> > > during an election?
> >
> > For a fair comparison, you'd have to imagine what would happen if during
> > a government election it turned out that most of the electorate found
> > themselves unable to receive a ballot and therefore couldn't vote.
>
> Do you have evidence that has actually happened to anyone in this
> case? I was able to vote quite easily, and it seems (from your ML
> comments) that both Christian and yourself were as well, and Christian
> provided explicit steps earlier in this email thread.

I wasn't able to vote. I tried a few different emails and the system
wouldn't recognize any, and I gave up on that day and forgot about it,
until this thread was woken up. Of course, the one email I didn't try
was the correct one, but having to pick an email, request a token,
wait, use token, and then nothing, was too cumbersome that day and I
gave up after 3 attempts.

Today I talked with Robie, and he told me the correct email to use,
and I was able to vote.

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Call for votes: Developer Membership Board restaffing

[Dan Streetman]

On Tue, Mar 29, 2022 at 9:45 AM Robie Basak  wrote:
>
> On Tue, Mar 29, 2022 at 09:19:31AM -0400, Dan Streetman wrote:
> > For example, in this situation; carrying out an election really
> > shouldn't be an exceptional event.
>
> Normally it isn't. Previous elections have run smoothly and with no
> issues that I'm aware of.
>
> However we now have an interaction between the following exceptional
> situations, none of which were predicted:
>
> 1) The sudden apparent inability to send out announcements in the usual
> way.
>
> 2) The sudden (for us) change in CIVS to require email pre-approval.
>
> 3) Our existing email-gathering system means that people now don't
> necessarily know their own ballot email alias and figuring that out is
> particularly difficult.
>
> This is exceptional and requires exceptional consideration. Nothing we
> might have had in rules or policies previously could reasonably have
> predicted this.
>
> You seem to be suggesting that the current situation demonstrates that
> the existing documentation, process or policy around running a DMB
> election is somehow inadequate. But since this exceptional situation
> couldn't reasonably have been accommodated in hindsight, I don't think
> this is the case.
>
> > 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.
>
> Thank you for your feedback.
>
> > Can you imagine if a government decided to change the election process
> > during an election?
>
> For a fair comparison, you'd have to imagine what would happen if during
> a government election it turned out that most of the electorate found
> themselves unable to receive a ballot and therefore couldn't vote.

Do you have evidence that has actually happened to anyone in this
case? I was able to vote quite easily, and it seems (from your ML
comments) that both Christian and yourself were as well, and Christian
provided explicit steps earlier in this email thread.

Can you clarify what will happen at the announced end of the election
tomorrow? Will the election end, or will you extend it? What is the
criteria you will use to decide to extend or adjust the election?
What's the next steps if the election is extended?

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Call for votes: Developer Membership Board restaffing

[Robie Basak]

On Tue, Mar 29, 2022 at 09:19:31AM -0400, Dan Streetman wrote:
> For example, in this situation; carrying out an election really
> shouldn't be an exceptional event.

Normally it isn't. Previous elections have run smoothly and with no
issues that I'm aware of.

However we now have an interaction between the following exceptional
situations, none of which were predicted:

1) The sudden apparent inability to send out announcements in the usual
way.

2) The sudden (for us) change in CIVS to require email pre-approval.

3) Our existing email-gathering system means that people now don't
necessarily know their own ballot email alias and figuring that out is
particularly difficult.

This is exceptional and requires exceptional consideration. Nothing we
might have had in rules or policies previously could reasonably have
predicted this.

You seem to be suggesting that the current situation demonstrates that
the existing documentation, process or policy around running a DMB
election is somehow inadequate. But since this exceptional situation
couldn't reasonably have been accommodated in hindsight, I don't think
this is the case.

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

Thank you for your feedback.

> Can you imagine if a government decided to change the election process
> during an election?

For a fair comparison, you'd have to imagine what would happen if during
a government election it turned out that most of the electorate found
themselves unable to receive a ballot and therefore couldn't vote.


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Call for votes: Developer Membership Board restaffing

[Dan Streetman]

On Tue, Mar 29, 2022 at 8:57 AM Robie Basak  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  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

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Call for votes: Developer Membership Board restaffing

[Robie Basak]

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, we would all be unanimous about
the appropriateness of doing that. This is why I'm asking for feedback
here.

On Tue, Mar 29, 2022 at 06:17:23AM -0400, Dan Streetman wrote:
> On Tue, Mar 29, 2022 at 6:14 AM Dan Streetman  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


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Call for votes: Developer Membership Board restaffing

[Dan Streetman]

On Tue, Mar 29, 2022 at 6:14 AM Dan Streetman  wrote:
>
> On Tue, Mar 29, 2022 at 6:02 AM Robie Basak  wrote:
> >
> > On Wed, Mar 23, 2022 at 12:51:52PM +0100, Christian Ehrhardt wrote:
> > > If you happen to activate the "wrong" email you'll just see:
> > >
> > > ```
> > >   Email address successfully activated.
> > > ```
> > >
> > > But if you activate the right one (just as Robie said, usually the
> > > @ubuntu.com one) you'd in the Web UI of CIVS right after clicking
> > > "Complete activation" see this:
> > >
> > > ```
> > > Email address successfully activated.
> > >   Pending poll invitations:
> > > Ubuntu Developer Membership Board restaffing
> > > ```
> > >
> > > The latter line is a link leading you to your vote.
> >
> > Thank you Christian for detailing this. Hopefully this has helped others
> > vote.
> >
> > So far the turnout is considerably lower than the previous election two
> > years ago. Last time there were 54/173 votes cast at the time the poll
> > closed. For the CIVS poll in progress I can't see who voted (or how) but
> > the control page does show me the count. So far we have 23/174.
> >
> > We've had a couple of hurdles:
> >
> > 1) This extra opt-in step means that the electorate no longer get the
> > poll request directly to their inbox. We're relying on them seeing the
> > ubuntu-devel-announce@ notifications, or subsequent traffic to
> > ubuntu-devel@.
> >
> > 2) Recently Gmail seems to have adjusted things which has caused
> > deliverability problems to @gmail.com addresses (and presumably other
> > addresses hosted by Google). IS has made some adjustments to try to
> > help, but it's unclear to me if they worked because overnight I received
> > ~373 "unsubscribe" notifications to ubuntu-devel-owner@ all at once,
> > predominantely relating to @gmail.com addresses. It seems likely to me
> > that these are a result of the deliverability problems. So it's not
> > clear to me that all of the electorate is actually even aware of the
> > election. Of course there are surely many more ubuntu-devel@ subscribers
> > than those eligible to vote, so the number of unsubscribes doesn't
> > actually mean anything.
> >
> > I'd appreciate feedback on how to proceed.
>
> Where are the rules/policies written down about how elections should
> be handled? We should have the process written down somewhere so there
> is not ambiguity like this.

Also, I think we should probably remove ubuntu-devel-announce from
this discussion?

>
> > For example, together with
> > some specific action to draw the attention of the electorate, I could
> > extend the voting period if that would be considered helpful.
> >
> > On the other hand, it would be helpful to get the replacement DMB
> > members resolved as soon as possible. Perhaps the current vote count can
> > be considered enough to not make a big difference to the outcome, given
> > that there's no particular reason for bias in those that might not have
> > received the announcement?
> >
> > Robie
> > --
> > Ubuntu-devel-discuss mailing list
> > ubuntu-devel-disc...@lists.ubuntu.com
> > Modify settings or unsubscribe at: 
> > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Call for votes: Developer Membership Board restaffing

[Dan Streetman]

On Tue, Mar 29, 2022 at 6:02 AM Robie Basak  wrote:
>
> On Wed, Mar 23, 2022 at 12:51:52PM +0100, Christian Ehrhardt wrote:
> > If you happen to activate the "wrong" email you'll just see:
> >
> > ```
> >   Email address successfully activated.
> > ```
> >
> > But if you activate the right one (just as Robie said, usually the
> > @ubuntu.com one) you'd in the Web UI of CIVS right after clicking
> > "Complete activation" see this:
> >
> > ```
> > Email address successfully activated.
> >   Pending poll invitations:
> > Ubuntu Developer Membership Board restaffing
> > ```
> >
> > The latter line is a link leading you to your vote.
>
> Thank you Christian for detailing this. Hopefully this has helped others
> vote.
>
> So far the turnout is considerably lower than the previous election two
> years ago. Last time there were 54/173 votes cast at the time the poll
> closed. For the CIVS poll in progress I can't see who voted (or how) but
> the control page does show me the count. So far we have 23/174.
>
> We've had a couple of hurdles:
>
> 1) This extra opt-in step means that the electorate no longer get the
> poll request directly to their inbox. We're relying on them seeing the
> ubuntu-devel-announce@ notifications, or subsequent traffic to
> ubuntu-devel@.
>
> 2) Recently Gmail seems to have adjusted things which has caused
> deliverability problems to @gmail.com addresses (and presumably other
> addresses hosted by Google). IS has made some adjustments to try to
> help, but it's unclear to me if they worked because overnight I received
> ~373 "unsubscribe" notifications to ubuntu-devel-owner@ all at once,
> predominantely relating to @gmail.com addresses. It seems likely to me
> that these are a result of the deliverability problems. So it's not
> clear to me that all of the electorate is actually even aware of the
> election. Of course there are surely many more ubuntu-devel@ subscribers
> than those eligible to vote, so the number of unsubscribes doesn't
> actually mean anything.
>
> I'd appreciate feedback on how to proceed.

Where are the rules/policies written down about how elections should
be handled? We should have the process written down somewhere so there
is not ambiguity like this.

> For example, together with
> some specific action to draw the attention of the electorate, I could
> extend the voting period if that would be considered helpful.
>
> On the other hand, it would be helpful to get the replacement DMB
> members resolved as soon as possible. Perhaps the current vote count can
> be considered enough to not make a big difference to the outcome, given
> that there's no particular reason for bias in those that might not have
> received the announcement?
>
> Robie
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Call for votes: Developer Membership Board restaffing

[Dan Streetman]

On Tue, Mar 29, 2022 at 6:02 AM Robie Basak  wrote:
>
> On Wed, Mar 23, 2022 at 12:51:52PM +0100, Christian Ehrhardt wrote:
> > If you happen to activate the "wrong" email you'll just see:
> >
> > ```
> >   Email address successfully activated.
> > ```
> >
> > But if you activate the right one (just as Robie said, usually the
> > @ubuntu.com one) you'd in the Web UI of CIVS right after clicking
> > "Complete activation" see this:
> >
> > ```
> > Email address successfully activated.
> >   Pending poll invitations:
> > Ubuntu Developer Membership Board restaffing
> > ```
> >
> > The latter line is a link leading you to your vote.
>
> Thank you Christian for detailing this. Hopefully this has helped others
> vote.
>
> So far the turnout is considerably lower than the previous election two
> years ago. Last time there were 54/173 votes cast at the time the poll
> closed. For the CIVS poll in progress I can't see who voted (or how) but
> the control page does show me the count. So far we have 23/174.
>
> We've had a couple of hurdles:
>
> 1) This extra opt-in step means that the electorate no longer get the
> poll request directly to their inbox. We're relying on them seeing the
> ubuntu-devel-announce@ notifications, or subsequent traffic to
> ubuntu-devel@.
>
> 2) Recently Gmail seems to have adjusted things which has caused
> deliverability problems to @gmail.com addresses (and presumably other
> addresses hosted by Google). IS has made some adjustments to try to
> help, but it's unclear to me if they worked because overnight I received
> ~373 "unsubscribe" notifications to ubuntu-devel-owner@ all at once,
> predominantely relating to @gmail.com addresses. It seems likely to me
> that these are a result of the deliverability problems. So it's not
> clear to me that all of the electorate is actually even aware of the
> election. Of course there are surely many more ubuntu-devel@ subscribers
> than those eligible to vote, so the number of unsubscribes doesn't
> actually mean anything.
>
> I'd appreciate feedback on how to proceed.

Where are the rules/policies written down about how elections should
be handled? We should have the process written down somewhere so there
is not ambiguity like this.

> For example, together with
> some specific action to draw the attention of the electorate, I could
> extend the voting period if that would be considered helpful.
>
> On the other hand, it would be helpful to get the replacement DMB
> members resolved as soon as possible. Perhaps the current vote count can
> be considered enough to not make a big difference to the outcome, given
> that there's no particular reason for bias in those that might not have
> received the announcement?
>
> Robie
> --
> Ubuntu-devel-discuss mailing list
> ubuntu-devel-disc...@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Call for votes: Developer Membership Board restaffing

[Robie Basak]

On Wed, Mar 23, 2022 at 12:51:52PM +0100, Christian Ehrhardt wrote:
> If you happen to activate the "wrong" email you'll just see:
> 
> ```
>   Email address successfully activated.
> ```
> 
> But if you activate the right one (just as Robie said, usually the
> @ubuntu.com one) you'd in the Web UI of CIVS right after clicking
> "Complete activation" see this:
> 
> ```
> Email address successfully activated.
>   Pending poll invitations:
> Ubuntu Developer Membership Board restaffing
> ```
> 
> The latter line is a link leading you to your vote.

Thank you Christian for detailing this. Hopefully this has helped others
vote.

So far the turnout is considerably lower than the previous election two
years ago. Last time there were 54/173 votes cast at the time the poll
closed. For the CIVS poll in progress I can't see who voted (or how) but
the control page does show me the count. So far we have 23/174.

We've had a couple of hurdles:

1) This extra opt-in step means that the electorate no longer get the
poll request directly to their inbox. We're relying on them seeing the
ubuntu-devel-announce@ notifications, or subsequent traffic to
ubuntu-devel@.

2) Recently Gmail seems to have adjusted things which has caused
deliverability problems to @gmail.com addresses (and presumably other
addresses hosted by Google). IS has made some adjustments to try to
help, but it's unclear to me if they worked because overnight I received
~373 "unsubscribe" notifications to ubuntu-devel-owner@ all at once,
predominantely relating to @gmail.com addresses. It seems likely to me
that these are a result of the deliverability problems. So it's not
clear to me that all of the electorate is actually even aware of the
election. Of course there are surely many more ubuntu-devel@ subscribers
than those eligible to vote, so the number of unsubscribes doesn't
actually mean anything.

I'd appreciate feedback on how to proceed. For example, together with
some specific action to draw the attention of the electorate, I could
extend the voting period if that would be considered helpful.

On the other hand, it would be helpful to get the replacement DMB
members resolved as soon as possible. Perhaps the current vote count can
be considered enough to not make a big difference to the outcome, given
that there's no particular reason for bias in those that might not have
received the announcement?

Robie


signature.asc
Description: PGP signature
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Call for votes: Developer Membership Board restaffing

[Robie Basak]

On Wed, Mar 23, 2022 at 12:51:52PM +0100, Christian Ehrhardt wrote:
> If you happen to activate the "wrong" email you'll just see:
> 
> ```
>   Email address successfully activated.
> ```
> 
> But if you activate the right one (just as Robie said, usually the
> @ubuntu.com one) you'd in the Web UI of CIVS right after clicking
> "Complete activation" see this:
> 
> ```
> Email address successfully activated.
>   Pending poll invitations:
> Ubuntu Developer Membership Board restaffing
> ```
> 
> The latter line is a link leading you to your vote.

Thank you Christian for detailing this. Hopefully this has helped others
vote.

So far the turnout is considerably lower than the previous election two
years ago. Last time there were 54/173 votes cast at the time the poll
closed. For the CIVS poll in progress I can't see who voted (or how) but
the control page does show me the count. So far we have 23/174.

We've had a couple of hurdles:

1) This extra opt-in step means that the electorate no longer get the
poll request directly to their inbox. We're relying on them seeing the
ubuntu-devel-announce@ notifications, or subsequent traffic to
ubuntu-devel@.

2) Recently Gmail seems to have adjusted things which has caused
deliverability problems to @gmail.com addresses (and presumably other
addresses hosted by Google). IS has made some adjustments to try to
help, but it's unclear to me if they worked because overnight I received
~373 "unsubscribe" notifications to ubuntu-devel-owner@ all at once,
predominantely relating to @gmail.com addresses. It seems likely to me
that these are a result of the deliverability problems. So it's not
clear to me that all of the electorate is actually even aware of the
election. Of course there are surely many more ubuntu-devel@ subscribers
than those eligible to vote, so the number of unsubscribes doesn't
actually mean anything.

I'd appreciate feedback on how to proceed. For example, together with
some specific action to draw the attention of the electorate, I could
extend the voting period if that would be considered helpful.

On the other hand, it would be helpful to get the replacement DMB
members resolved as soon as possible. Perhaps the current vote count can
be considered enough to not make a big difference to the outcome, given
that there's no particular reason for bias in those that might not have
received the announcement?

Robie


signature.asc
Description: PGP signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Call for votes: Developer Membership Board restaffing

[Christian Ehrhardt]

On Wed, Mar 23, 2022 at 12:06 PM Robie Basak  wrote:
>
> The Developer Membership Board (DMB) has started a restaffing vote for
> three vacant seats. The DMB is responsible for reviewing and approving
> new Ubuntu developers. It evaluates prospective Ubuntu developers and
> decides when to entrust them with developer privileges. There are five
> candidates:
>
> William 'jawn-smith' Wilson (https://wiki.ubuntu.com/jawn-smith/RunningForDMB)
> Brian Murray
> Sebastien Bacher
> Lucas Kanashiro
> Utkarsh Gupta
>
> The vote closes on 2022-03-30 at approximately 18:00 UTC.
>
> As usual, the election is being run using the Condorcet Internet Voting
> Service. All members of the ~ubuntu-dev team in Launchpad are eligible
> to vote. However, recent changes to CIVS require you to *opt-in* to
> using your email address to vote. You cannot receive a ballot until you
> have opted in. Please opt in here:
>
> https://civs1.civs.us/cgi-bin/opt_in.pl
>
> You must use the same email address as the one I have collected for you
> for your ballot. This is generally @ubuntu.com if that is an
> alias that you have published in Launchpad publicly. More complicated
> matching rules apply otherwise. If you are a member of ~ubuntu-dev and
> are struggling to acquire your ballot, please contact me privately. I
> may need to identify the email alias I am using for you directly.

Thank you so much Robie for outlining all this in detail.
Since I just activated mine, but needed to try a few addresses I
wanted to describe how it looks.
I hope it will help that everybody knows what to expect.

If you happen to activate the "wrong" email you'll just see:

```
  Email address successfully activated.
```

But if you activate the right one (just as Robie said, usually the
@ubuntu.com one) you'd in the Web UI of CIVS right after clicking
"Complete activation" see this:

```
Email address successfully activated.
  Pending poll invitations:
Ubuntu Developer Membership Board restaffing
```

The latter line is a link leading you to your vote.


> This announcement is being sent to a moderated announcement mailing
> list. For discussion, Ubuntu developers should use
> ubuntu-de...@lists.ubuntu.com.
>
> On behalf of the DMB,
>
> Robie
> --
> ubuntu-devel-announce mailing list
> ubuntu-devel-annou...@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce



--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Call for votes: Developer Membership Board restaffing

[Christian Ehrhardt]

On Wed, Mar 23, 2022 at 12:06 PM Robie Basak  wrote:
>
> The Developer Membership Board (DMB) has started a restaffing vote for
> three vacant seats. The DMB is responsible for reviewing and approving
> new Ubuntu developers. It evaluates prospective Ubuntu developers and
> decides when to entrust them with developer privileges. There are five
> candidates:
>
> William 'jawn-smith' Wilson (https://wiki.ubuntu.com/jawn-smith/RunningForDMB)
> Brian Murray
> Sebastien Bacher
> Lucas Kanashiro
> Utkarsh Gupta
>
> The vote closes on 2022-03-30 at approximately 18:00 UTC.
>
> As usual, the election is being run using the Condorcet Internet Voting
> Service. All members of the ~ubuntu-dev team in Launchpad are eligible
> to vote. However, recent changes to CIVS require you to *opt-in* to
> using your email address to vote. You cannot receive a ballot until you
> have opted in. Please opt in here:
>
> https://civs1.civs.us/cgi-bin/opt_in.pl
>
> You must use the same email address as the one I have collected for you
> for your ballot. This is generally @ubuntu.com if that is an
> alias that you have published in Launchpad publicly. More complicated
> matching rules apply otherwise. If you are a member of ~ubuntu-dev and
> are struggling to acquire your ballot, please contact me privately. I
> may need to identify the email alias I am using for you directly.

Thank you so much Robie for outlining all this in detail.
Since I just activated mine, but needed to try a few addresses I
wanted to describe how it looks.
I hope it will help that everybody knows what to expect.

If you happen to activate the "wrong" email you'll just see:

```
  Email address successfully activated.
```

But if you activate the right one (just as Robie said, usually the
@ubuntu.com one) you'd in the Web UI of CIVS right after clicking
"Complete activation" see this:

```
Email address successfully activated.
  Pending poll invitations:
Ubuntu Developer Membership Board restaffing
```

The latter line is a link leading you to your vote.


> This announcement is being sent to a moderated announcement mailing
> list. For discussion, Ubuntu developers should use
> ubuntu-devel@lists.ubuntu.com.
>
> On behalf of the DMB,
>
> Robie
> --
> ubuntu-devel-announce mailing list
> ubuntu-devel-annou...@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce



--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Call for votes: Developer Membership Board restaffing

[Bipul kumar]

My vouch to Simon Quigley (tsimonq2)

Thank you
Respectfully,
Bipul
PUBLIC KEY 
97F0 2E08 7DE7 D538 BDFA  B708 86D8 BE27 8196 D466
** Please excuse brevity and typos. **


On Fri, Feb 14, 2020 at 9:21 PM Robie Basak  wrote:

> The Developer Membership Board (DMB) has started a restaffing vote for
> the seven members whose terms are expiring. The DMB is responsible for
> reviewing and approving new Ubuntu developers. It evaluates prospective
> Ubuntu developers and decides when to entrust them with developer
> privileges. There are eight candidates:
>
> Łukasz Zemczak (sil2100)
> Dan Streetman (ddstreet)
> Simon Quigley (tsimonq2)
> Thomas Ward (teward)
> Eric Desrochers (slashd)
> Micah Gersten (micahg)
> Rafael D. Tinoco (rafaeldtinico)
> Robie Basak (rbasak)
>
> The vote closes on 2020-02-21 at approximately 18:00 UTC.
>
> Ballots are being mailed to all members of ~ubuntu-dev who have a public
> email address visible in Launchpad or who have linked GPG keys that
> verify against their Launchpad accounts. If you are a member of
> ~ubuntu-dev and don't receive a ballot, please contact me privately.
>
> On behalf of the DMB,
> Robie Basak
> --
> ubuntu-devel-announce mailing list
> ubuntu-devel-annou...@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce
>
-- 
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss

Re: Call for votes: Developer Membership Board restaffing

[Micah Gersten]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/30/2013 09:36 AM, Micah Gersten wrote:
 The Developer Membership Board has started a vote to restaff for the four 
 members whose terms are
expiring.

The results were as follows:
1. Scott Kitterman (ScottK)
2. Stéphane Graber (stgraber)
3. Iain Lane (Laney)
4. Benjamin Drung (bdrung)
5. Dmitrijs Ledkovs (xnox)
6. Cody Somerville (cody-somerville)
7. Bhavani Shankar (coolbhavi)

The DMB confirmed these results at the meeting on 2013-02-11.

Please welcome Scott Kitterman to the DMB.  His term began on
2013-02-13. We would also like to thank Cody Somerville for his years of
service on the DMB and wish him well in his future endeavors within the
Ubuntu community.

You can see the full results here [1].

Thanks,
Micah Gersten
On behalf of the DMB

[1]
http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/results.pl?id=E_5b1837b9f3008750
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlE0MNYACgkQTniv4aqX/Vni4ACdF6EdZCuzKpE0FwKPC9+gi/dc
sHUAn2vbmkQ0OPdbN39I5znex2QeR41o
=LhXj
-END PGP SIGNATURE-


-- 
ubuntu-devel-announce mailing list
ubuntu-devel-announce@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-announce

Re: Call for votes: Developer Membership Board restaffing

[Jani Monoses]

On Wed, 30 Jan 2013 16:22:58 -0800, Steve Langasek wrote:

 Hello,
[snip]
 That's certainly true, but I think this is something that the DMB has a
 duty to correct.  Frankly, I think there's no reason that Adam and Björn
 couldn't have been ready for upload rights by January, *if* the DMB's

I must ask the same question as the Debian maintainer who endorsed Björn's 
application: 'Are you kidding? :)'
I never assumed for a moment that he had not long been an uploader of 
LibreOffice.

I think the DMB members did their job well by following the existing 
guidelines for such approval procedures and I also think those guidelines 
are in need of adjustments.

It seems ridiculous to have such a bureaucratic process that prevents for 
example someone who more or less single-handedly has been taking care of 
LibreOffice in Ubuntu for the past two years get upload rights *for that 
set of packages only*.

Extra caution is desirable when approving core developer or universe 
upload rights but it is counterproductive to have the same rules for 
applicants of restricted upload rights.

I've seen similar problems in the past two years where people from Linaro 
would simply not bother applying for maintainership of otherwise good 
packages and preferred keeping them in PPAs at the detriment of those who 
only use the official Ubuntu archives, because again, the requirements 
seemed daunting.

I honestly think the process should lose the 'pledge of allegiance' 
aspect for single uploaders and just get out of the way, saving time and 
annoyance both for those uploaders and for the Ubuntu developers who have 
to do the sponsoring.

cheers
Jani


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Call for votes: Developer Membership Board restaffing

[Iain Lane]

Hi Steve,

On Wed, Jan 30, 2013 at 04:22:58PM -0800, Steve Langasek wrote:
 Hello,
 […]
 So my question to each of the candidates is this.  As a member of the DMB,
 what would you do to remove this uncertainty around when people are ready to
 apply, reducing the number of rejections (whether those are hard rejects, or
 soft redirects) at DMB meetings?

[ Disclaimer: I'm currently on the DMB but I wasn't at that particular
  meeting, so I won't comment on these particular cases. ]

I think you're right in identifying this as an area of concern, and I
tried to address this briefly in my election statement [1]. I'll try to
restate it a bit now.

As others have said, it's probably not going to be possible to reduce
the process to going through a checklist. What we can do is to be
responsive /and proactive/ when applications first come in (or even
before then, if applicants contact the DMB speculatively or if teams
like the DAT want to link up with us which I think would be a good
idea). It's true that most of the information required to make a
decision is often available before the meeting in which the decision is
ultimately taken.

Given that, if a DMB member feels sure that they would want to vote
negatively on an application, they should feel able to act on their own
initiative and contact the applicant explaining so. I expect this to be
rather less negative than a similar outcome after a full round of voting
at a meeting.

It occurs to me now that if this would actually be slightly more opaque
if it were implemented as such feedback would be in private. [1] talks
about providing feedback after applications fall at a meeting, but this
could also be extended to situations where applicants defer themselves
after correspondence with the DMB prior to a meeting. There are a few
avenues that members can use, depending on the situation, to communicate
their recommendations. [2] and [3], public mail to devel-permissions or
private mail to the endorsers. These would help to build up a body of
case law.

The how do I know when I am ready question is one I recognise as one
of the toughest for applicants. It's tough for the DMB to articulate it
too. I recognise that it can feel like the DMB is making arbitrary
decisions or is too quick to defer applications. Greater transparency
would, in my opinion, be the best antidote to ill-will that
unfortunately can sometimes breed.

Finally I want to state that while deferrals are contentious decisions
that sometimes generate a lot of discussion, the vast majority of
candidates the DMB evaluates are approved for the upload rights they
seek (sometimes they are granted even broader permissions if that seems
appropriate). I feel pleased and proud when I look back on the excellent
developers that have been approved during my time on the DMB.

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]

[1] https://wiki.ubuntu.com/IainLane/DMB2013
[2] https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess
[3] https://wiki.ubuntu.com/UbuntuDevelopers


signature.asc
Description: Digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Call for votes: Developer Membership Board restaffing

[Iain Lane]

Hello Jani,

On Thu, Jan 31, 2013 at 09:23:39AM +, Jani Monoses wrote:
 On Wed, 30 Jan 2013 16:22:58 -0800, Steve Langasek wrote:
 
  Hello,
 [snip]
  That's certainly true, but I think this is something that the DMB has a
  duty to correct.  Frankly, I think there's no reason that Adam and Björn
  couldn't have been ready for upload rights by January, *if* the DMB's

 […]
 I've seen similar problems in the past two years where people from Linaro 
 would simply not bother applying for maintainership of otherwise good 
 packages and preferred keeping them in PPAs at the detriment of those who 
 only use the official Ubuntu archives, because again, the requirements 
 seemed daunting.

Hmm, I'm concerned about this. If the parties concerned are happy, could
you pass on their contact details to me or
developer-membership-board@l.u.c and I/we will follow up with them. I
don't want the process to be seen as such a huge burden that puts people
who should be given uploads rights off from even applying, and I'm keen
to work to change this.

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]


signature.asc
Description: Digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Call for votes: Developer Membership Board restaffing

[Daniel Holbach]

Hello,

On 31.01.2013 11:08, Iain Lane wrote:
 As others have said, it's probably not going to be possible to reduce
 the process to going through a checklist. What we can do is to be
 responsive /and proactive/ when applications first come in (or even
 before then, if applicants contact the DMB speculatively or if teams
 like the DAT want to link up with us which I think would be a good
 idea). It's true that most of the information required to make a
 decision is often available before the meeting in which the decision is
 ultimately taken.

I like this suggestion a lot.

The Dev Advisory Team reviews the work of contributors all the time and
we actively encourage developers to apply and help them set up their
application pages. I mentioned it in another thread already: the fear of
being rejected is real - so that's a reality we have to work with.

Having a regular exchange between DMB and DAT in the form of these
developers look ready to apply to us, what are your thoughts? might be
a good start towards:

 1) providing applicants with either some reassurance (no immediate
objections) or some concrete tasks to work on (clarify some
bits in the application or put some more work into Ubuntu and
apply a few weeks later).
 2) establishing a clearer set of requirements for applicants in the
long run.

For now I'd be happy if we got better at 1) and have more successful
applications by being more proactive, but in the long run I think we
should get better at 2) too. Clearer expectations will make contributors
much more likely to apply.

Maybe with more collaboration between the Advisory Team and the
Membership Board we can also look into simplifying the process a bit, so
it's even more straight-forward, but maybe that's a separate discussion.

Have a great day,
 Daniel

-- 
Ubuntu Developer Week - https://wiki.ubuntu.com/UbuntuDeveloperWeek
29th-31st Jan 2013 - Your great chance to finally get involved!

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Call for votes: Developer Membership Board restaffing

[Daniel Holbach]

Hello,

On 31.01.2013 14:51, Scott Kitterman wrote:
 I don't think having an intermediary between the DMB and the applicant is a 
 good idea.  I think approximately that last thing we need is more meetings.

I didn't say that this needs to happen in a meeting format.

In your earlier mail you said:

I like to seek them out and discuss it with them.
 That way they can consider if they should apply or not

The suggestion to bring the Advisory Team and the Membership Board
closer together is what I see exactly in the same spirit. We all don't
want applicants to fail. So whatever helps to set expectations is going
to be a good move.

Right now the DMB doesn't hear from a number of developers who /are/
ready for upload rights. The Advisory Team is actively reaching out to
them, so that's is why I'm suggesting establishing communication
channels, how formal, we can still decide.

Have a great day,
 Daniel

-- 
Ubuntu Developer Week - https://wiki.ubuntu.com/UbuntuDeveloperWeek
29th-31st Jan 2013 - Your great chance to finally get involved!

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Call for votes: Developer Membership Board restaffing

[Scott Kitterman]

On Thursday, January 31, 2013 09:23:39 AM Jani Monoses wrote:
 On Wed, 30 Jan 2013 16:22:58 -0800, Steve Langasek wrote:
  Hello,
 
 [snip]
 
  That's certainly true, but I think this is something that the DMB has a
  duty to correct.  Frankly, I think there's no reason that Adam and Björn
  couldn't have been ready for upload rights by January, *if* the DMB's
 
 I must ask the same question as the Debian maintainer who endorsed Björn's
 application: 'Are you kidding? :)'
 I never assumed for a moment that he had not long been an uploader of
 LibreOffice.
 
 I think the DMB members did their job well by following the existing
 guidelines for such approval procedures and I also think those guidelines
 are in need of adjustments.

What's in the current guidelines that needs changing?

 It seems ridiculous to have such a bureaucratic process that prevents for
 example someone who more or less single-handedly has been taking care of
 LibreOffice in Ubuntu for the past two years get upload rights *for that
 set of packages only*.
 
 Extra caution is desirable when approving core developer or universe
 upload rights but it is counterproductive to have the same rules for
 applicants of restricted upload rights.
 
 I've seen similar problems in the past two years where people from Linaro
 would simply not bother applying for maintainership of otherwise good
 packages and preferred keeping them in PPAs at the detriment of those who
 only use the official Ubuntu archives, because again, the requirements
 seemed daunting.
 
 I honestly think the process should lose the 'pledge of allegiance'
 aspect for single uploaders and just get out of the way, saving time and
 annoyance both for those uploaders and for the Ubuntu developers who have
 to do the sponsoring.

I think this is a difficult problem.  On one hand, I agree that sometimes the 
barriers are too high, but I'm not sure how to fix that just based on rules 
(once again - I don't know the details of these specific applications, so I'm 
speaking generally).  

One class of people that should be easy to generally approve are Debian 
developers who want PPU for packages they maintain in Debian.  I think they 
should generally be approved, but, OTOH, in years of being on the release team 
the single most inappropriate upload for the end stage of the release cycle 
I've had to reject was done by such a person.  The upload had enough things 
wrong with it and was so invasive, so late in the release cycle that I am 
completely confident this person got PPU without knowing anything about Ubuntu 
specific processes or schedules.  It can go too far the other way too.

Scott K

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Call for votes: Developer Membership Board restaffing

[Scott Kitterman]

On Thursday, January 31, 2013 03:03:52 PM Daniel Holbach wrote:
 Hello,
 
 On 31.01.2013 14:51, Scott Kitterman wrote:
  I don't think having an intermediary between the DMB and the applicant is
  a
  good idea.  I think approximately that last thing we need is more
  meetings.
 
 I didn't say that this needs to happen in a meeting format.
 
 In your earlier mail you said:
 
   I like to seek them out and discuss it with them.
  That way they can consider if they should apply or not
 
 The suggestion to bring the Advisory Team and the Membership Board
 closer together is what I see exactly in the same spirit. We all don't
 want applicants to fail. So whatever helps to set expectations is going
 to be a good move.
 
 Right now the DMB doesn't hear from a number of developers who /are/
 ready for upload rights. The Advisory Team is actively reaching out to
 them, so that's is why I'm suggesting establishing communication
 channels, how formal, we can still decide.

I think it's great that the advisory team is doing this.  I have, in the past, 
had to almost beg people who were clearly ready to apply.  This is a real 
problem that it's a good thing you are tackling.  While the advisory team can, 
and should, encourage and support applicants, I think we should be careful to 
avoid making them an intermediary.

Scott K

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Call for votes: Developer Membership Board restaffing

[Daniel Holbach]

Hello,

On 31.01.2013 15:08, Scott Kitterman wrote:
 While the advisory team can, 
 and should, encourage and support applicants, I think we should be careful to 
 avoid making them an intermediary.

I wasn't trying to say that this should be a mandatory step.

If you go back to my original mail I mentioned that I'd love to see the
process simplified, so adding a meeting or another step in the
application process is not in my interest.


Here are some problems which I currently see:

 - contributor A applies and gets rejected
 - after seeing contributor A fail, contributor B is suddenly
   unsure about applying and feels well, there's still sponsorship
 - contributor A might lose interest
 - DMB never hears back from contributor B

These are the social implications of (probably any) application
processes in general, and it's made worse by a public process.


Sure, we're all individuals in the project and individual ties between
people are important, but as an individual you can't always be in touch
with everyone and in a fast-paced project sometimes there's nobody who
reaches out to either A or B and Ubuntu as a project is off worse.

The Advisory Team set out to try to close those social gaps, so if the
DAT reached out to possible applicants, the DMB could have a first look
at applications and/or upload history and mention if they have concerns
or questions, so when contributors apply they have a little bit more
reassurance. This would be an optional step, not a requirement. Having
these communication channels would probably help bringing the DMB and
contributor B in touch and hopefully avoid a case of contributor A.

Let me know what you think.

Have a great day,
 Daniel

-- 
Ubuntu Developer Week - https://wiki.ubuntu.com/UbuntuDeveloperWeek
29th-31st Jan 2013 - Your great chance to finally get involved!

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Call for votes: Developer Membership Board restaffing

[Scott Kitterman]

On Thursday, January 31, 2013 03:30:42 PM Daniel Holbach wrote:
 Hello,
 
 On 31.01.2013 15:08, Scott Kitterman wrote:
  While the advisory team can,
  and should, encourage and support applicants, I think we should be careful
  to avoid making them an intermediary.
 
 I wasn't trying to say that this should be a mandatory step.
 
 If you go back to my original mail I mentioned that I'd love to see the
 process simplified, so adding a meeting or another step in the
 application process is not in my interest.
 
 
 Here are some problems which I currently see:
 
  - contributor A applies and gets rejected
  - after seeing contributor A fail, contributor B is suddenly
unsure about applying and feels well, there's still sponsorship
  - contributor A might lose interest
  - DMB never hears back from contributor B
 
 These are the social implications of (probably any) application
 processes in general, and it's made worse by a public process.
 
 
 Sure, we're all individuals in the project and individual ties between
 people are important, but as an individual you can't always be in touch
 with everyone and in a fast-paced project sometimes there's nobody who
 reaches out to either A or B and Ubuntu as a project is off worse.
 
 The Advisory Team set out to try to close those social gaps, so if the
 DAT reached out to possible applicants, the DMB could have a first look
 at applications and/or upload history and mention if they have concerns
 or questions, so when contributors apply they have a little bit more
 reassurance. This would be an optional step, not a requirement. Having
 these communication channels would probably help bringing the DMB and
 contributor B in touch and hopefully avoid a case of contributor A.
 
 Let me know what you think.

I agree about the problem statement and what you are trying to accomplish.  
What I think is important though is that the DAT should be there to support 
the applicant and, if needed, encourage the applicant to discuss matters with 
DMB members.  To put it a bit differently, I think the DAT should be there as 
part of the support system for the applicant, not as a substitute for the 
applicant communicating with people.

Scott K

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Call for votes: Developer Membership Board restaffing

[Stéphane Graber]

On 01/30/2013 07:22 PM, Steve Langasek wrote:
 Hello,
 
 On Wed, Jan 30, 2013 at 09:36:19AM -0600, Micah Gersten wrote:
 The Developer Membership Board has started a vote to restaff for the
 four members whose terms are expiring. The Developer Membership Board is
 responsible for reviewing and approving new Ubuntu developers. It
 evaluates prospective Ubuntu developers and decides when to entrust them
 with developer privileges. There are seven candidates:
 
 Benjamin Drung (bdrung) https://wiki.ubuntu.com/BenjaminDrung
 Bhavani Shankar (coolbhavi) https://wiki.ubuntu.com/BhavaniShankar
 Cody Somerville (cody-somerville) https://wiki.ubuntu.com/CodySomerville
 Dmitrijs Ledkovs (xnox) 
 https://wiki.ubuntu.com/DmitrijsLedkovs/DMBApplication
 Iain Lane (Laney) https://wiki.ubuntu.com/IainLane/DMB2013
 Scott Kitterman (ScottK) https://wiki.ubuntu.com/ScottKitterman
 Stéphane Graber (stgraber) https://wiki.ubuntu.com/stgraber
 
 At the January DMB meeting, there were two applicants, both of whom were
 rejected.  It doesn't say that on paper; on paper it says that Adam Stokes's
 application was changed to contributing member during the meeting and was
 approved.  But the long and the short of it is that two people with a
 substantial history of contributing to Ubuntu in their respective domains
 applied for upload rights in January, were recommended by existing Ubuntu
 developers, and were denied upload rights by the DMB.
 
 I understand that the DMB won't always agree with their fellow Ubuntu
 Developers about whether a particular applicant is ready for a particular
 uploader status.  But I do think it's important that when the DMB disagrees
 with the developers who are recommending someone for uploader status, there
 be transparency about the reasons for this disagreement.  Currently, the
 wiki says:
 
   It can be difficult to know when you are ready to apply for uploader team
   membership.
 
   (https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess)
 
 That's certainly true, but I think this is something that the DMB has a duty
 to correct.  Frankly, I think there's no reason that Adam and Björn couldn't
 have been ready for upload rights by January, *if* the DMB's expectations
 were made clearer.  If there were documented standards that at least tried
 to be objective, people who are aiming to get upload rights can be working
 to those standards in advance, instead of being told in the DMB meeting that
 the work they've been doing doesn't tick the right boxes on the DMB's
 invisible checklist.
 
 So my question to each of the candidates is this.  As a member of the DMB,
 what would you do to remove this uncertainty around when people are ready to
 apply, reducing the number of rejections (whether those are hard rejects, or
 soft redirects) at DMB meetings?

First of all, I'd like to start by looking at some numbers because I
know people on this list love those.
Based on my quick grepping through the IRC logs, over the past year
we've had a total of 29 applications of which 22 were granted, giving
over 75% success rate for our applicants.

Note that those numbers look at what was originally asked for by the
applicant, so any case where the application is downgraded by the DMB
isn't part of those 22.

Detailed stats are:
Coredev applications: 6 / 8 = 75%
MOTU applications: 2 / 4 = 50%
PPU: 14 / 16 = 87.5% (of which 5 included the creation of a new set)
UCD: 0 / 1 = 0%



Now to try to improve those numbers a bit, I think we can do a few things:
 - Improve our wiki documentation. I think we've rewritten it from
scratch 2-3 times since I first joined the DMB, but maybe the next time
will be perfect. As others said, we can't and won't publish a checklist
of things to do to become a coredev, MOTU or get PPU, but what we can
publish is a list of important areas of work related to the membership.
   Essentially we'd mention that coredevs work on the whole archive,
have to deal with a variety of different packaging methods, help with
library transitions, SRUs, merges from Debian and coordinate with the
release team. That should give enough pointers as to what we typically
look at when we get one of those applications.

 - I like the idea of having the Developer Advisory Board contact us and
in general I feel that applicants and sponsors should equally feel free
to contact DMB members to check if they feel they are ready or what kind
of work is still expected.
   All DMB members don't always agree with each other, so unfortunately
even if you're being told that you seem ready, it's no guarantee that
you'll be successful at the meeting, but those cases are fairly rare I
think and unfortunately Adam Stokes' application was one of those (where
I was the DMB member contacted pre-meeting).

 - Attempt to better describe what we expect on the social/distro side.
   The DMB doesn't only grant upload privileges, it also grants Ubuntu
Membership along with those privileges. That's 

Re: Call for votes: Developer Membership Board restaffing

[Jani Monoses]

On Thu, 31 Jan 2013 09:06:31 -0500, Scott Kitterman wrote:

 On Thursday, January 31, 2013 09:23:39 AM Jani Monoses wrote:
 On Wed, 30 Jan 2013 16:22:58 -0800, Steve Langasek wrote:
  Hello,
 
 [snip]
 
  That's certainly true, but I think this is something that the DMB has
  a duty to correct.  Frankly, I think there's no reason that Adam and
  Björn couldn't have been ready for upload rights by January, *if* the
  DMB's
 
 I must ask the same question as the Debian maintainer who endorsed
 Björn's application: 'Are you kidding? :)'
 I never assumed for a moment that he had not long been an uploader of
 LibreOffice.
 
 I think the DMB members did their job well by following the existing
 guidelines for such approval procedures and I also think those
 guidelines are in need of adjustments.
 
 What's in the current guidelines that needs changing?

I am only talking about PPU rights below, I think the current process for 
getting broader rights is ok.

There is too much coupling between Ubuntu membership and upload rights. 
While there are many developers who are both uploaders and contribute 
broadly to other non-technical aspects of the project, I think PPU should 
be seen as a focused technical role closer to that of traditional 
upstreams.

I'd also argue that endorsements from people who had sponsored and worked 
closely with the applicant in the past should have a greater weight than 
they apparently do and the process should not be about interview style  
packaging related questions.

Jani


-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Call for votes: Developer Membership Board restaffing

[Scott Kitterman]

On Thursday, January 31, 2013 05:08:22 PM Jani Monoses wrote:
 On Thu, 31 Jan 2013 09:06:31 -0500, Scott Kitterman wrote:
  On Thursday, January 31, 2013 09:23:39 AM Jani Monoses wrote:
  On Wed, 30 Jan 2013 16:22:58 -0800, Steve Langasek wrote:
   Hello,
  
  [snip]
  
   That's certainly true, but I think this is something that the DMB has
   a duty to correct.  Frankly, I think there's no reason that Adam and
   Björn couldn't have been ready for upload rights by January, *if* the
   DMB's
  
  I must ask the same question as the Debian maintainer who endorsed
  Björn's application: 'Are you kidding? :)'
  I never assumed for a moment that he had not long been an uploader of
  LibreOffice.
  
  I think the DMB members did their job well by following the existing
  guidelines for such approval procedures and I also think those
  guidelines are in need of adjustments.
  
  What's in the current guidelines that needs changing?
 
 I am only talking about PPU rights below, I think the current process for
 getting broader rights is ok.
 
 There is too much coupling between Ubuntu membership and upload rights.
 While there are many developers who are both uploaders and contribute
 broadly to other non-technical aspects of the project, I think PPU should
 be seen as a focused technical role closer to that of traditional
 upstreams.

One of the tricks here is that currently PPU makes someone a part of ubuntu-
dev which, among other things, means they have voting rights for tech board 
elections.  I think non-members should not be in ubuntu-dev.

This is a common enough problem that we should be able to have non-ubuntu-dev 
PPU that aren't members, but there are obviously some details that need to be 
worked out.

 I'd also argue that endorsements from people who had sponsored and worked
 closely with the applicant in the past should have a greater weight than
 they apparently do and the process should not be about interview style
 packaging related questions.

I agree they should have significant weight.  In the end though the DMB is the 
body delegated to decide and they have to make a decision.

Scott K

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Call for votes: Developer Membership Board restaffing

[Steve Langasek]

Hi Scott, Bhavani,

On Thu, Jan 31, 2013 at 03:02:44AM +, Scott Kitterman wrote:

 Regardless of if it's the DMB or other delegated body, the decision about
 upload rights is on behalf of the Ubuntu project and it needs to be taken
 with the project's needs in mind.  I don't think there is any inherent
 right to upload to the archive.  Generally it is in the project's interest
 to grant upload rights where technically and socially appropriate, so
 there is rarely any conflict between the needs of the project and the
 desires of the applicant, but I do think it's important to remember on
 whose behalf we act.

I agree with that principle.  What concerns me is that the needs of the
project are harmed not only by granting upload rights to people who are not
ready for them (or who may never be ready for them); they are also harmed if
we raise so high a bar to membership that the community withers, or if
existing developers have to spend excessive time on sponsorship of
contributors that they believe are ready to have the training wheels come
off.  I fear that the DMB is dealing with the problem on one end at the
expense of the other end, and think it's important that a better balance be
struck.

I am specifically not arguing that the DMB should reverse their decision
about the two applications in question - I don't think it's my place to
second-guess the DMB.  What I /am/ arguing is that there is too much
uncertainty leading /up to/ the meetings about whether a given applicant is
ready.  I mean, come on - Adam and Björn are both sharp guys, and
contributing to Ubuntu is part of their day job.  There's no reason they
shouldn't have both been able to work towards the DMB's standards over the
course of, say, six months, and get approved for upload rights on the first
go... /except/ that no one really knows what the DMB's standards are, so
it's not possible for other developers in the community to reliably guide
them.

 I usually know how I'm likely to vote before such a meeting starts.  From
 my perspective, the meeting should be largely confirmatory and questioning
 should be to establish what further training someone might need in the
 short term.  In cases where I've been one of the people deciding if
 someone should be granted upload rights and I think the person is not
 ready, I like to seek them out and discuss it with them.  That way they
 can consider if they should apply or not or I might learn something new
 and help them improve their application.

 I do not think that it is possible to reduce the decision about if someone
 is ready for upload rights to quantifiable standards that give complete
 certainty about if one is ready or not.  I have recommended people for
 MOTU/core-dev based on varying standards appropriate to the individual. 
 Some people I trust to be well technically versed enough to tackle most
 Ubuntu development tasks, while others have much narrow knowledge, but I
 trust them to understand the limits of their understanding to and ask if
 needed.  Specifically, I think proposals to handcuff the DMB such as [1]
 are not a good idea.

Yes, there's no way to make this 100% quantifiable.  Do you agree, though,
that the current wiki guidance is too vague, and doesn't adequately map to
the DMB's existing decision-making process?  Do you agree that this is
something that should be addressed, to improve the reliability (and speed)
of the approval process - not by compromising our technical standards, but
by making clear what those are so applicants can prepare for them
appropriately?

Taking Adam as an example again, I understand that the feedback he was given
was that the DMB wanted to see some merges from Debian before they would
consider him ready.  This was very surprising to me, because Adam had
already done quite a bit of SRU work - which I think is the more difficult
process to get right.  And whereas SRUs are mentioned on
https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess, merges
are not.  Do you agree that if there are specific areas of involvement that
the DMB are going to consider prerequisites for uploader status (such as
package merges), that these should be called out in the wiki documentation?

 I want people to succeed.  The way to do that is through communication
 before and after the meeting.  Before the meeting, to try to get any
 concerns addressed and afterwards to make sure that anyone who was not
 approved understands why.

 I do not think we need another mailing list to debate the merits of
 particular applications.  People with opinions about an application should
 document them on the applicant's wiki (you can document NOT RECOMMENDED
 opinions - I've never seen anyone else do it, but I certainly have).  I
 think that specific detailed feedback from the DMB should be speedy and
 private.  If the applicant cares to make it public, they can, but since
 it's their application that's been rejected, I think they should decide.

When an applicant is 

Re: Call for votes: Developer Membership Board restaffing

[Scott Kitterman]

On Thursday, January 31, 2013 04:12:25 PM Steve Langasek wrote:
 Hi Scott, Bhavani,
 
 On Thu, Jan 31, 2013 at 03:02:44AM +, Scott Kitterman wrote:
  Regardless of if it's the DMB or other delegated body, the decision about
  upload rights is on behalf of the Ubuntu project and it needs to be taken
  with the project's needs in mind.  I don't think there is any inherent
  right to upload to the archive.  Generally it is in the project's interest
  to grant upload rights where technically and socially appropriate, so
  there is rarely any conflict between the needs of the project and the
  desires of the applicant, but I do think it's important to remember on
  whose behalf we act.
 
 I agree with that principle.  What concerns me is that the needs of the
 project are harmed not only by granting upload rights to people who are not
 ready for them (or who may never be ready for them); they are also harmed if
 we raise so high a bar to membership that the community withers, or if
 existing developers have to spend excessive time on sponsorship of
 contributors that they believe are ready to have the training wheels come
 off.  I fear that the DMB is dealing with the problem on one end at the
 expense of the other end, and think it's important that a better balance be
 struck.
 
 I am specifically not arguing that the DMB should reverse their decision
 about the two applications in question - I don't think it's my place to
 second-guess the DMB.  What I /am/ arguing is that there is too much
 uncertainty leading /up to/ the meetings about whether a given applicant is
 ready.  I mean, come on - Adam and Björn are both sharp guys, and
 contributing to Ubuntu is part of their day job.  There's no reason they
 shouldn't have both been able to work towards the DMB's standards over the
 course of, say, six months, and get approved for upload rights on the first
 go... /except/ that no one really knows what the DMB's standards are, so
 it's not possible for other developers in the community to reliably guide
 them.

I don't find anything to disagree with here.  There are (at least) two problems 
that lead to this:

 - The first order problem is that standards aren't quantified.  This makes it 
difficult to know if one is qualified or not.  It also makes it difficult for 
there 
to be a common standard among all DMB members.

 - The second order effect is that there is no DMB standard, there is only 
the collection of the standards of the individual members of the DMB.

I recall experienced Kubuntu contributors being denied MOTU specifically on the 
basis of most of their experience was with KDE based packages.  IMO, this was 
nonsense.  There are many KDE packages in Universe that need MOTU to watch 
after them and in any case KDE packages aren't notably different than others.

As I have watched the process, DMB members roughly fall into two camps:

1.  The applicant should know enough to contribute usefully without the 
supervision of the sponsorship process and be experienced enough and socially 
responsible enough to ask for help if they need it and to fix stuff if they 
break it.

2.  The applicant should be broadly versed within the scope of the rights 
being applied for to handle anything that might come up.

Some people might think it's obvious which of these is correct, but there is a 
diversity of opinion.  I know one person that declined to apply for core-dev 
until they knew kernel packaging well enough to be comfortable uploading the 
kernel because they thought a core-dev should be ready to deal with every 
package in the archive.  I believe an election is the perfect time to find out 
how candidates feel about this and vote for ones that you agree with.  IMO, I 
have seen some DMB members be very strongly in camp #2 and vote people down 
who I thought were reasonably qualified.

If you think that the DMB is being to parsimonious with upload rights, then 
find out how the candidates view this question.  I think it will tell more than 
any wiki page.  For avoidance of doubt, I'm firmly in camp #1.

  I usually know how I'm likely to vote before such a meeting starts.  From
  my perspective, the meeting should be largely confirmatory and questioning
  should be to establish what further training someone might need in the
  short term.  In cases where I've been one of the people deciding if
  someone should be granted upload rights and I think the person is not
  ready, I like to seek them out and discuss it with them.  That way they
  can consider if they should apply or not or I might learn something new
  and help them improve their application.
  
  I do not think that it is possible to reduce the decision about if someone
  is ready for upload rights to quantifiable standards that give complete
  certainty about if one is ready or not.  I have recommended people for
  MOTU/core-dev based on varying standards appropriate to the individual.
  Some people I trust to be well technically versed enough 

Re: Call for votes: Developer Membership Board restaffing

[Bhavani Shankar R]

On Fri, Feb 1, 2013 at 5:42 AM, Steve Langasek
steve.langa...@ubuntu.com wrote:
 Hi Scott, Bhavani,


snip


 On Thu, Jan 31, 2013 at 11:36:38AM +0530, Bhavani Shankar R wrote:
 What I believe is a perspective developer gets ready for applying at a
 particular level when a minimum of one developer of ranks of core dev
 believes that the applicant is ready for a particular level of upload
 rights and having more than one of them vouching for the applicants'
 skills does no harm.

 I have been working with the ubuntu developer advisory team a fair
 bit, reaching out to contributors, helping them by providing pointers
 in their interested area of ubuntu development, helping contributors
 in preparing their wiki page for the DMB meeting once they seem to be
 ready and also reaching out to contributors who have gone inactive
 over a period of time (maybe due to lack of time or lack of motivation
 due to rejection of application by DMB for instances) and collecting
 their feedback and motivating them.

 Ofcourse, as you mentioned, the developers who are on the board would
 have their own thoughts about the applicant and what I would not do is
 to point out any shortcomings on a public list (which I am presuming
 that it would be viewable to the entire world), simply because it
 would give raise to the concern of motivation level drop for an
 applicant (if feedback given is not taken in the right sense and right
 manner).

 FWIW this concern that feedback on specific applicants not be made public
 does not resonate with me.  I think the greater drain on motivation is from
 putting oneself forward at all (at the prompting of one's peers) only to
 have the DMB tell them they aren't ready.  I think it's far more important
 to make sure Ubuntu developers understand the DMB's thinking, so that we
 collectively are able to give applicants the guidance they need to be
 successful.


I totally agree that DMB feedback is important to the Ubuntu Community
and I would like to go with what Scott said, Maybe we can try
criticising them in private most times because when we criticize in
public for instance many other perspective developers when they look
at the feedback given, they could tend to get a what if I am
rejected  fear and might not apply which gives rise to a totally
opposite scenario of application rejection from the DMB. (v/s not
applying at all).

So, I also agree with Scott's second point that feedback might not
necessarily be on a per application basis per se, but what we can have
is a detailed meeting minutes summarizing as to what was each
aggregate application outcomes and a short and concise view of why the
DMB thought the application was not upto the mark.

/me puts his dev advisory team hat on for a moment now.

I like Daniel's idea of having an informal exchange (maybe over a ping
or a pm on irc) of how the DMB thinks so that we can really get an
info of how the DMB thinks on various cases so that we can provide a
broad overview of what the DMB thinks while one is ready for an
application and provide them feedback before they apply and sometimes
after one gets rejected too, so that it can help in simplifying the
situation by providing inputs to the contributors as to what they are
expected to do and reduce the number of incomplete or a application
coming to the DMB in the incorrect area of upload rights intended.

 What I would do is if I deem to see an application incomplete or
 perhaps a bit early to apply to the particular set of upload rights, I
 would simply abstain with a short explanation and then catch up with
 the applicant privately on a detailed view of what I thought of his
 application, his positives and why I exactly thought his application
 was incomplete, So that it enables him to focus on the shortcomings
 and hone his strengths even better.

 In short, I would rather prefer to a soft redirect, considering the
 applicants' work with the passion and motivation factor that comes
 into picture when contributing to an open source environment.

 Do you agree with my argument that if such soft redirects are happening in
 large numbers, this is a problem?


Large number of rejections are definitely a problem because it can
create a psychological impact on the existing contributors who have
not yet applied for upload rights and much more potential contributors
in the pipeline. Which boils down to three points in my view:

1. The DMB procedures are well documented but can have difficulties in
quantifying the same as on any given day each person on the DMB is
free to interpret situations in his own manner.

2. Lack of prerequisite information/awareness of the processes on the
applicant side eventually ending up applying for a wrong area of
upload rights in ubuntu (IMHO, thinking levels and interpretation of
things will differ from person to person), which might lead to change
of application areas as we have seen in the past where DMB and
applicants' thinking have differed.

3. Fear of rejection 

Re: Call for votes: Developer Membership Board restaffing

[Scott Kitterman]

On Friday, February 01, 2013 11:27:07 AM Bhavani Shankar R wrote:
...
 I like Daniel's idea of having an informal exchange (maybe over a ping
 or a pm on irc) of how the DMB thinks so that we can really get an
 info of how the DMB thinks on various cases so that we can provide a
 broad overview of what the DMB thinks while one is ready for an
 application and provide them feedback before they apply and sometimes
 after one gets rejected too, so that it can help in simplifying the
 situation by providing inputs to the contributors as to what they are
 expected to do and reduce the number of incomplete or a application
 coming to the DMB in the incorrect area of upload rights intended.
...
The trick here is that unless you ping everyone on the DMB, you don't have 
how the DMB thinks about an application.  The DMB is a collective of 
individuals with individual perspectives.  This could easily evolve into some 
kind of pre-meeting which a think would be a serious mistake.

While the advisory team may advise, I think it's on the applicant to discuss 
their application with some DMB members if they want to.  I believe that the 
people that are in the best position to give people advice on when to apply 
are their sponsors.  I don't think anyone should be in the role of 
intermediary.

Scott K

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Call for votes: Developer Membership Board restaffing

[Bhavani Shankar R]

On Fri, Feb 1, 2013 at 11:41 AM, Scott Kitterman ubu...@kitterman.com wrote:
 On Friday, February 01, 2013 11:27:07 AM Bhavani Shankar R wrote:
 ...
 I like Daniel's idea of having an informal exchange (maybe over a ping
 or a pm on irc) of how the DMB thinks so that we can really get an
 info of how the DMB thinks on various cases so that we can provide a
 broad overview of what the DMB thinks while one is ready for an
 application and provide them feedback before they apply and sometimes
 after one gets rejected too, so that it can help in simplifying the
 situation by providing inputs to the contributors as to what they are
 expected to do and reduce the number of incomplete or a application
 coming to the DMB in the incorrect area of upload rights intended.
 ...
 The trick here is that unless you ping everyone on the DMB, you don't have
 how the DMB thinks about an application.  The DMB is a collective of
 individuals with individual perspectives.  This could easily evolve into some
 kind of pre-meeting which a think would be a serious mistake.

Totally agreed and my point intended was the same that each person on
the DMB will have their own way of thinking and interpreting the
situations, So what we can do is to ping all the members of the DMB
informally if feasible or perhaps even mail members of the DMB in
person and collect feedback of what DMB thinks.


 While the advisory team may advise, I think it's on the applicant to discuss
 their application with some DMB members if they want to.  I believe that the
 people that are in the best position to give people advice on when to apply
 are their sponsors.  I don't think anyone should be in the role of
 intermediary.

Agreed again and going by the principles of the team, we only provide
feedback and pointers to people regarding various areas of ubuntu
development and whom to reach out for when in doubts and I dont see
any intermediate role arising here on the part of the dev advisory
team [1] [2]

In short, as Daniel said, we would love to simplify the process by
collecting the feedback and passing it on to the applicants and
helping them in case of issues, whilst not advising the applicants nor
speaking on behalf of any applicant.

Hope this clarifies :)

[1] https://wiki.ubuntu.com/DeveloperAdvisoryTeam

[2] https://wiki.ubuntu.com/MeetingLogs/devweek1208/DevAdvisoryTeam

Regards,
-- 
Bhavani Shankar
Ubuntu Developer   |  www.ubuntu.com
https://launchpad.net/~bhavi

-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Call for votes: Developer Membership Board restaffing

[Steve Langasek]

Hello,

On Wed, Jan 30, 2013 at 09:36:19AM -0600, Micah Gersten wrote:
 The Developer Membership Board has started a vote to restaff for the
 four members whose terms are expiring. The Developer Membership Board is
 responsible for reviewing and approving new Ubuntu developers. It
 evaluates prospective Ubuntu developers and decides when to entrust them
 with developer privileges. There are seven candidates:

 Benjamin Drung (bdrung) https://wiki.ubuntu.com/BenjaminDrung
 Bhavani Shankar (coolbhavi) https://wiki.ubuntu.com/BhavaniShankar
 Cody Somerville (cody-somerville) https://wiki.ubuntu.com/CodySomerville
 Dmitrijs Ledkovs (xnox) 
 https://wiki.ubuntu.com/DmitrijsLedkovs/DMBApplication
 Iain Lane (Laney) https://wiki.ubuntu.com/IainLane/DMB2013
 Scott Kitterman (ScottK) https://wiki.ubuntu.com/ScottKitterman
 Stéphane Graber (stgraber) https://wiki.ubuntu.com/stgraber

At the January DMB meeting, there were two applicants, both of whom were
rejected.  It doesn't say that on paper; on paper it says that Adam Stokes's
application was changed to contributing member during the meeting and was
approved.  But the long and the short of it is that two people with a
substantial history of contributing to Ubuntu in their respective domains
applied for upload rights in January, were recommended by existing Ubuntu
developers, and were denied upload rights by the DMB.

I understand that the DMB won't always agree with their fellow Ubuntu
Developers about whether a particular applicant is ready for a particular
uploader status.  But I do think it's important that when the DMB disagrees
with the developers who are recommending someone for uploader status, there
be transparency about the reasons for this disagreement.  Currently, the
wiki says:

  It can be difficult to know when you are ready to apply for uploader team
  membership.

  (https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess)

That's certainly true, but I think this is something that the DMB has a duty
to correct.  Frankly, I think there's no reason that Adam and Björn couldn't
have been ready for upload rights by January, *if* the DMB's expectations
were made clearer.  If there were documented standards that at least tried
to be objective, people who are aiming to get upload rights can be working
to those standards in advance, instead of being told in the DMB meeting that
the work they've been doing doesn't tick the right boxes on the DMB's
invisible checklist.

So my question to each of the candidates is this.  As a member of the DMB,
what would you do to remove this uncertainty around when people are ready to
apply, reducing the number of rejections (whether those are hard rejects, or
soft redirects) at DMB meetings?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Call for votes: Developer Membership Board restaffing

[Dmitrijs Ledkovs]

On 31/01/13 00:22, Steve Langasek wrote:
 Hello,
 
 On Wed, Jan 30, 2013 at 09:36:19AM -0600, Micah Gersten wrote:
 The Developer Membership Board has started a vote to restaff for the
 four members whose terms are expiring. The Developer Membership Board is
 responsible for reviewing and approving new Ubuntu developers. It
 evaluates prospective Ubuntu developers and decides when to entrust them
 with developer privileges. There are seven candidates:
 
 Benjamin Drung (bdrung) https://wiki.ubuntu.com/BenjaminDrung
 Bhavani Shankar (coolbhavi) https://wiki.ubuntu.com/BhavaniShankar
 Cody Somerville (cody-somerville) https://wiki.ubuntu.com/CodySomerville
 Dmitrijs Ledkovs (xnox) 
 https://wiki.ubuntu.com/DmitrijsLedkovs/DMBApplication
 Iain Lane (Laney) https://wiki.ubuntu.com/IainLane/DMB2013
 Scott Kitterman (ScottK) https://wiki.ubuntu.com/ScottKitterman
 Stéphane Graber (stgraber) https://wiki.ubuntu.com/stgraber
 
 So my question to each of the candidates is this.  As a member of the DMB,
 what would you do to remove this uncertainty around when people are ready to
 apply, reducing the number of rejections (whether those are hard rejects, or
 soft redirects) at DMB meetings?
 

A prospective developer is ready to apply when one gets an endorsement
from a core-dev for a particular developer membership level. This is not
dis-similar to Debian New Member process where a DD advocates one's
application.

I'd like to use devel-permissions mailing list to discuss applications
with applicants, DMB and subscribers to devel-permissions mailing list.
This should reduce the number of rejections and/or downgrades, hopefully
not make meetings over-run, as well as allow to further scrutinize
applications.

In his application, Iain mentions that DMB should sumamrise the reasons
any candidates are not accepted on a public mailing list [1]. I'd
rather also raise concerns on the public mailing list with the
applicant, before the meeting and before the decision has already been made.

[1] https://wiki.ubuntu.com/IainLane/DMB2013

-- 
Regards,
Dmitrijs.



signature.asc
Description: OpenPGP digital signature
-- 
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Call for votes: Developer Membership Board restaffing

[Scott Kitterman]

On Wednesday, January 30, 2013 04:22:58 PM Steve Langasek wrote:
 Hello,
 
 On Wed, Jan 30, 2013 at 09:36:19AM -0600, Micah Gersten wrote:
  The Developer Membership Board has started a vote to restaff for the
  four members whose terms are expiring. The Developer Membership Board is
  responsible for reviewing and approving new Ubuntu developers. It
  evaluates prospective Ubuntu developers and decides when to entrust them
  
  with developer privileges. There are seven candidates:
  Benjamin Drung (bdrung) https://wiki.ubuntu.com/BenjaminDrung
  Bhavani Shankar (coolbhavi) https://wiki.ubuntu.com/BhavaniShankar
  Cody Somerville (cody-somerville)
  https://wiki.ubuntu.com/CodySomerville
  Dmitrijs Ledkovs (xnox)
  https://wiki.ubuntu.com/DmitrijsLedkovs/DMBApplication Iain Lane
  (Laney) https://wiki.ubuntu.com/IainLane/DMB2013
  Scott Kitterman (ScottK) https://wiki.ubuntu.com/ScottKitterman
  Stéphane Graber (stgraber) https://wiki.ubuntu.com/stgraber
 
 At the January DMB meeting, there were two applicants, both of whom were
 rejected.  It doesn't say that on paper; on paper it says that Adam Stokes's
 application was changed to contributing member during the meeting and was
 approved.  But the long and the short of it is that two people with a
 substantial history of contributing to Ubuntu in their respective domains
 applied for upload rights in January, were recommended by existing Ubuntu
 developers, and were denied upload rights by the DMB.

I'm not a sitting member of the DMB and have not looked into these specific 
cases, so my thoughts should be taken on a general basis and not at all 
related to these individuals or their applications.

I object a bit to your formulation of the situation though.  I think denied 
upload rights is backwards.  Not granted upload rights would be much 
better.  I've got a fair amount of experience with making the decision about 
if someone should be given upload rights or not.  I do that currently as a 
member of kubuntu-dev and also did so for MOTU applications when I was a 
member of one of the DMB predecessor organizations, the MOTU Council.

Regardless of if it's the DMB or other delegated body, the decision about 
upload rights is on behalf of the Ubuntu project and it needs to be taken with 
the project's needs in mind.  I don't think there is any inherent right to 
upload to the archive.  Generally it is in the project's interest to grant 
upload rights where technically and socially appropriate, so there is rarely 
any conflict between the needs of the project and the desires of the applicant, 
but I do think it's important to remember on whose behalf we act.

 I understand that the DMB won't always agree with their fellow Ubuntu
 Developers about whether a particular applicant is ready for a particular
 uploader status.  But I do think it's important that when the DMB disagrees
 with the developers who are recommending someone for uploader status, there
 be transparency about the reasons for this disagreement.  Currently, the
 wiki says:
 
   It can be difficult to know when you are ready to apply for uploader team
   membership.
 
   (https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess)
 
 That's certainly true, but I think this is something that the DMB has a duty
 to correct.  Frankly, I think there's no reason that Adam and Björn
 couldn't have been ready for upload rights by January, *if* the DMB's
 expectations were made clearer.  If there were documented standards that at
 least tried to be objective, people who are aiming to get upload rights can
 be working to those standards in advance, instead of being told in the DMB
 meeting that the work they've been doing doesn't tick the right boxes on
 the DMB's invisible checklist.
 
 So my question to each of the candidates is this.  As a member of the DMB,
 what would you do to remove this uncertainty around when people are ready to
 apply, reducing the number of rejections (whether those are hard rejects,
 or soft redirects) at DMB meetings?

I usually know how I'm likely to vote before such a meeting starts.  From my 
perspective, the meeting should be largely confirmatory and questioning should 
be to establish what further training someone might need in the short term.  
In cases where I've been one of the people deciding if someone should be 
granted upload rights and I think the person is not ready, I like to seek them 
out and discuss it with them.  That way they can consider if they should apply 
or not or I might learn something new and help them improve their application.

I do not think that it is possible to reduce the decision about if someone is 
ready for upload rights to quantifiable standards that give complete certainty 
about if one is ready or not.  I have recommended people for MOTU/core-dev 
based on varying standards appropriate to the individual.  Some people I trust 
to be well technically versed enough to tackle most Ubuntu