Debian Project Leader Elections 2013: Call for votes
Hi,
This is the first call for votes for the Debian Project Leader
Elections 2013.
Voting period starts 00:00:00 UTC on Sunday, March 31st, 2013
Votes must be received by 23:59:59 UTC on Saturday, April 13th, 2013
This vote is being conducted as required by the Debian Constitution.
You may see the constitution at http://www.debian.org/devel/constitution.
For voting questions or problems contact secret...@debian.org.
The details of the candidate platform can be found at:
http://www.debian.org/vote/2013/platforms/
Also, note that you can get a fresh ballot any time before the end of
the vote by sending a mail to
bal...@vote.debian.org
with the subject "leader2013".
HOW TO VOTE
First, read the full text of the platform.
To cast a vote, it is necessary to send this ballot filled out to a
dedicated e-mail address, in a signed message, as described below.
The dedicated email address this ballot should be sent to is:
leader2...@vote.debian.org
The form you need to fill out is contained at the bottom of this
message, marked with two lines containing the characters
'-=-=-=-=-=-'. Do not erase anything between those lines, and do not
change the choice names.
There are 4 choices in the form, which you may rank with numbers between
1 and 4. In the brackets next to your preferred choice, place a 1.
Place a 2 in the brackets next to your next choice. Continue until you
reach your last choice. Do not enter a number smaller than 1 or larger
than 4.
You may skip numbers, leave some choices unranked, and rank options
equally. Unranked choices are considered equally the least desired
choices, and ranked below all ranked choices.
To vote "no, no matter what", rank "None Of The Above" as more desirable
than the unacceptable choices, or you may rank the "None Of The Above"
choice and leave choices you consider unacceptable blank. (Note: if the
"None Of The Above" choice is unranked, then it is equal to all other
unranked choices, if any -- no special consideration is given to the
"None Of The Above" choice by the voting software).
Finally, mail the filled out ballot to: leader2...@vote.debian.org.
Don't worry about spacing of the columns or any quote characters (">") that
your reply inserts.
NOTE: The vote must be GPG signed (or PGP signed) with your key that is
in the Debian keyring. You may, if you wish, choose to send a signed,
encrypted ballot: use the vote key appended below for encryption.
The voting software (Devotee) accepts mail that either contains only an
unmangled OpenPGP message (RFC 2440 compliant), or a PGP/MIME mail
(RFC 3156 compliant). To avoid problems I suggest you use PGP/MIME.
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
8367b943-96ac-4530-afbd-529da5fc4fd5
[ ] Choice 1: Gergely Nagy
[ ] Choice 2: Moray Allan
[ ] Choice 3: Lucas Nussbaum
[ ] Choice 4: None Of The Above
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
--
The responses to a valid vote shall be signed by the vote key created
for this vote. The public key for the vote, signed by the Project
secretary, is appended below.
-BEGIN PGP PUBLIC KEY BLOCK-
Version: GnuPG v1.4.12 (GNU/Linux)
mQINBFFXZ+YBEACXvc2fxRFSf/75RnGGzKjNV7JxccJdFdZuufCGuLcH9FwFi6ds
/cCk3yafi0XXYQabAYnXVdDhzAxPEIXydyjRETIZuPXGn6N/alyabB3tL0sFA84k
FPTkfUWpcPYb0NkIC+SyhZeubq/BHgSRLfq+PpvrR7hpRUWUBU+LkSTLjw4W9DIP
vY0BWxVIODD7lQI/nv3DkhEP6OsCDmt6u9gnTC+GCE25rEIg5On7kunRgF9kyyrS
eSbQYhFGoboiCtbOdr9zGZw+rov+rZWXKJeGD5fg2QBtzTP1DbbkHSjQu2MO9V1C
iYY8tqsroRWRr3x5UToBISn2wv8zc6igh5SUYddXzvbwKmVvR3xAF7qav43Afhsf
ccry77jk/bp48tlBc8YCw+9UDE+UxxmjrVGJvwYfNTEas7l4wgX2LhZOAXgsPckp
Fx9kJ95Ot3yFgqKGFyLH4VCHwUMG9N2X0qeZzVmRPVVik71n3ZB+1ak4XUigIEdt
4l6a4s4I4QYrvTZvidJmvdHHfjI0SnV1HeZbs1Fpy7ItiutztJr6LuBNhQEvhLOe
WJzYKEjrSR3DnJ0qqToNcGmVDEUMDgv0Htt4iSj5QqtLWHVIUdURRcaTNWMXekO0
kJDwA8gQuhCmB/tUHhVEzjAW2khuaW9Wq6+6OEVlJa9lPOrN3bj83bo8kwARAQAB
tDhEZWJpYW4gTGVhZGVyIGVsZWN0aW9uIDIwMTMgPGxlYWRlcjIwMTNAdm90ZS5k
ZWJpYW4ub3JnPokCPgQTAQIAKAUCUVdn5gIbAwUJABUYAAYLCQgHAwIGFQgCCQoL
BBYCAwECHgECF4AACgkQITFK+nr1KB3pSg/+NGhu/4W/D02IgkkW9Gjr+XH10X4Z
OPtBRY9OSoTWBIHBuwsoSg/uvUc76+Uu+xUIzDAZxUnP4y5cE6XBuvoGieY4jvK6
FXOI4p2UjEMwFqoNgnftotcDMhjiT5gTH58ZEU9v0WWSQff+mUtQd9OpkgEL4qgB
vMG+GvOZB2LIuyLYPxktlkhl3YTetnlS0/WFmV0k6unmW06uiwqPGOGye719aY74
qsYng4FCHVEcbt9Y73k9vGnj2WAyt1CCxzh9S7Ssj4GM1pogoVJmWrA9PGlQsmnh
nCpqqlGSJ8JwpPekYCrP1I17f2ff+II15HpCsYvSP1I4tEvLz88Y/suMye6Zwlyj
8Ncr4CLnEPeOaxSo6wd+qUh/m0byL32CBHQx0P8JIvIyDkrGfwfMUeB12kSnX3yv
yGJTi7L0CsArhtnp5WjBG3UL/zK12QI443LtXTqA4VNDHusYKBhj+rCJVn1EfuPY
EeMLN2Tgcz3Y8OtpGUzPLA00sL63D6tPN619NQ35K2E/ddPz605yI/o+tuq3nx4l
d5VkxKoCKZxiXNDNXMCxxP3tlY5LnR9zIxp0MThm16ZNCZlTg5X06Q/3GJUPZeFY
JF4LrkXy4ICL2JgeQ1WtqPQAuEP61f8CGu/MB+F0J3s29bcqJ/ZhDTO9fLl1uq5G
W7VUhKxUKNDEfQmJAhwEEwEKAAYFAlFXaHQACgkQIGTFNkHCXl0GMxAAg0sujyiC
kD+Ac911wQijUmL94lNXzbEP58gFwAdTPZu/TdcfvUxNWHefz3JtHboQ0xz1590H
iubqXZpEE2xbcR981
Re: [all candidates] Removing or limiting DD rights?
gregor herrmann writes: > On Mon, 25 Mar 2013 18:02:08 +0100, Lucas Nussbaum wrote: > >> On 25/03/13 at 16:22 +, Steve McIntyre wrote: >> > Are we strict enough with our existing contributors? When we're trying >> > to work together as best we can to make the Universal Operating System >> > happen, what could/should we do with contributors who hinder our work? >> > Sometimes that hindrance is inadvertent, sometimes it seems >> > deliberate. At other times it looks like we have developers who are >> > just not paying attention to what they're doing or who just don't care >> > about the goals of the project. > > Thanks for this question, which I would like to extend a bit. > Im my understanding you are pointing to unconstructive behaviour > related to technical work. What we also see (and discuss) every now > and then is behaviour that is socially questionable or clearly > unacceptable (from disrespect for peers to blatant abusive language). > > I guess we all remember such examples, which have led to > demotivation, frustration, hurt feelings, and have driven > contributors away. Indeed, I do remember. But - like Moray - as far as I see, this happens fewer times than it did in the past, at least on the most public lists (it does happen nevertheless, especially in those long threads we all know and "love"...). This being less of an issue than it was a decade ago, is good. There's certainly room for improvement, nevertheless. >> One small thing that we could improve on is earlier official >> communication. For example, in case of seriously problematic behaviour >> that could eventually lead to censure or expulsion, official warnings >> could be issued to the DD, and Cced to -private@. In some cases, that >> could help the DD realize that s/he needs a behaviour change, and also >> limit the surprise effect if/when a final decision is taken. > > What other ideas do you (plural, for all candidates, in case you see > the necessity to improve the handling of "social problems") see as > viable? I'll answer your specific answers first: > Examples that have come up in the past and might or might not be > helpful: > - Encourage everyone to chime in when they see potentially > unacceptable behaviour? In public/private? The problem with this is that multiple people independently chiming in has the tendency to make things worse. A more coordinated effort would help that, and if we had single coordinating contact point to help, that'd be great. (These do exist, owner@bugs.d.o and listmaster@, as Don mentioned earlier, but I am as of yet, unsure whether they're used this way, and how often.) I would encourage chiming in privately, and in a coordinated manner, with a single statement publicly, to discourage others from public flaming (and instead, point them towards the coordinated effort). > - Should we try to establish a Code of Conduct for project members? > Cf. https://openhatch.org/wiki/Project_codes_of_conduct for > examples. > If yes, how would we do this, and how could we make sure it gets > respected? > - Could the CoC for mailing lists > (http://www.debian.org/MailingLists/#codeofconduct) > be used as a starting point / be extended? > - Or Enrico's Debian Community Guidelines? > http://people.debian.org/~enrico/dcg/index.html I'm not a terribly big fan of Codes of Conduct, because they're vague and very, very general, and as such, subject to interpretation. What I would consider a flame, or common sense may be much different than someone else thinks. I've grown up on IRC, and frequented channels where foul language and flames were a daily show (and I'm not ashamed to admit, that I enjoyed these, one could learn a lot about how not to behave, and what triggers a flame. I found it very educational at the time.) Enforcing the CoC is also quite a big task. However, there's one good thing about them: they send a message, that we're serious about caring about and nurturing our community. For that reason alone, a CoC is worth it. I do like Enrico's guidelines though. Something along those lines, and the mailing list CoC would make sense, in my opinion. Perhaps both! A CoC, a short, generic code, and the Guidelines, for more in-depth suggestions. The Guidelines would be treated only as such, though - guidelines, not enforcable, but a reasonable basis of peace talks. > - Another recurring topic is the Social Committee, cf. e.g. > https://lwn.net/Articles/221077/ (or the ombudsman team mentioned > in the article: > https://lists.debian.org/debian-project/2007/01/msg00101.html ) > Would such a body make sense? With which powers? I would find such a body useful, but not in the way it is explained in Gustavo's mail (there's quite a few things I disagree with, like a public pseudo package in the BTS for the task). As for powers - I would not wish to grant the body any particular power, but rather, ask them to channel issues to the DPL, and they together would decide how to proceed, wit
Re: [all candidates] What to do with debian-private ?
Charles Plessy writes: > If this has not changed, is that something that the DPL candidates would > like to tackle ? (Bonus question to the DPL candidates: are you subscribed > to debian-private ?) Private is like it always was (I am subscribed, and have been for every day of my DDship). Fortunately, modern mail clients can mark a whole thread read, so if the subject is not interesting, it's just a button away, and the whole thread disappears. And if I don't read it, it's not hard to keep that information private, whether it belonged to -private in the first place, or not. As such, whatever goes on on -private, it doesn't really bother me. The traffic is low enough to handle. (But then, I'm subscribed to -bugs-dist@ AND lkml, so my definition of low may not be shared by most.) Nevertheless, I have no intention of trying to change how -private@ is used. I could imagine ways to make it more useful, but I don't see the effort being worth the trouble. -- |8] -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762087fi6@galadriel.madhouse-project.org
Re: [all candidates] What to do with debian-private ?
On Sat, Mar 30, 2013 at 08:59:39AM +0100, Wouter Verhelst wrote: > I'm not sure we need that. There's an expectation that vacation messages > have a [vac] prefix in the subject, which is mostly followed (although > sometimes people do forget it). That makes it fairly easy to filter them > out for those who're not interested in them. Yes, and even a simple filter (mine is currently [.*vac\s*] or similar) works 99% of the time. I like replies to VACs to go to my -private folder. I use a similar scheme for ITPs on -devel. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130330163435.GA6722@debian
Re: [all candidates] What to do with debian-private ?
On 2013-03-29 19:34, Charles Plessy wrote: How is the state of -private those days ? When I unsubscribed, it was still mixing informations that are really private, like "Alice takes holidays in Honolulu", some that may be private by accident, like "Bob wants to package libfoo-perl", and some that are irrelevant, like "Claudius likes pasta well cooked", "Donna does not like discussions about pasta", and "Eros thinks that one should not be criticised for discussing about pasta on -private". I found it very tiring to have to permanently remember to never talk about a lot of things that should never have been private in the first place. If this has not changed, is that something that the DPL candidates would like to tackle ? (Bonus question to the DPL candidates: are you subscribed to debian-private ?) Yes, I am subscribed. I find it surprising that others are concentrating on whether the volume and mix of topics on debian-private are convenient for readers. For those questions, I would worry far more about debian-devel. [1] For debian-private, my worry is about messages that have no reason to be private. I don't find the volume that high, and VAC messages are easily filtered out by people who don't want to see them. But any discussion thread there tends to quickly move to include things that have no reason to be private -- and it takes some effort to move a discussion to a more appropriate public list without leaking any clues about the original private topic or including quoted text that people may want to keep private, so people don't bother, but just continue to reply about the topic on -private. I see this problem happen almost every time a thread on debian-private develops past a couple of messages. And I think it's bad, not only because our Social Contract says that "we will not hide problems", but for practical reasons. Where discussions don't have a genuine reason to be private, they will lead to more useful results for Debian if they are on a public list where we can benefit from the input of many more of Debian's contributors, and where they are easy to find later and can be cited in subsequent discussions. Even if someone tries to move or restart discussion of a non-private topic that has been discussed on -private, people tend to lack enthusiasm for re-posting to a public list the same kind of ideas they have already written about on -private. Part of the problem is that we automatically subscribe new project members to -private, but not any other list. It seems that there are a significant number of people who read debian-private without reading debian-project, which is where many -private threads would be more appropriate, or even debian-devel-announce, which we claim is mandatory. I liked Steve Langasek's previous suggestion of a one-off fix by unsubscribing everyone and posting resubscription instructions on -devel-announce [2] Moray [1] We presumably want to encourage new project contributors to read -devel, but it remains rather high-volume, and with a wide mix including significant bursts of traffic from ITP messages and "general" bugs that would logically make more sense on different lists. I understand that the intention is effectively to get more eyes to look at these by putting them on -devel, but for individual senders "Where will most people read this?" has never been an acceptable reason to choose a list to post to, but rather "Where will this be on topic *and the readers want to read it*?" With the combination of high-volume and non-discussion mails, I worry that new readers of -devel are likely to quickly get a build-up of messages that are uninteresting to them, then lose enthusiasm for trying to keep up-to-date with it. [2] Maybe putting the resubscription instructions as a footnote to a message about release management would be appropriate. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1afba77fb723f47e6eec220c46134...@www.morayallan.com
Re: [all candidates] What to do with debian-private ?
On 30-03-13 02:49, Russ Allbery wrote: > I have no objections to the vacation messages (personally, I find them > interesting), Same here. > but we could certainly make a separate list with the same > nondisclosure requirements as -private devoted specifically to those > messages and any followups around keysignings, etc. (and, probably more > broadly, for any other life events that Debian Developers want to share > internal to the project, such as marriages, new children, etc.), sort of a > DD-internal version of -curiosa, and keep -private as more a DD-internal > version of -project. I'm not sure we need that. There's an expectation that vacation messages have a [vac] prefix in the subject, which is mostly followed (although sometimes people do forget it). That makes it fairly easy to filter them out for those who're not interested in them. Personally, I've filtered them into a separate folder for years. While there are occasional false negatives, I can't remember the last time I had a false positive -- if that's ever occurred, which I'm not sure of. I think the current rules are fine. -- Copyshops should do vouchers. So that next time some bureaucracy requires you to mail a form in triplicate, you can mail it just once, add a voucher, and save on postage. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51569b6b.1030...@uter.be
Re: [all candidates] What to do with debian-private ?
On 30/03/13 at 10:34 +0900, Charles Plessy wrote:
> Le Thu, Mar 28, 2013 at 03:35:40PM -0700, Don Armstrong a écrit :
> >
> > -private is notified so DDs are aware.
>
> How is the state of -private those days ? When I unsubscribed, it was still
> mixing informations that are really private, like "Alice takes holidays in
> Honolulu", some that may be private by accident, like "Bob wants to package
> libfoo-perl", and some that are irrelevant, like "Claudius likes pasta well
> cooked", "Donna does not like discussions about pasta", and "Eros thinks that
> one should not be criticised for discussing about pasta on -private". I found
> it very tiring to have to permanently remember to never talk about a lot of
> things that should never have been private in the first place.
>
> If this has not changed, is that something that the DPL candidates would
> like to tackle ? (Bonus question to the DPL candidates: are you subscribed
> to debian-private ?)
Hi,
I am subscribed to -private@.
On some of our lists, we have a mix of different traffic that could have
been more clearly separated. That applies to -private@, but also to
-devel@, with the ITP mails.
I don't think that there's a widespread perception that this is a
serious problem that we should actively work on.
Generally, creating another list for the same audience, with the same
posting and visibility criterias (e.g. unmoderated; private archives)
results in more emails about "why is that mail on list A rather
than list B" than the amount of mail that some people considered
unwanted in the first place.
As an anecdote, at some point I was marginally involved in a project
whose main mailing list was fairly high traffic, due to lots of (mostly
interesting) discussions. Some people were complaining about the traffic
(on list, of course, so it generated even more traffic), and as a
result, another list, named debates@, was created. The idea was that,
once a discussion starts to grow too much on the main list, it should be
moved to the debates@ list so that people who were OK with high-traffic
lists could continue the discussion. Of course, this completely failed:
on the main list, there were many mails about "maybe it's time to move
that discussion to debates@", and some emails about "please don't, I
find this discussion interesting but I'm not subscribed to debates@".
So, creating sub-lists must be handled with care. Even if the case of
VAC messages, we have two kinds:
- social-only VAC messages ("I'll be in $city for 2 days next week, does
someone want to meet for a drink?"), where the resulting absence is
very unlikely to have an impact on the project.
- VAC messages that inform of an impact on the project. e.g. core team
member informing that s/he will change job and move to a new place,
resulting in reduced Debian activity for several months.
Lucas
--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130330071949.ga20...@xanadu.blop.info
