Re: Call for votes: Developer Membership Board restaffing
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
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
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
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
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
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
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
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
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
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
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
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
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
On Fri, Feb 1, 2013 at 11:41 AM, Scott Kitterman 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
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
On Fri, Feb 1, 2013 at 5:42 AM, Steve Langasek wrote: > Hi Scott, Bhavani, > > > 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 applica
Re: Call for votes: Developer Membership Board restaffing
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 ind
Re: Call for votes: Developer Membership Board restaffing
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 shou
Re: Call for votes: Developer Membership Board restaffing
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
On Jan 31, 2013, at 05:08 PM, Jani Monoses wrote: >There is too much coupling between Ubuntu membership and upload rights. This comes up often, and there have been discussions about separating the two aspects but nothing's come of it. I do think it would be useful to separate these concerns, especially as it pertains to PPU. >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. +1 IMHO. >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. FWIW, as a DMB member who is not up for re-election this year, I do put a lot of weight into the endorsements, especially when they come from highly respected Ubuntu developers. I think of it as "vouching" for the prospective developer and shouldn't be given or taken lightly. As much due diligence as the DMB does and should do, sponsors have more direct and high-bandwidth interactions with the prospective developer, and that feedback is very valuable. Occasionally, a sponsor will contact the DMB directly to vouch for someone, and I have found that to be quite persuasive. I don't think it's necessary in every case (please don't bombard us! :) but for decisions where I've been on the fence, strong positive endorsements can make the difference. Cheers, -Barry -- 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
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
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 privileg
Re: Call for votes: Developer Membership Board restaffing
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
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
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
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
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
On Thursday, January 31, 2013 11:43:41 AM Daniel Holbach wrote: > 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. 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. 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
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
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
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
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
On Thu, Jan 31, 2013 at 5:52 AM, 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? > Hello Steve, 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). 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. 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
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 pe
Re: Call for votes: Developer Membership Board restaffing
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
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