Re: On community and conflicts
Hi Russ, I realize I'm very late with this (sometimes one is just delayed with reading emails), but I wanted to thank you for this mail. I think it captures quite well how this all works, and why it is difficult to write down a set of rigid rules (occasionally, that is also why I did not add such a rigid set of rules to the code of conduct, when I wrote it). So, thanks! On Thu, Mar 16, 2023 at 08:57:33AM -0700, Russ Allbery wrote: > Roberto C. Sánchez writes: > > > I'm afraid that you miss the point. I specifically chose flat earth, & > > co., as a contrast. My position is that we are all adults, capable of > > deciding for ourselves and that, absent some behavior that is a clear > > violation of the Code of Conduct and/or mailing list rules (e.g., > > harassment), simply uttering something that some people do not like does > > not form cause for removing someone, or even for issuing any sort of > > warning. Else, why bother having a Code of Conduct and mailing list > > rules? > > Let me propose an alternate way of thinking about this, which I think is a > bit more accurate description of what happens in practice. > > 1. Someone has something they feel passionately about but which is not >very related to the work of Debian. One can argue some connection (we >are people living in the world -- there will always be some >connection), but it's not obviously directly relevant to our work. >They start using project resources (mailing lists, etc.) to talk about >this topic. > > 2. Those discussions upset other people in the project. Often this is >because they directly disagree, sometimes it's just because they don't >want to talk about that topic here. The former is usually what creates >the initial reaction, of course, and the latter is more of a fallback >position among the vocal people, but I suspect is a more common initial >position among the quieter people who just want to do Debian work. > > 3. We reach some sort of rough consensus as a community that this >discussion is disruptive and we don't want to have it here. This is >the critical point: for many previous controversial discussions, we >*didn't* reach this consensus for one reason or another. Perhaps >there's ongoing disagreement over whether this topic is directly >relevant to Debian or not. But sometimes we reach a pretty >overwhelming consensus (by this I mean nearly everyone speaking up is >arguing in that direction) that regardless of the merits of the >argument we don't want to talk about it on project resources. > > 4. The person who feels passionately about this thinks that consensus is >wrong and keeps talking about it anyway. > > 5. Eventually DAM gets involved, judges the consensus about declaring this >off-topic, and asks the person to stop. > > 6. The person refuses to stop because this topic is of overwhelming >importance to them and for some reason they feel like they have to >discuss it in Debian. > > 7. Eventually, DAM takes action to force them to stop. At this point, I >would argue that it doesn't make sense for them to continue as members >of the project because they're pretty clearly unwilling to respect a >boundary the project is trying to draw (step 3). That's a fairly >irreconcilable difference and it's better for everyone to go their >separate ways. > > I think this is a pretty typical process for just about any community > space where people interact. I've seen versions of this play out in just > about every community I've been involved in. Usually things stop at step > 2 because discussing something when other people are upset at the > discussion isn't very fun and usually people don't like to keep doing it. > Very often the process stops at step 3 because no sufficiently strong > consensus emerges. Hopefully the rest of the time the process stops at > step 5. Very rarely it runs through the whole list. > > If this is a reasonably accurate model, I think it makes it somewhat > obvious that you can't have a list of banned topics written down in > advance because steps 2 and 3 are really important (and step 3 can change > over time!). The point isn't that there is a specific set of off-topic > topics. The point is that if you talk about something that makes other > community members actively upset (step 2) *and* they can build a project > consensus that we want to shut down this specific topic here (step 3), > then the rest of the process potentially comes into play. > > Nearly all controversial topics in Debian do not get past step 3. We have > endless recurring topics that run up to step 3 every year or so, and never > progress any farther. > > At least in my opinion, having watched this specific incident from the > start, we passed point 3 fairly clearly with a rather remarkable consensus > by Debian standards (not unanimity, but a pretty strong consensus). I > realize other
Re: cv25519 key support on devotee
On Thu, Sep 29, 2022 at 03:09:30AM +0800, Shengjing Zhu wrote:
> On Thu, Sep 29, 2022 at 2:50 AM Kurt Roeckx wrote:
> >
> > On Wed, Sep 28, 2022 at 07:22:38AM +0200, Kurt Roeckx wrote:
> > >
> > > As far as I understand of what is going wrong is that gnupg tries to
> > > write to the status fd, but libgnupg-interface-perl is trying to read
> > > gnupg's stdout and they just deadlock.
> >
> > So I applied this patch and things seem to work now:
>
> And I can confirm I 've received the ack now.
Yes, me too.
> Thanks!
Same.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Re: cv25519 key support on devotee
On Mon, Sep 26, 2022 at 12:51:48AM +0800, Shengjing Zhu wrote:
> Hi,
>
> Is there any plan to support cv25519 key on devotee?
>
> Or could devotee send unencrypted ack to the voter? I really don't
> mind the vote secrecy... But I want to see my vote hash.
Yes, same here. I'm willing to put in some work if it helps, btw; now that I'm
using a P-384 gpg key, I'm somewhat motivated to at least look at the problem
:-)
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Re: Possible draft non-free firmware option with SC change
On Thu, Sep 15, 2022 at 09:54:01PM +0200, Bill Allombert wrote:
> On Thu, Sep 15, 2022 at 03:14:05PM +0200, Wouter Verhelst wrote:
> > IME, often, lawyers go "this probably won't do anything, but it can't
> > harm us, so meh, let's try and see what we can get from a judge if it
> > ever comes to it".
> >
> > Or even "I've seen this in other licenses, can't hurt, let's copy".
> >
> > If a requirement like that gets thrown out in court, they haven't lost
> > anything, but if it *doesn't* get thrown out, they have gained an
> > advantage.
>
> Indeed, but Debian should not promote this.
I never said anything of the sorts, but you suggested that Intel lawyers
"know exactly what advantage they can get" from doing something like
this. I don't think that's actually true, which is why I sent the above.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Re: Possible draft non-free firmware option with SC change
On Wed, Sep 14, 2022 at 09:13:50AM +, Bill Allombert wrote:
> Le Tue, Sep 13, 2022 at 10:17:16PM +0200, Tobias Frost a écrit :
> > On Tue, Sep 13, 2022 at 07:10:24PM +, Bill Allombert wrote:
> > > Le Tue, Sep 13, 2022 at 02:37:49PM +, Bill Allombert a écrit :
> > > > Le Tue, Sep 13, 2022 at 11:56:07AM +0500, Andrey Rahmatullin a écrit :
> > > > > Do you too agree with the position that having non-free firmware
> > > > > stored in
> > > > > your hardware is better than having it loaded from your OS?
> > > >
> > > > My position is that the laws governing embedded firmware are much
> > > > more favorable to the users than the laws governing freestanding
> > > > firmware.
> > >
> > > To gives a random example: firmware-iwlwifi
> > > (by the way the link in packages.d.o to the copyright file does not work
> > > https://metadata.ftp-master.debian.org/changelogs//non-free/f/firmware-nonfree/firmware-nonfree_20210315-3_copyright
> > > return 404
> > > )
> > >
> > > * No reverse engineering, decompilation, or disassembly of this software
> > > is permitted.
> > > FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED
> > >
> > > You cannot disclaim warranty on hardware. You have to provide statutory
> > > warranty.
> >
> > You can't disclaim statutory warranty, regardless if its hardware or
> > software.
> >
> > However, you can write a lot of sentences in your licenses, even some
> > sentences
> > which are legally ineffective…
> >
> > Disclaimer: IANAL. This is not legal advice, but my oppinion.
>
> I am not a lawyer either, but Intel _does_ have lawyers that drafted
> this that way, and they know exactly what advantage they can get from
> it.
IME, often, lawyers go "this probably won't do anything, but it can't
harm us, so meh, let's try and see what we can get from a judge if it
ever comes to it".
Or even "I've seen this in other licenses, can't hurt, let's copy".
If a requirement like that gets thrown out in court, they haven't lost
anything, but if it *doesn't* get thrown out, they have gained an
advantage.
Lawyers are "cover all your bases" kind of people.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Re: Changing how we handle non-free firmware
On Mon, Aug 22, 2022 at 12:32:54PM -0500, Gunnar Wolf wrote:
> I hereby propose the following alternative text to Steve's original
> proposal.
>
> I'm only suggesting to modify the third paragraph, offering to produce
> two sets of images (fully-free and with-non-free-firmware), being the
> later more prominent.
>
> =
>
> We will include non-free firmware packages from the
> "non-free-firmware" section of the Debian archive on our official
> media (installer images and live images). The included firmware
> binaries will *normally* be enabled by default where the system
> determines that they are required, but where possible we will include
> ways for users to disable this at boot (boot menu option, kernel
> command line etc.).
>
> When the installer/live system is running we will provide information
> to the user about what firmware has been loaded (both free and
> non-free), and we will also store that information on the target
> system such that users will be able to find it later. The target
> system will *also* be configured to use the non-free-firmware
> component by default in the apt sources.list file. Our users should
> receive security updates and important fixes to firmware binaries just
> like any other installed software.
>
> While we will publish these images as official Debian media, they will
> *not* replace the current media sets that do not include non-free
> firmware packages, but offered alongside. Images that do include
> non-free firmware will be presented more prominently, so that
> newcomers will find them more easily; fully-free images will not be
I would state here instead
"Images that do include non-free firmware *may* be presented more
prominently, at the relevant teams' discretion".
(or something along those lines)
Rationale: we don't want to bind ourselves to an action that we're
taking because the situation is *currently* problematic. While unlikely,
it is certainly possible (given enough pressure) that at some undefined
point in the future the *majority* of firmware packages will no longer
be in the non-free section. At that point, we may want to decide to give
the image without non-free firmware priority again.
> hidden away; they will be linked from the same project pages, but with
> less visual priority.
Other than that, I would second this if I had a functional GPG key ;-)
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Re: Changing how we handle non-free firmware
On Fri, Aug 26, 2022 at 03:01:41PM +0200, Simon Richter wrote:
> Hi,
>
> On 8/23/22 22:22, Bart Martens wrote:
>
> > > Debian would recommend the one with non-free-firmware, for the
> > > purposes of enabling users to install on current hardware, but both
> > > would be available.
>
> > Do we need to recommend one above the other? I'd rather use some short
> > explanation per installer to help the user choose.
>
> This. Both installers have trade-offs:
>
> Free installer:
>
> - will not work with some hardware
> + fully supported
> + can be redistributed freely
>
> Installer including firmware:
>
> + supports more hardware
> - some bugs might be unfixable
> - users need to be aware of non-free licenses
>
> The third point is something we can and should address in the medium term:
> so far, license checks for non-free components have been mostly "can Debian
> redistribute this" and "can users install this".
The suggestion is for there to be a new section, "non-free-firmware".
The requirements on this new section need not be the same as those on
non-free.
Thus, your concern can easily be handled by requiring maintainers and/or
ftpmasters to vet licenses of packages before they are moved to
non-free-firmware.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Re: Changing how we handle non-free firmware
On Fri, Aug 19, 2022 at 11:26:51AM +0100, Steve McIntyre wrote:
> Hey Wouter!
>
> On Fri, Aug 19, 2022 at 12:19:55PM +0200, Wouter Verhelst wrote:
> >On Thu, Aug 18, 2022 at 08:58:21PM +0100, Steve McIntyre wrote:
> >> system will *also* be configured to use the non-free-firmware
> >> component by default in the apt sources.list file.
> >
> >What's the rationale for this one?
> >
> >I think it would make more sense to only configure the system to enable
> >the non-free-firmware component if the installer determines that
> >packages from that component are useful for the running system (or if
> >the user explicitly asked to do so).
>
> That's a fair point, my text was unclear here. Let's tweak it:
>
> "Where non-free firmware is found to be necessary, the target system
> will *also* be configured to use the non-free-firmware component by
> default in the apt sources.list file."
>
> Does that sound better?
Much!
With that tweak, I would second it, except that I am out of a GPG key
currently.
> >If I'm not mistaken, code to do this already exists, and seems to work
> >well (but do correct me if I'm wrong).
>
> Ish! :-)
>
> We don't have any code in d-i to deal with the *non-free-firmware*
> component yet, but I#m sure we can adapt the existing stuff around
> non-free / contrib to suit.
Well, yes, that's what I meant.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Re: Changing how we handle non-free firmware
On Thu, Aug 18, 2022 at 08:58:21PM +0100, Steve McIntyre wrote:
> system will *also* be configured to use the non-free-firmware
> component by default in the apt sources.list file.
What's the rationale for this one?
I think it would make more sense to only configure the system to enable
the non-free-firmware component if the installer determines that
packages from that component are useful for the running system (or if
the user explicitly asked to do so).
If I'm not mistaken, code to do this already exists, and seems to work
well (but do correct me if I'm wrong).
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
Re: Questions about Debian derivatives
On Mon, Mar 28, 2022 at 10:27:48AM +0800, Paul Wise wrote:
[...]
> > Not sure if you're familiar with extrepo?
>
> As I understand it, extrepo is more for things like the Mozilla Firefox
> or PostgreSQL repositories than things like Ubuntu? Probably a
> discussion for the extrepo maintainer, or potentially there is room for
> an extrepo extension containing apt configs/keys for derivatives,
> perhaps pulled from the census. As an example of where this would be
> useful, I'm pulling the Ubuntu census apt config into a chdist so I can
> list Ubuntu package versions etc on the command-line.
The URL format of the extrepo metadata currently contains "/debian/" in
it, precisely because I foresaw the possibility to also include
repositories for (or of) our derivatives, and then you might not
necessarily want to mix that with Debian *all* the time.
The current extrepo client does not have the ability to select a
different distribution, mostly because it hasn't come up yet and there
are other things that are important currently; but if there is a need
and/or interest from derivatives, I'm definitely open to adding the
metadata to extrepo and extending the client with functionality that
would be useful.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Re: To all candidates: Debian and people with disabilities
Hi Samuel,
On Tue, Mar 22, 2022 at 09:23:38AM +0100, Samuel Thibault wrote:
> Hello,
>
> Devin Prater, le lun. 21 mars 2022 22:10:15 -0500, a ecrit:
> > As far as backports, my problem is enabling it. Normal desktop users
> > probably
> > won't even know what that is, and the syntax is rather ugly, to me at least.
>
> Ok, that's one point that could be worked on: creating an easy way to
> enable backports.
This is what my project, "extrepo", wants to accomplish: to make it
easily possible to enable repositories that are not enabled by default.
You can enable backports on bullseye by way of the following two
commands:
sudo apt install extrepo
sudo extrepo enable debian_backports
(there are a lot of other repositories you can enable that way, btw; to
get a full list, run "extrepo search", although you might want to pipe
it into a pager ;-) )
> At least as a question in the installer,
Adding an installer module for extrepo is on my TODO list, but I do have
a lot on my plate and thus am not sure I'll be able to finish that work
in time for the release.
[...]
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Re: General Resolution: Change the resolution process: results
On Mon, Jan 31, 2022 at 11:44:16AM -0800, Russ Allbery wrote:
> Marc Haber writes:
>
> > The one we just had was tl;dr to me. The people pushing it gave me zero
> > motivation to read it, I spent my spare time on my packages.
While I can't speak for Russ, I did try to summarize in "normal"
language what I was trying to accomplish with my proposal in its
rationale.
I don't know if that was clear enough (I guess it wasn't, given your
message here), but hey, I tried.
>
> As the person proposing this GR, I think that's a perfectly reasonable
> stance to take, and to be quite honest one of my goals was to *not* give
> people a (negative) motivation to feel like they have to be involved.
+1.
Some votes have a big impact on what we do in Debian, and they matter.
This one? Not so much. It was mostly a bug fix, and while I had some
strong disagreements with Russ on one particular bit of his proposal,
when all is said and done it's just a method, and we can reverse it
again if we decide it doesn't work.
If you decide that the political side of Debian is irrelevant, then you
should feel free to ignore all that and focus on your packages. I don't
think that's wrong! The technical side of the project is probably the
most important one, and while you should of course not complain if the
politics aren't going your way if you decide not to partake in them, I
don't think you should be in any way required to be part of it, or be
ashamed if you think it's not for you.
Our voting system is just a slightly more formal way of essentially the
same thing as asking people to raise their hands during a keynote talk
at debconf, after all.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Re: General Resolution: Change the resolution process: results
On Sun, Jan 30, 2022 at 11:41:51PM +0100, Kurt Roeckx wrote:
> On Sun, Jan 30, 2022 at 11:23:35PM +0200, Wouter Verhelst wrote:
> > As of this writing, the tally sheet is still the dummy tally sheet, and it
> > has not been replaced with the real one.
>
> I don't see a problem. This looks like the real tally sheet:
> https://www.debian.org/vote/2021/vote_003_tally.txt
>
> There is a dummy tally sheet at:
> https://vote.debian.org/~secretary/gr_resolution_process/tally.txt
>
> I'm not sure the real one ever got published there.
In that case, the problem is that the links to the tally sheet still
point to the dummy sheet; if you go to the vote's page, then click on
the "statistics" link, and next on the "tally sheet" one, you get the
dummy tally sheet.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Re: General Resolution: Change the resolution process: results
As of this writing, the tally sheet is still the dummy tally sheet, and it has not been replaced with the real one. What's happening? -- Verstuurd vanaf mijn Android apparaat met K-9 Mail. Excuseer mijn beknoptheid.
Re: GR: Change the resolution process (corrected)
... let's try that with cryptography this time around. On Thu, Dec 02, 2021 at 11:58:21PM +0200, Wouter Verhelst wrote: > On Thu, Dec 02, 2021 at 01:46:51PM -0700, Sam Hartman wrote: > > >>>>> "Wouter" == Wouter Verhelst writes: > > > > Wouter> Hi Kurt, > > Wouter> On Thu, Dec 02, 2021 at 06:45:24PM +0100, Kurt Roeckx wrote: > > Wouter> It was always my intent that the discussion time can be kept > > Wouter> alive as long as it has not yet expired, but that it cannot > > Wouter> be revived once it has expired. But I now think it does not > > Wouter> forbid someone from sponsoring an extension proposal when > > Wouter> the discussion time has already expired. > > > > Wouter> So I think I should add the following to my A.3: > > > > Wouter> 6. Once the discussion time expires, any pending time > > Wouter> extension proposals that have not yet received their > > Wouter> required number of sponsors are null and void, and no > > Wouter> further time extensions may be proposed. > > > > Wouter> Or is that superfluous? > > > > Please say one way or the other so we don't fight about it later:-) > > Heh :) > > I first wanted to know whether other people think my reading makes > sense, or if I'm just overthinking it... > > > Thanks for noticing this. > > I'll take it you think I'm not overthinking things then. > > > So, out of morbid curiosity about the current formal process. If you > > propose this change, can Russ accept it for you, or could he only do > > that if he accepts your entire proposal as an amendment? > > I could bypass the whole thing and claim a minor change. That's probably > cheating, but then again, it is what I had always intended, so from that > POV I guess it isn't. > > So unless someone objects, the below is now the proposal: > > Rationale > = > > Much of the rationale of Russ' proposal still applies, and indeed this > amendment builds on it. However, the way the timing works is different, > on purpose. > > Our voting system, which neither proposal modifies, as a condorcet > voting mechanism, does not suffer directly from too many options on the > ballot. While it is desirable to make sure the number of options on the > ballot is not extremely high for reasons of practicality and voter > fatigue, it is nonetheless of crucial importance that all the *relevant* > options are represented on the ballot, so that the vote outcome is not > questioned for the mere fact that a particular option was not > represented on the ballot. Making this possible requires that there is > sufficient time to discuss all relevant opinions. > > Russ' proposal introduces a hard limit of 3 weeks to any and all ballot > processes, assuming that that will almost always be enough, and relying > on withdrawing and restarting the voting process in extreme cases where > it turns out more time is needed; in Russ' proposal, doing so would > increase the discussion time by another two weeks at least (or one if > the DPL reduces the discussion time). > > In controversial votes, I believe it is least likely for all ballot > proposers to be willing to use this escape hatch of withdrawing the vote > and restarting the process; and at the same time, controversial votes > are the most likely to need a lot of discussion to build a correct > ballot, which implies they would be most likely to need some extra time > -- though not necessarily two more weeks -- for the ballot to be > complete. > > At the same time, I am not insensitive to arguments of predictability, > diminishing returns, and process abuse which seem to be the main > arguments in favour of a hard time limit at three weeks. > > For this reason, my proposal does not introduce a hard limit, and > *always* makes it theoretically possible to increase the discussion > time, but does so in a way that extending the discussion time becomes > harder and harder as time goes on. I believe it is better for the > constitution to allow a group of people to have a short amount of extra > time so they can finish their proposed ballot option, than to require > the full discussion period to be restarted through the withdrawal and > restart escape hatch. At the same time, this escape hatch is not > removed, although I expect it to be less likely to be used. > > The proposed mechanism sets the initial discussion time to 1 week, but > allows it to be extended reasonably easily to 2 or 3 weeks, makes it > somewhat harder to reach 4 weeks, and makes it highly unlikely (but > still possible) to go beyond that. &g
Re: GR: Change the resolution process (corrected)
On Thu, Dec 02, 2021 at 01:46:51PM -0700, Sam Hartman wrote: > >>>>> "Wouter" == Wouter Verhelst writes: > > Wouter> Hi Kurt, > Wouter> On Thu, Dec 02, 2021 at 06:45:24PM +0100, Kurt Roeckx wrote: > Wouter> It was always my intent that the discussion time can be kept > Wouter> alive as long as it has not yet expired, but that it cannot > Wouter> be revived once it has expired. But I now think it does not > Wouter> forbid someone from sponsoring an extension proposal when > Wouter> the discussion time has already expired. > > Wouter> So I think I should add the following to my A.3: > > Wouter> 6. Once the discussion time expires, any pending time > Wouter> extension proposals that have not yet received their > Wouter> required number of sponsors are null and void, and no > Wouter> further time extensions may be proposed. > > Wouter> Or is that superfluous? > > Please say one way or the other so we don't fight about it later:-) Heh :) I first wanted to know whether other people think my reading makes sense, or if I'm just overthinking it... > Thanks for noticing this. I'll take it you think I'm not overthinking things then. > So, out of morbid curiosity about the current formal process. If you > propose this change, can Russ accept it for you, or could he only do > that if he accepts your entire proposal as an amendment? I could bypass the whole thing and claim a minor change. That's probably cheating, but then again, it is what I had always intended, so from that POV I guess it isn't. So unless someone objects, the below is now the proposal: Rationale = Much of the rationale of Russ' proposal still applies, and indeed this amendment builds on it. However, the way the timing works is different, on purpose. Our voting system, which neither proposal modifies, as a condorcet voting mechanism, does not suffer directly from too many options on the ballot. While it is desirable to make sure the number of options on the ballot is not extremely high for reasons of practicality and voter fatigue, it is nonetheless of crucial importance that all the *relevant* options are represented on the ballot, so that the vote outcome is not questioned for the mere fact that a particular option was not represented on the ballot. Making this possible requires that there is sufficient time to discuss all relevant opinions. Russ' proposal introduces a hard limit of 3 weeks to any and all ballot processes, assuming that that will almost always be enough, and relying on withdrawing and restarting the voting process in extreme cases where it turns out more time is needed; in Russ' proposal, doing so would increase the discussion time by another two weeks at least (or one if the DPL reduces the discussion time). In controversial votes, I believe it is least likely for all ballot proposers to be willing to use this escape hatch of withdrawing the vote and restarting the process; and at the same time, controversial votes are the most likely to need a lot of discussion to build a correct ballot, which implies they would be most likely to need some extra time -- though not necessarily two more weeks -- for the ballot to be complete. At the same time, I am not insensitive to arguments of predictability, diminishing returns, and process abuse which seem to be the main arguments in favour of a hard time limit at three weeks. For this reason, my proposal does not introduce a hard limit, and *always* makes it theoretically possible to increase the discussion time, but does so in a way that extending the discussion time becomes harder and harder as time goes on. I believe it is better for the constitution to allow a group of people to have a short amount of extra time so they can finish their proposed ballot option, than to require the full discussion period to be restarted through the withdrawal and restart escape hatch. At the same time, this escape hatch is not removed, although I expect it to be less likely to be used. The proposed mechanism sets the initial discussion time to 1 week, but allows it to be extended reasonably easily to 2 or 3 weeks, makes it somewhat harder to reach 4 weeks, and makes it highly unlikely (but still possible) to go beyond that. Text of the GR == The Debian Developers, by way of General Resolution, amend the Debian constitution under point 4.1.2 as follows. This General Resolution requires a 3:1 majority. Sections 4 through 7 Copy from Russ' proposal, replacing cross-references to §A.5 by §A.6, where relevant. Section A - Replace section A as per Russ' proposal, with the following changes: A.1.1. Replace the sentence "The minimum discussion period is 2 weeks." by "The initial discussion period is 1 week." Strike the sentence
Re: GR: Change the resolution process (corrected)
Hi Kurt,
On Thu, Dec 02, 2021 at 06:45:24PM +0100, Kurt Roeckx wrote:
> On Thu, Dec 02, 2021 at 03:50:22PM +0200, Wouter Verhelst wrote:
> > Ping?
>
> I've pushed this to the website on Tuesday. I forgot to mail
> that I've done so.
Ah, yes; indeed. I missed that, obviously.
Looking it over one more time, I noticed a defect.
It was always my intent that the discussion time can be kept alive as
long as it has not yet expired, but that it cannot be revived once it
has expired. But I now think it does not forbid someone from sponsoring
an extension proposal when the discussion time has already expired.
So I think I should add the following to my A.3:
6. Once the discussion time expires, any pending time extension
proposals that have not yet received their required number of
sponsors are null and void, and no further time extensions may be
proposed.
Or is that superfluous?
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Re: GR: Change the resolution process (corrected)
On Mon, Nov 29, 2021 at 06:52:59PM +0100, Kurt Roeckx wrote:
> On Mon, Nov 29, 2021 at 09:31:42AM -0800, Russ Allbery wrote:
> > Wouter Verhelst writes:
> >
> > > aaand this should've been signed. Good morning.
> >
> > > On Tue, Nov 23, 2021 at 09:50:14AM +0200, Wouter Verhelst wrote:
> >
> > >> All this changes my proposal to the below. I would appreciate if my
> > >> seconders would re-affirm that they agree with the changes I propose,
> > >> and apologies for the mess.
> >
> > I think this is at or near the required number of sponsors
>
> I think that's the case too, but didn't have time to properly verify it.
> That will probably be something for tomorrow.
Ping?
According to my count, we're now at six sponsors: Holger,
Pierre-Elliott, Mathias, Kyle, Mattia, Louis-Philippe. That's one over,
isn't it?
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Re: GR: Change the resolution process (corrected)
Hi Kurt,
On Tue, Nov 30, 2021 at 11:54:57PM +0100, Kurt Roeckx wrote:
> On Tue, Nov 23, 2021 at 09:53:50AM +0200, Wouter Verhelst wrote:
> > > Text of the GR
> > > ==
> > >
> > > The Debian Developers, by way of General Resolution, amend the Debian
> > > constitution under point 4.1.2 as follows. This General Resolution
> > > requires a 3:1 majority.
> > >
> > > Sections 4 through 7
> > >
> > >
> > > Copy from Russ' proposal, replacing cross-references to §A.5 by §A.6,
> > > where relevant.
>
> Since this is based on Russ' proposal, and that has been changed, I
> would like you to confirm that it's based on it's current proposal
> and not the original one.
Confirmed. I substantially agree with most of Russ' proposal (and even
contributed to it before the public discussion on this list), just not the
timing.
If Russ changes something that I disagree with, I'll change my proposal
to revert that change, but I don't foresee this happening.
Thanks for checking.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
signature.asc
Description: PGP signature
Re: Possible third ballot option -- middle ground between choices (1) and (2)
Hi Sean,
On Mon, Nov 29, 2021 at 12:09:41PM -0700, Sean Whitton wrote:
> Dear all,
>
> I am interested in this informal proposal from Russ, which has not
> received much explicit feedback:
>
> On Sun 07 Nov 2021 at 03:53PM -08, Russ Allbery wrote:
>
> > I wonder if you could make the system even simpler, producing a scheme
> > that has some admirable simplicity advantages over my proposal.
> > Something like this:
> >
> > 1. The discussion period starts when a draft resolution is proposed and
> >sponsored. The length of the discussion period starts at 1 week.
> >
> > 2. An extension to the discusison period may be proposed and sponsored
> >according to the requirements for a new resolution. As soon as a
> >discussion period extension reaches the required number of sponsors, it
> >takes effect and cannot be withdrawn.
> >
> > 3. The first two times the discussion period is extended add an additional
> >week to the length of the discussion period. Subsequent extensions add
> >an additional 72 hours.
> >
> > 4. The proposer and sponsors of an extension to the discussion period may
> >not propose or sponsor any additional extensions to the discussion
> >period for the same General Resolution.
> >
> > 5. The discussion period may not be extended beyond six weeks.
> >
> > and then drop not only the language about extending the discussion period
> > when the ballot changes but also all the language for the DPL varying the
> > length of the discussion period, and use this system as the only mechanism
> > for changing the length of the discussion period.
>
> I have been studying Wouter's formal proposal and believe that the only
> substantive difference with the quoted text is that where the quoted
> text has a hard limit on the discussion period, Wouter's proposal
> instead has a mechanism for objecting to further extensions.
>
> Would someone else be able to confirm this reading, please?
Yes, that's pretty much correct; my current proposal was created after I
discarded Russ' informal proposal that you point to here as "not good
enough for me", and then I added the objection mechanism to cope with
that.
> If I'm right, I am considering proposing a third choice which is
> identical to Wouter's, except it would drop the mechanism for objecting
> to extensions beyond four weeks and reimpose a maximum discussion
> period, which I am thinking of setting to four weeks.
You may of course do so, but I think it creates a system that
incorporates the worst of both worlds. My proposed system allows one to
extend the time at all time (while making it progressively harder as
time goes on), because I believe it is better to have a system that
allows that flexibility when necessary than to have a system with a
rigid, unchangeable limit.
If you *do* prefer that limit, then I think it makes more sense to have
a system like Russ's, where time is extended when a ballot option is
added, but not past your time limit. His system is procedurally much
simpler than mine, but has the downside that it creates what I think is
an unacceptable hard limit. If you believe three weeks is too short,
might it not be better to propose a system like Russ's, but with the
hard limit at four weeks rather than three?
I don't really like the procedural complexity that my system creates,
but I think that disadvantage outweighs the disadvantage that the rigid
limit in Russ's proposal creates.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Re: Possible fourth ballot option
On Mon, Nov 29, 2021 at 08:55:19PM +0100, Lucas Nussbaum wrote:
> Hi,
>
> First,
>
> > Many thanks to Russ and Wouter for all their work on this.
>
> +1
>
>
> If I understand correctly, most agree that we would like to keep
> the discussion period short in most cases. But at the same time, in
> exceptional circumstances, some would like a way to extend it.
>
> Instead of the quite complex procedure proposed by Wouter, couldn't we
> patch the DPL's power to increase or decrease the the discussion period
> to allow the DPL to extend it beyond three weeks?
The downside of doing that is that if the DPL does this, then it is a
fairly political action, with all downsides of that method: if there is
a group of developers who would like the time to be extended and a group
who doesn't, then the DPL will be caught between a rock and a hard
place, and will be yelled at by one group or the other, regardless of
which decision they take.
The proposed system makes it less problematic in that respect: the DPL
still has the ability to extend the discussion time by themselves once,
but really the responsibility of extending the discussion time is now in
the hands of the people who are actually discussing things.
[...]
> I think that it is reasonable to assume that the DPL will make such
> decisions based on what is best for the project. If the DPL abuses this,
> there's still the possibility to override the decision.
But then you now have two votes, which feels superfluous.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Re: GR: Change the resolution process (corrected)
On Tue, Nov 23, 2021 at 09:00:07AM -0800, Russ Allbery wrote: > Wouter Verhelst writes: > > > Since both Russ and myself seem to be having issues here, in order to > > better understand the proposed changes, I have made > > https://salsa.debian.org/wouter/webwml/-/blob/constitution-russ/english/devel/constitution.wml > > (which is a version of the constitution with the changes as proposed by > > Russ) and > > https://salsa.debian.org/wouter/webwml/-/blob/constitution-wouter/english/devel/constitution.wml > > (with the required changes as per my proposal). While doing so, I > > realized there were a few cross-references still that I needed to update > > as well. > > Thank you so much! This saved me tons of time. Well, it only took about an hour or so, so I wouldn't say "tons", but yeah :-) > > Russ, please review the patch I wrote, so as to make sure I haven't made > > any mistakes in your proposal. > > I confirm that you accurately reflected the changes from my proposal Cool. > except that your version (quite reasonably) doesn't include the minor > change to add "is" in A.2.3. > > I did a bit of reformatting with an eye to such a diff eventually being > merged that makes the HTML style match what appeared to be the prevailing > style in the rest of the document and will use that version to generate an > "official" diff of my proposal. Not sure whether you want to rebase on > that version or not; I can push it up to Salsa in my own repo, or give you > a PR against your repo, or whatever else is convenient. > > I'm happy to help with that rebasing if you'd like and give you a PR for > your branch as well. It's the least that I can do after you did all the > work of recasting my proposal in webwml. Any and all MRs that reflect what's been discussed/decided on this list are definitely welcome. > > Rationale > > = > > I just wanted to say how much I appreciated the collaborative and > collegial tone of this rationale even though by necessity you're laying > out how you disagree with my proposal. It's really excellent. And in > general I've been very happy with how constructive and positive this whole > discussion has been. Likewise. I wish I could say "but of course, that's how things are done", except that things do tend to get a bit emotional on this list sometimes. > > Section A > > - > > > Replace section A as per Russ' proposal, with the following changes: > > > A.1.1. Replace the sentence "The minimum discussion period is 2 weeks." > >by "The initial discussion period is 1 week." Strike the sentence > >"The maximum discussion period is 3 weeks". > > > A.1.4. Strike in its entirety > > > A.1.5. Rename to A.1.4. > > I think you also want to remove: > > In this case the length of the discussion period is not changed. > > from this section because that's only there because of the provision in > A.1.4 that you are removing. You can probably do this as a minor change > since it doesn't affect the meaning. Yes, thanks; good catch. > > After A.2, insert: > > > A.3. Extending the discussion time. > > > 1. When less than 48 hours remain in the discussion time, any Developer > >may propose an extension to the discussion time, subject to the > >limitations of §A.3.3. These extensions may be seconded according to > >the same rules that apply to new ballot options. > > Minor point: We routinely in casual discussion use the term "seconded," > but the constitution uniformly uses "sponsor" and the word "seconded" > doesn't appear anywhere in the constitution. I adjusted my change while I > was drafting it to stick with that language and you may want to make the > same change here. > > Same note for points 2 and 3. Yes, indeed; changed as such. I've made those two changes as a minor change below. > > 2. As soon as a time extension has received the required number of > >seconds, these seconds are locked in and cannot be withdrawn, and the > >time extension is active. > > > 3. When a time extension has received the required number of seconds, > >its proposers and seconders may no longer propose or second any > >further time extension for the same ballot, and any further seconds > >for the same extension proposal will be ignored for the purpose of > >this paragraph. In case of doubt, the Project Secretary decides how > >the order of seconds is determined. > > "this paragraph" sounds like it may only be applying to point 3, and I > th
Re: GR: Change the resolution process (corrected)
aaand this should've been signed. Good morning. On Tue, Nov 23, 2021 at 09:50:14AM +0200, Wouter Verhelst wrote: > ... and then I realize I *also* made a (small, but crucial) mistake: > > On Mon, Nov 22, 2021 at 05:15:34PM +0200, Wouter Verhelst wrote: > [...] > > Section A > > - > > > > Replace section A as per Russ' proposal, with the following changes: > > > > A.1.1. Strike the sentence "The maximum discussion period is 3 weeks". > > This should additionally say, > > Replace the sentence "The minimum discussion period is 2 weeks." by > "The initial discussion period is 1 week." > > as my proposal does not allow the DPL to reduce the discussion time, and > instead reduces the discussion time always, relying on the time > extension procedure to lengthen it, if required (which the DPL can use > without seconds, once). > > Since both Russ and myself seem to be having issues here, in order to > better understand the proposed changes, I have made > https://salsa.debian.org/wouter/webwml/-/blob/constitution-russ/english/devel/constitution.wml > (which is a version of the constitution with the changes as proposed by > Russ) and > https://salsa.debian.org/wouter/webwml/-/blob/constitution-wouter/english/devel/constitution.wml > (with the required changes as per my proposal). While doing so, I > realized there were a few cross-references still that I needed to update > as well. > > Russ, please review the patch I wrote, so as to make sure I haven't made > any mistakes in your proposal. > > All this changes my proposal to the below. I would appreciate if my > seconders would re-affirm that they agree with the changes I propose, > and apologies for the mess. > > Rationale > = > > Much of the rationale of Russ' proposal still applies, and indeed this > amendment builds on it. However, the way the timing works is different, > on purpose. > > Our voting system, which neither proposal modifies, as a condorcet > voting mechanism, does not suffer directly from too many options on the > ballot. While it is desirable to make sure the number of options on the > ballot is not extremely high for reasons of practicality and voter > fatigue, it is nonetheless of crucial importance that all the *relevant* > options are represented on the ballot, so that the vote outcome is not > questioned for the mere fact that a particular option was not > represented on the ballot. Making this possible requires that there is > sufficient time to discuss all relevant opinions. > > Russ' proposal introduces a hard limit of 3 weeks to any and all ballot > processes, assuming that that will almost always be enough, and relying > on withdrawing and restarting the voting process in extreme cases where > it turns out more time is needed; in Russ' proposal, doing so would > increase the discussion time by another two weeks at least (or one if > the DPL reduces the discussion time). > > In controversial votes, I believe it is least likely for all ballot > proposers to be willing to use this escape hatch of withdrawing the vote > and restarting the process; and at the same time, controversial votes > are the most likely to need a lot of discussion to build a correct > ballot, which implies they would be most likely to need some extra time > -- though not necessarily two more weeks -- for the ballot to be > complete. > > At the same time, I am not insensitive to arguments of predictability, > diminishing returns, and process abuse which seem to be the main > arguments in favour of a hard time limit at three weeks. > > For this reason, my proposal does not introduce a hard limit, and > *always* makes it theoretically possible to increase the discussion > time, but does so in a way that extending the discussion time becomes > harder and harder as time goes on. I believe it is better for the > constitution to allow a group of people to have a short amount of extra > time so they can finish their proposed ballot option, than to require > the full discussion period to be restarted through the withdrawal and > restart escape hatch. At the same time, this escape hatch is not > removed, although I expect it to be less likely to be used. > > The proposed mechanism sets the initial discussion time to 1 week, but > allows it to be extended reasonably easily to 2 or 3 weeks, makes it > somewhat harder to reach 4 weeks, and makes it highly unlikely (but > still possible) to go beyond that. > > Text of the GR > == > > The Debian Developers, by way of General Resolution, amend the Debian > constitution under point 4.1.2 as follows. This General Resolution > requires
Re: GR: Change the resolution process (corrected)
... and then I realize I *also* made a (small, but crucial) mistake: On Mon, Nov 22, 2021 at 05:15:34PM +0200, Wouter Verhelst wrote: [...] > Section A > - > > Replace section A as per Russ' proposal, with the following changes: > > A.1.1. Strike the sentence "The maximum discussion period is 3 weeks". This should additionally say, Replace the sentence "The minimum discussion period is 2 weeks." by "The initial discussion period is 1 week." as my proposal does not allow the DPL to reduce the discussion time, and instead reduces the discussion time always, relying on the time extension procedure to lengthen it, if required (which the DPL can use without seconds, once). Since both Russ and myself seem to be having issues here, in order to better understand the proposed changes, I have made https://salsa.debian.org/wouter/webwml/-/blob/constitution-russ/english/devel/constitution.wml (which is a version of the constitution with the changes as proposed by Russ) and https://salsa.debian.org/wouter/webwml/-/blob/constitution-wouter/english/devel/constitution.wml (with the required changes as per my proposal). While doing so, I realized there were a few cross-references still that I needed to update as well. Russ, please review the patch I wrote, so as to make sure I haven't made any mistakes in your proposal. All this changes my proposal to the below. I would appreciate if my seconders would re-affirm that they agree with the changes I propose, and apologies for the mess. Rationale = Much of the rationale of Russ' proposal still applies, and indeed this amendment builds on it. However, the way the timing works is different, on purpose. Our voting system, which neither proposal modifies, as a condorcet voting mechanism, does not suffer directly from too many options on the ballot. While it is desirable to make sure the number of options on the ballot is not extremely high for reasons of practicality and voter fatigue, it is nonetheless of crucial importance that all the *relevant* options are represented on the ballot, so that the vote outcome is not questioned for the mere fact that a particular option was not represented on the ballot. Making this possible requires that there is sufficient time to discuss all relevant opinions. Russ' proposal introduces a hard limit of 3 weeks to any and all ballot processes, assuming that that will almost always be enough, and relying on withdrawing and restarting the voting process in extreme cases where it turns out more time is needed; in Russ' proposal, doing so would increase the discussion time by another two weeks at least (or one if the DPL reduces the discussion time). In controversial votes, I believe it is least likely for all ballot proposers to be willing to use this escape hatch of withdrawing the vote and restarting the process; and at the same time, controversial votes are the most likely to need a lot of discussion to build a correct ballot, which implies they would be most likely to need some extra time -- though not necessarily two more weeks -- for the ballot to be complete. At the same time, I am not insensitive to arguments of predictability, diminishing returns, and process abuse which seem to be the main arguments in favour of a hard time limit at three weeks. For this reason, my proposal does not introduce a hard limit, and *always* makes it theoretically possible to increase the discussion time, but does so in a way that extending the discussion time becomes harder and harder as time goes on. I believe it is better for the constitution to allow a group of people to have a short amount of extra time so they can finish their proposed ballot option, than to require the full discussion period to be restarted through the withdrawal and restart escape hatch. At the same time, this escape hatch is not removed, although I expect it to be less likely to be used. The proposed mechanism sets the initial discussion time to 1 week, but allows it to be extended reasonably easily to 2 or 3 weeks, makes it somewhat harder to reach 4 weeks, and makes it highly unlikely (but still possible) to go beyond that. Text of the GR == The Debian Developers, by way of General Resolution, amend the Debian constitution under point 4.1.2 as follows. This General Resolution requires a 3:1 majority. Sections 4 through 7 Copy from Russ' proposal, replacing cross-references to §A.5 by §A.6, where relevant. Section A - Replace section A as per Russ' proposal, with the following changes: A.1.1. Replace the sentence "The minimum discussion period is 2 weeks." by "The initial discussion period is 1 week." Strike the sentence "The maximum discussion period is 3 weeks". A.1.4. Strike in its entirety A.1.5. Rename to A.1.4. A.1.6. Strike in its entirety A.1.7. Rename to A.1.5. After A.2, insert: A.3. Extending
Re: GR: Change the resolution process (corrected)
I propose the following amendment. I expect Russ to not accept it, and
am looking for seconds.
Rationale
=
Much of the rationale of Russ' proposal still applies, and indeed this
amendment builds on it. However, the way the timing works is different,
on purpose.
Our voting system, which neither proposal modifies, as a condorcet
voting mechanism, does not suffer directly from too many options on the
ballot. While it is desirable to make sure the number of options on the
ballot is not extremely high for reasons of practicality and voter
fatigue, it is nonetheless of crucial importance that all the *relevant*
options are represented on the ballot, so that the vote outcome is not
questioned for the mere fact that a particular option was not
represented on the ballot. Making this possible requires that there is
sufficient time to discuss all relevant opinions.
Russ' proposal introduces a hard limit of 3 weeks to any and all ballot
processes, assuming that that will almost always be enough, and relying
on withdrawing and restarting the voting process in extreme cases where
it turns out more time is needed; in Russ' proposal, doing so would
increase the discussion time by another two weeks at least (or one if
the DPL reduces the discussion time).
In controversial votes, I believe it is least likely for all ballot
proposers to be willing to use this escape hatch of withdrawing the vote
and restarting the process; and at the same time, controversial votes
are the most likely to need a lot of discussion to build a correct
ballot, which implies they would be most likely to need some extra time
-- though not necessarily two more weeks -- for the ballot to be
complete.
At the same time, I am not insensitive to arguments of predictability,
diminishing returns, and process abuse which seem to be the main
arguments in favour of a hard time limit at three weeks.
For this reason, my proposal does not introduce a hard limit, and
*always* makes it theoretically possible to increase the discussion
time, but does so in a way that extending the discussion time becomes
harder and harder as time goes on. I believe it is better for the
constitution to allow a group of people to have a short amount of extra
time so they can finish their proposed ballot option, than to require
the full discussion period to be restarted through the withdrawal and
restart escape hatch. At the same time, this escape hatch is not
removed, although I expect it to be less likely to be used.
The proposed mechanism sets the initial discussion time to 1 week, but
allows it to be extended reasonably easily to 2 or 3 weeks, makes it
somewhat harder to reach 4 weeks, and makes it highly unlikely (but
still possible) to go beyond that.
Text of the GR
==
The Debian Developers, by way of General Resolution, amend the Debian
constitution under point 4.1.2 as follows. This General Resolution
requires a 3:1 majority.
Sections 4 through 7
Same changes as in Russ' proposal
Section A
-
Replace section A as per Russ' proposal, with the following changes:
A.1.1. Strike the sentence "The maximum discussion period is 3 weeks".
A.1.4. Strike in its entirety
A.1.5. Rename to A.1.4.
A.1.6. Strike in its entirety
A.1.7. Rename to A.1.5.
After A.2, insert:
A.3. Extending the discussion time.
1. When less than 48 hours remain in the discussion time, any Developer
may propose an extension to the discussion time, subject to the
limitations of §A.3.3. These extensions may be seconded according to
the same rules that apply to new ballot options.
2. As soon as a time extension has received the required number of
seconds, these seconds are locked in and cannot be withdrawn, and the
time extension is active.
3. When a time extension has received the required number of seconds,
its proposers and seconders may no longer propose or second any
further time extension for the same ballot, and any further seconds
for the same extension proposal will be ignored for the purpose of
this paragraph. In case of doubt, the Project Secretary decides how
the order of seconds is determined.
4. The first two successful time extensions will extend the discussion
time by one week; any further time extensions will extend the
discussion time by 72 hours.
5. Once the discussion time is longer than 4 weeks, any Developer may
object to further time extensions. Developers who have previously
proposed or seconded a time extension may object as well. If the
number of objections outweigh the proposer and their seconders,
including seconders who will be ignored as per §A.3.3, the time
extension will not be active and the discussion time does not change.
A.3. Rename to A.4.
A.4. Rename to A.5.
A.5. Rename (back) to A.6.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
signature.asc
Description: PGP signature
My position, and possible changes to my proposed system
Hi all, I just caught up with all the traffic on this list (and there were a lot of them). Rather than trying to find all the relevant emails and reply to each of them individually, let me just combine all my comments in this mail. First, let me clarify my position: I feel that our voting system works best if all the relevant options are represented on the ballot. This requires that all relevant options have a chance to be developed; if we have a system that has a hard time limit, no matter where it is set, then there is a chance that a relevant option would not appear on the ballot, which I think should be avoided as it can call into question the legitimacy of the ballot: if a controversial option favoured by a vocal minority was not represented on the ballot, the GR is not likely to resolve the issue, because you can be sure that minority will hammer on the missing option in the discussion after the GR. I realize that this is an edge case, but rules such as the one for our voting system should consider all edge cases. As such, I think that as long as a reasonable need exists for the discussion period to be extended, it should be possible in theory for this to be possible. Even if I agree that six weeks is exorbitantly long, I am wary of adding a rule to my proposed system that caps the discussion time anywhere. That being said, I am not unsensitive to arguments of process abuse and diminishing returns, and as such I do believe that extending the discussion period should be made harder as time goes on. My current proposed system already does that to some extent, but it is certainly possible to improve in that area. I had a few other things that I had thought of but that, in the interest of not overcomplicating the process, I did not add to my original proposal; however, two of them (variable extension times and objections to extensions) have now been independently proposed by other people, so I think perhaps I should add them after all. Additionally, my original proposal had the time extension start from the point where it was proposed, rather than from the end of the current discussion period. The reason for this was to encourage that extensions are only proposed and seconded when they would actually be needed, rather than proactively by people who actually care only about avoiding the vote at all, but I think we can also avoid that issue by mandating that a time extension can only be proposed if there are less than 48 hours left in the discussion time currently. Given all that, here's something that could work, and that I would see as reasonable: - The initial time of the discussion period is 1 week - When less than 48 hours remain in the discussion time, time extensions can be proposed under the same rules as ballot option proposals. - As soon as a time extension reaches its required number of seconds, it is active and cannot be withdrawn. - The initial two time extensions increase the discussion time by one week; further extensions increase the discussion time by 72 hours - Once the discussion time has reached 4 weeks, further extension proposals can be objected to by any developer. If the number of opposing developers is higher than the number of valid seconders for the extension proposal by the time the discussion period would run out if the time extension had not been voted upon, then the time extension does not happen. - If a time extension happens, the proser and the first K seconders can no longer propose or second any time extension. - There is no limit to objections to time extensions. This makes it trivially easy to extend to 3 weeks, not so easy but doable to extend to 4, and probably highly unlikely to extend beyond that, except if a majority of the project believes that it is better to wait a few days than it is to go to a vote now, or to withdraw the vote entirely (and that is the whole point of this process). The third option I had in mind (linking a time extension to a particular ballot option proposal) had a number of edge cases that meant I thought it a pretty bad idea overall, so I'm not going to suggest that. The downside of the above as compared to other proposals is that the system becomes more complicated with each rule that gets added. I don't think it is critically problematic yet with the above proposal, but am open to arguments otherwise. I note that both Russ and Sam have mentioned they may vote my proposal above FD, which I find encouraging. In the interest of clarity, however, I'll note that I do not intend to return the favour; I think having a time limit that is reflective of the situation at hand is a much better situation than having a set of rigid rules that cannot be changed, other than by restarting the whole process from scratch, which is a much worse situation -- I can imagine it being difficult to convince all proposers of ballot options that they should withdraw their ballot option so that the discussion time can be reset, in case
Re: Draft GR: Resolution process changes
Russ Allbery schreef op 7 november 2021 22:33:48 GMT+02:00: >Hi all, > >I think the discussion has mostly died down on my draft GR. Wouter's >alternative proposal has some support, but not the sort of overwhelming >support that would lead me to believe I should drop my proposal in favor >of his, so I think that will be best handled as an additional ballot >option. > >Below is the draft GR as I intend to propose it. There are no substantive >changes from the previous draft, but I added a rationale and changed the >text to clearly describe the changes to make to the constitution. > >I intend to propose this formally as a GR on November 13th and ask for >sponsors. Please let me know if this would cause problems for anyone that >would warrant further delay. > >This is also the last call for any discussion or changes before this >becomes a formal GR and the discussion period clock starts. (Obviously, >people can still propose changes during the discussion period.) > >Draft GR begins here: > >Rationale >= > >We have uncovered several problems with the current constitutional >mechanism for preparing a Technical Committee resolution or General >Resolution for vote: > >* The timing of calling for a vote is discretionary and could be used > strategically to cut off discussion while others were preparing > additional ballot options. >* The original proposer of a GR has special control over the timing of the > vote, which could be used strategically to the disadvantage of other > ballot options. >* The description of the process for adding and managing additional ballot > options is difficult to understand. >* The current default choice of "further discussion" for a General > Resolution has implications beyond rejecting the other options that may, > contrary to its intent, discourage people Developers ranking it above > options they wish to reject. > >The actual or potential implications of these problems caused conflict in >the Technical Committee systemd vote and in GRs 2019-002 and 2021-002, >which made it harder for the project to reach a fair and widely-respected >result. > >This constitutional change attempts to address those issues by > >* separating the Technical Committee process from the General Resolution > process since they have different needs; >* requiring (passive) consensus among TC members that a resolution is > ready to proceed to a vote; >* setting a maximum discussion period for a TC resolution and then > triggering a vote; >* setting a maximum discussion period for a GR so that the timing of the > vote is predictable; >* extending the GR discussion period automatically if the ballot changes; >* modifying the GR process to treat all ballot options equally, with a > clearer process for addition, withdrawal, and amendment; >* changing the default option for a GR to "none of the above"; and >* clarifying the discretion extended to the Project Secretary. > >It also corrects a technical flaw that left the outcome of the vote for >Technical Committee Chair undefined in the event of a tie, and clarifies >responsibilities should the Technical Committee put forward a General >Resolution under point 4.2.1. > >Effect of the General Resolution > > >The Debian Developers, by way of General Resolution, amend the Debian >constitution under point 4.1.2 as follows. This General Resolution >requires a 3:1 majority. > >Section 4.2.4 >- > >Strike the sentence "The minimum discussion period is 2 weeks, but may be >varied by up to 1 week by the Project Leader." (A modified version of >this provision is added to section A below.) Add to the end of this >point: > >The default option is "None of the above." > >Section 5.2.7 >- > >Replace "section §A.6" with "section §A.5". > >Section 6.1.7 >- > >Replace "section §A.6" with "section §A.5". > >Add to the end of this point: > >There is no casting vote. If there are multiple options with no >defeats in the Schwartz set at the end of A.5.8, the winner will be >randomly chosen from those options, via a mechanism chosen by the >Project Secretary. > >Section 6.3 >--- > >Replace 6.3.1 in its entirety with: > >1. Resolution process. > > The Technical Committee uses the following process to prepare a > resolution for vote: > > 1. Any member of the Technical Committee may propose a resolution. > This creates an initial two-option ballot, the other option > being the default option of "Further discussion." The proposer > of the resolution becomes the proposer of the ballot option. > > 2. Any member of the Technical Committee may propose additional > ballot options or modify or withdraw a ballot option they > proposed. > > 3. If all ballot options except the default option are withdrawn, > the process is canceled. > > 4. Any member of the Technical Committee may call
Re: Opposing strict time limits
On Sun, Oct 24, 2021 at 08:41:15PM -0600, Sam Hartman wrote:
> Interesting:-)
> I'd have to think hard about whether to rank that proposal above or
> below FD.
> I prefer Russ's option, but given your goals I agree this sounds like a
> good way to achieve them.
Can you shed some light on your opinion here? I've tried to build an
option that I hope can achieve some form of consensus, and I would like
to know whether I have succeeded in doing so. I don't think I'll change
much if not, but it would be useful information nonetheless.
Thanks in advance,
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Re: Opposing strict time limits
Hi Nikolaus,
On Mon, Oct 25, 2021 at 11:20:13AM +0100, Nikolaus Rath wrote:
> On Oct 22 2021, Wouter Verhelst wrote:
> > I also believe that a ballot with options that were written by people
> > who do not support that option will usually result in a cluttered
> > ballot, with various options that are almost but not quite the same
> > thing, and options that are irrelevant noise and which will never win. I
> > think this behavior should be discouraged if not outright forbidden
> > (although, again, I'm not sure how to forbid them),
>
> How about something like this?
>
> "My proposing or seconding a ballot option, every proposer/amender
> commits to rank this option above FD and (in case of multiple ballot
> options) higher than at least half of all the options. Should the
> proposer/amender's ballot not confirm reflect this at the time of the
> vote, proposer's/amender's vote will not be counted."
I had considered something along those lines, but decided against it.
Firstly for the same reason that Sam also pointed out: people should be
allowed to change their minds.
Additionally, while I think it is wrong to *draft* an option that you
consider incorrect, I do not consider it wrong to *second* an option
that you consider incorrect. As an example, consider that AJ Towns
seconded GR 2006_005, his own recall vote. I think that was a
reasonable thing to do, and I don't think we should forbid such behavior
by anyone. If you consider that plus the fact that Russ's proposal
allows proposers to withdraw their ballots, then this would incentivize
withdrawing proposals that otherwise still have sufficient support,
which is not necessarily a good idea.
So thanks, but no thanks :)
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Re: Opposing strict time limits
On Sun, Oct 24, 2021 at 03:53:38PM -0500, Richard Laager wrote:
> On 10/24/21 2:01 PM, Wouter Verhelst wrote:
> > 6. The project leader may, at any point in the process, set the
> > discussion period to any length between 1 and 3 weeks, except that
> > they may not do so in a way that causes the discussion period to end
> > within 48 hours of when this change is made, unless that would
> > require them to set a discussion time beyond three weeks.
>
> What is the purpose/intent of the "unless" here? If the discussion period is
> coming right up on (< 48 hours) 3 weeks, can the DPL truncate it using this?
It was never my intention to allow the DPL to override a time extension.
I see now that that is indeed not forbidden in my proposal; this is an
oversight that I will need to remedy. Thanks for pointing that out.
The wording I use allows the DPL to reduce and then lengthen the
discussion time to any point between one and three weeks.
If the DPL reduced the discussion time to, say, two weeks, and then
through the other process the discussion time is lengthened to 3 weeks
minus a day, then in the time window between 3 weeks minus 48 hours and
when the discussion time is now scheduled to end, the DPL would not be
allowed to lengthen the discussion time again to the maximum of three
weeks. I think that would be suboptimal.
But I realize now that the "causes" in that sentence already covers
that, so I can probably drop that "unless" cause and leave the paragraph
as-is.
> > 10. When a time extension has received the required number of seconds,
> > the discussion time is extended to end 72 hours from when the
> > extension was first proposed.
>
> This wording might need some tweaking for clarity/anti-abuse. Specifically,
> if I ask for and receive an "extension" when there was more than 72 hours
> left already, what happens?
Two things:
- The DPL will not be able to reduce the discussion time to less than
the 72 hours your extension gives you
- You will not be able to ask or second another extension.
... but nothing beyond that. Specifically, the discussion time will not
be extended beyond the original time, because your extension falls
entirely within the existing discussion period.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Re: Opposing strict time limits
On second thought...
On Sun, Oct 24, 2021 at 06:54:51PM +0200, Wouter Verhelst wrote:
> With this process, we could also default the minimum discussion time to
> be much shorter (say, one week or so); then if there is much to discuss,
> after 6 days or so someone could suggest "we're clearly not there yet,
> let's extend the discussion" and we can extend with this process.
This bit (which was meant to have discussion times as short as possible
by default, allowing to extend things if necessary) is probably a
mistake. The process I wrote down, by design, makes it more difficult as
time goes on to extend the discussion time even further; if I say that I
believe 3 weeks may not be enough in contentious debates (and I still
believe that), then reducing the time to 1 week by default and expecting
it to be extended until 3 weeks have passed is probably not a good idea.
So instead, scratch that bit. What we could do though is allow the DPL
to reduce the discussion time from 3 weeks down to one week (but not
up), and allow this process to be used on top of that if and when
necessary.
I also think now that perhaps allowing someone to propose multiple
extensions (and only limiting seconds) could be a bad idea, so I think
it might be better to limit proposers too.
In somewhat more formal language, apply the following changes to Russ'
draft (sections that remain unchanged from his draft are skipped below):
---
A.1. Discussion and amendment.
1. The discussion period starts when a draft resolution is proposed and
sponsored. The default discussion period is 3 weeks.
[...]
4. (removed, does not apply; for clarity, the following are not
renumbered although they would have to be in a final proposal)
[...]
6. The project leader may, at any point in the process, set the
discussion period to any length between 1 and 3 weeks, except that
they may not do so in a way that causes the discussion period to end
within 48 hours of when this change is made, unless that would
require them to set a discussion time beyond three weeks.
[...]
8. Anyone may propose an extension to the discussion time. These
extensions may be seconded according to the same rules that apply to
second new ballot options.
9. As soon as a time extension has received the required number of
seconds, these seconds are locked in and cannot be withdrawn.
10. When a time extension has received the required number of seconds,
the discussion time is extended to end 72 hours from when the
extension was first proposed. Its proposers and seconders may then
also no longer propose or second any further time extensions for the
same ballot, and any further seconds for the same extension proposal
will be ignored. In case of doubt, the Project Secretary determines
how the time of the original proposal is measured, and how the order
of seconds is determined.
---
I *think* this language also allows the DPL to propose a time extension
once, without any seconders, under 5.1.5, but I'm not sure. I think this
is a good thing, and perhaps we should make that somewhat more explicit.
The language I suggest purposely also allows the DPL to change their
mind: they can reduce the discussion time to one week because they
believe the matter is urgent, but then when there is a lot of discussion
happening, they can decide that one week is not enough and extend it to
two weeks, say. Or they can decide that they don't believe more than one
week is necessary, even if discussion is happening; if other people
disagree, they can then attempt to use this procedure to extend the time
if they believe that is necessary.
(I should also note that, given this is an amendment to an amended
version of the constitution, I haven't yet looked at all the possible
corner cases that this would result in, and so some tweaking might be
required; but at least this gives us something to work from)
Thoughts?
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
signature.asc
Description: PGP signature
Re: Opposing strict time limits
Hi Sam,
On Sat, Oct 23, 2021 at 12:49:57PM -0600, Sam Hartman wrote:
> However there is one area of agreement, and I'll focus there.
> I agree that if a sufficient part of the project wants to continue the
> discussion, we should be able to do that.
> I just don't see how to accomplish that in a way that is better than
> what Russ proposes without being open to abuse.
Thanks for this message. It caused me to reconsider what I think is most
important, and how to accomplish it.
To me, what matters most is that the ballot is built in a way that makes
it most likely that all the relevant options are represented on the
ballot. Not necessary all the *possible* options -- there will always be
fringe opinions that are not supported by a significant amount of
people, but for those it doesn't really matter whether they're on the
ballot; if you can't even convince a handful of people that an option
should be voted on (let alone whether you *agree* with it), then it's
highly unlikely that that option will carry the vote.
However, the problem I see with strict timings that cannot be extended
in any possible scenario is that we may end up with a situation where
one option cannot be fleshed out entirely due to lack of time. I think
it's unrealistic to assume that in such a case everyone can be convinced
to postpone the vote by two weeks, *at least*, rather than extend the
discussion time by a few days in order to allow the option that hasn't
finished gathering enough seconds to finish up and become acceptable to
enough people.
So what I think is important is to allow for a way to get a short amount
of extra time, *once*, in order to finish up a proposed ballot option.
This could be accomplished as follows:
- If you think you need more time to flesh out a ballot option, you can
formally request, on the -vote mailinglist, for more time.
- A request for more time can be seconded, with the same requirements in
terms of number of seconds to get an option on the ballot.
- If the request for more time achieves the required number of seconds,
then the discussion time will last until a certain amount of time (as
specified in the constitution) from when the request was made (i.e.,
the count would *not* start from when the discussion time would
currently expire).
- The process can be repeated as long as the discussion time has not
expired; but, crucially, anyone who seconded a previous extension
request cannot second another one (although you can *request* another
extension if you want).
In practice this would mean that if you have a significant level of
support for extending the discussion time, you can probably get the
discussion time extended twice, and *maybe* three times if you're lucky,
but I think it highly unlikely you'll be able to extend beyond that.
The thought process behind requiring the same level of support for a
time extension as compared to adding an option to the ballot is that
this way, someone could say "I like this proposal, but there are some
details that I would like to see changed before I am prepared to
formally support it". If there's only a limited amount of people who
feel that way, then wordsmithing is unlikely to result in a text that
will satisfy enough people to result in an extra ballot option. However,
if there are, then such an option does have a fighting chance of making
it on the ballot, and I think we should give the people advocating for
that option sufficient time to get there.
In order to make this process work, the time of a single extension
should be long enough so that a person who requests the extension has
sufficient time to go to bed, wake up, go to work, come home, eat, draft
their proposed ballot option, post it to this list, and then have
sufficient time to allow for people to second it. That means that 24
hours is certainly going to be too short, but a full week is probably
going to be too much. I would suggest 72 hours at this point, but I'm
not married to that number.
With this process, we could also default the minimum discussion time to
be much shorter (say, one week or so); then if there is much to discuss,
after 6 days or so someone could suggest "we're clearly not there yet,
let's extend the discussion" and we can extend with this process.
If this process (or something similar) were to be incorporated in the
current draft, my objections to it would vanish.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
signature.asc
Description: PGP signature
Re: Opposing strict time limits
Hi Russ,
On Fri, Oct 22, 2021 at 11:22:36AM -0700, Russ Allbery wrote:
> To fully achieve what Wouter is calling for would therefore *also* require
> a constitutional change. It's not a preservation of the existing status
> quo. I know Wouter knows that, but I wanted to make sure it was explicit
> for everyone else.
I concur -- and to expand on this a bit, I'd like to clarify a bit:
I think we agree that the rules for timing in the current constitution
are a bit messed up. The initial proposer of a GR has powers to affect
the timing that don't strictly belong with that person, and these powers
can be abused. I think we both agree that this needs adjusting.
The difference is in how we would adjust things: your draft proposes to
take that power away entirely, whereas I think a better way forward is
to adjust who can use those powers.
I also don't want to create a situation where the process is fully
unbounded. Currently, effectively everyone can call for a vote at pretty
much any time after a minimal time has passed. I think this is a
feature, not a bug, of our current system, and I want to retain that
feature. I understand that you disagree.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Opposing strict time limits
Hi all, Let me start by apologizing for taking this long to send this email. The attentive reader will have noticed my name in Russ' original draft as one of the people who reviewed it. When Russ sent his initial proposal, I started drafting a large response that I lost due to a silly mistake on my end. Life then intervened, and I didn't have time to follow up until now. That said, I think introducing a fixed time limit on a GR is a bad idea, for various reasons. First of all, no matter how careful we choose a time limit based on historical precedence, I think it is naive to assume we will be able to come up with a time limit that will always work for all future GR proposals. Some issues are contentious, and they take time to work through them. In my reading, the longest we have ever taken to decide on a vote was for GR 2006-003, where the initial proposal was sent in June but the eventual vote only opened in September[1]. An argument that has been brought forward to avoid that problem is that it is theoretically possible to discuss matters on this list before starting the formal procedure. While that is true, I would like to point out that the whole reason for the introduction of this time limit is so that people can't game the system by using procedural measures to delay the vote, possibly indefinitely. If we don't want to allow people to delay the vote, we should *also* not allow people to game the system by forcing a vote prematurely, through proposing a formal GR when someone else offers incomplete ideas that they would have preferred to see discussed first. Again, I would point to GR 2006-003 where something along those lines happened[1]. I fear that in order to avoid that pitfall, people may wish to discuss things in private amongst themselves rather than posting something to the -vote list when they want to start looking at a problem, which will give them an unfair time advantage. Additionally, it is not always possible to foresee all of the complexity in a problem space; we may be quite a bit into the formal discussion of the ballot when we decide that there are some significant issues that require exploring and which would benefit from more time. If everyone involved agrees that this is a good thing, then I think we should allow for that possibility; the proposed procedure does not do so, and I fear that this may result in rushed proposals that are suboptimal and do not resolve the issue at hand. An argument that has been brought forward to remedy this is that it is theoretically possible to advance a vote for the default option in such a case. While this is true, that is problematic: first of all, it will delay the resolution of the situation by a significantly larger amount of time (you will need to go through a complete vote only to have to do the whole process over again). I think it is relevant in this context that we only managed to do this one time in the history of the project, in a vote where I can't help but feel like the proponents of the vote tried to game the system (2006-005[2]). We might have been able to use this for 2004-004, but alas. Additionally, I believe that proposing we vote the default option more often is antithesis to what we *should* be doing. I think a GR vote should generally be the final answer to an issue we are dealing with, and that in order to do that, we should ensure that the ballot is complete, with all relevant options represented. I don't think we get that if we introduce a rigid timeline that cannot be diverted from in exceptional situations. I hear and agree with the argument against such a procedure; having a way to delay the vote which everyone can trigger opens the system up to abuse, which could allow the vote to be delayed indefinitely if formulated badly. I believe the answer to that is not to remove the option to delay the vote entirely, but to restrict the conditions under which such a delay can be invoked; only provide it to the DPL, or provide only a limited number of delays, or allow a majority of people who proposed options that are already on the ballot to object, or something along those lines. The goal should be to end up with a procedure where *can* extend the discussion period if discussions are actually still happening and we believe it is valid, without allowing people who want to avoid any vote from happening entirely to delay things indefinitely. Additionally, this proposal does not remedy what I think is another issue we have with our procedure, which I have been wanting to resolve one way or the other for quite a while but have no idea how to do so; the "I want to create a ballot with all possible options" antipattern. We had a few cases of this over the years (at least two that I can remember), usually by well-intentioned people who want to get things to a vote quickly, but I honestly believe it creates more problems than it attempts to solve. Writing an option that does not represent your own personal opinion is
Re: re. RMS
On Mon, Apr 05, 2021 at 09:29:07AM -0400, Miles Fidelman wrote:
> Given that Friday was Autism Awareness Day, it might be worth noting that
> RMS is clearly "on the spectrum" - and well known since the days he slept in
> his office at MIT (my student days).
>
> Why is it that nobody ever gives him any leeway for that?
I am "on the spectrum" too, and nobody gives me any leeway for that either.
Not that I *want* leeway -- the point is that it's possible to learn,
and that if it's significantly more difficult for RMS, he can talk to a
therapist and learn that way (which is what hundreds of other people "on
the spectrum" end up doing, and they are much better off for it!).
Meanwhile, there are plenty of people who suffer under RMS'
"leadership", and they do not deserve that.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Re: Secret ballot and RMS Resolution
Hi, On Thu, Apr 01, 2021 at 03:06:07PM +, Didier 'OdyX' Raboud wrote: > Could we get a Constitution Amendment GR passed along the lines of the > following? > > Provided that 2*Q developers demand it, votes are kept secret after > the vote ended. I would actually prefer it to be easier: If one developer demands it, the votes will be kept secret, *unless* N developers oppose the secrecy of the vote (with the definition of N being up for debate). I think it may be more important to make people feel safe to express their vote than to keep the process open. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Re: What does FD Mean
On Fri, Apr 02, 2021 at 11:29:58PM +0200, Pierre-Elliott Bécue wrote: > I'd rather have a None of the Above default option all the time along > with FD. It'd probably help. FD effectively is the same as "none of the above". You might believe that the subject is stupid and that the horse is dead and we shop stop flogging it, but the fact that we got it to a vote in the first place proves that there are people who disagree with you, and they will translate NOTA winning into "we haven't found the right answer yet, so let's try this again, for real this time". That's further discussion, just under a different name. I'd rather have an option that is honest with everyone and declares what will in effect happen. If you want an option that says "no, not now, not ever", you need to put it on the ballot. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Re: Nuance Regarding RMS
Hi Barak, On Thu, Apr 01, 2021 at 11:51:59AM +0100, Barak A. Pearlmutter wrote: [...] > I'm not sure he'd be an ideal board member, but that’s a practical > rather than ethical consideration, and surely best left to the > judgement of the individual organization. > > What’s problematic to me about this whole “Cancel RMS” business is the > lack of nuance. He’s clearly not neurotypical in a way that makes him > very difficult to deal with. So, In my book, that's not an excuse. I too am not neurotypical, and my natural tendencies make me, too, very difficult to deal with. However, most people who are not neurotypical are still capable of learning. When people tell me that I'm being difficult, I listen. When people tell me that what I'm doing may push people away, I will usually attempt to avoid that particular type of behavior. I do not always succeed; but in doing so, over the years, I've changed my personality from someone who used to be rather annoying to what, I hope, is not the case anymore. RMS has been told, on numerous occasions, that the things he's doing are counterproductive. He either chose to ignore the advice, or decided that the advice was wrong. Either way, the result is that we now have a person in a position of leadership who tends to push people away, rather than being a positive force in the free software movement. > He doesn’t make appropriate eye contact. > He’s strange in ways that I think, on average, affects women more than > men. But should we bully or ostracise him for that? I don't think that pointing out that the way in which the FSF made a decision that they could have known was going to antagonize a lot of people amounts to "bullying". I don't think RMS should be forced out of the free software world altogether. He has many accomplishments, and we should be grateful to him for jumpstarting the free software movement as a whole (I know I am). However, there is a difference between acknowledging a person's past accomplishments, and believing that he is the right person for a position of leadership. In the case of RMS, I do the former; I don't do the latter. I do think that RMS can still have a position within the FSF; but for him to announce that he's back on the board, that it's a done deal, and that "he won't be resigning again", just like that, was a mistake. It's that mistake that this is a reaction to. > I think we should > try to develop coping strategies for both him and people who want or > need to deal with him. I don't think we need to continue dancing around any one person, both because it's annoying for everyone who needs to dance, *and* because *it doesn't help the person in question*. I think RMS needs to go see a therapist. Not because I think he's crazy or anything of the sorts, but because I can tell you from personal experience that a therapist can teach you certain techniques that may help you improve your own personality in an incremental fashion. > That’s actually supporting and accommodating diversity. And it’s hard! > We should seek ways to leverage his strengths, which are considerable. > Of course, that assumes lack of malice, which I think is the case with > RMS. He’s not malicious. I agree that he is not malicious, but I also don't think that is at all relevant. Malice is not required for being incapable of leading. I think RMS is utterly incapable of being a good person in a position of leadership for a community that I consider myself to be a member of -- and that's still true even if I'm not now, nor have I ever been, a member of the FSF in any shape or form. The open letter does not state that RMS should be ejected from the free software movement in general, or from the FSF specifically. Were that the case, I would agree with you that it was wrong. Instead, it merely states that he should be removed from leadership positions, both in the FSF and in the GNU project. I agree with that, because I don't think he is the right person to lead either of those. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Re: Asking DPL to shorten Discussion Period for rms-open-letter
Hi Jonas, On Sat, Mar 27, 2021 at 11:46:03PM +0100, Jonas Smedegaard wrote: > Hi Wouter, > > Quoting Wouter Verhelst (2021-03-27 18:19:57) > > On Sat, Mar 27, 2021 at 10:41:57AM +0100, Jonas Smedegaard wrote: > > > Thanks for your judgements(!), Luke and Enrico. > > > > > > For the record, I do not defend actions of RMS. I defend his right > > > to a fair trial. > > > > Nobody is claiming Richard doesn't have the right for a fair trial. He > > is still a human being, and every human being has such a right. > > > > However, there is no trial here. > > We agree that there is no trial here. > > My point is however tied to that of cancel culture a.k.a. group shaming > - specifically that the initial text on the ballot use judgemental > language that I can only read as intended to condemn the person that we > want to distance outselves from. Maybe I use the words wrongly or > sloppily - what I mean is the difference between saying "that person > allegedly made a crime" and "that person has made a crime", where the > former is an accusation. The word "allegedly" is used by the press when reporting on a case, as a shorthand for "we don't want to take a position either way, but this is what the one party in the case is saying". Since we *do* want to take a position here, using "allegedly" is not appropriate. Having said that, the language of the letter does not say that RMS *is* mysoginistic, transphobic, or ableist; it states that "he has shown himself to be" all these things. The difference here is subtle, but it is a difference of exactly the type you are arguing for. > Seems my concern is what in english is called "libel": > https://en.wikipedia.org/wiki/Defamation#Libel According to that very page, for a statement to be considered libel, it has to be false. Quote: Defamation (also known as calumny, vilification, libel, slander or traducement) is the oral or written communication of a *false* statement about another that *unjustly* harms their reputation and usually constitutes a tort or crime (emphasis mine) Do you have reason to believe these statements are false, and/or that they "unjustly" harm RMS' reputation? There is no question that they will harm his reputation; however, given the harm he has done to others, I do not believe it is "unjust", in that it is a result that could have been expected. > > There is just the statement that RMS > > has been a very annoying person for the past several decades, and that > > having him in a position of leadership, in the opinion of those people > > that signed the letter, causes more harm than good. > > > > *That is not a trial*. That is an opinion on the effects another > > person's behavior has to a community. > > You talk about the part of Debian distancing itself from RMS. > > I talk about the part of Debian making accusations against RMS. > > Imagine someone in Debian blogged about skin colors, super annoyingly > and persistently for many years but always "just talking about stuff" > maybe walking close to but never crossing the line of racism, Do you believe that to be the case here? Do you think RMs has "walked close but never crossed the line" of the things he's being accused of? If not, then I fail to see what the problem is. If you do, then... well, we'll have to discuss that. For the record, I don't believe so. I do believe he is all the things he is being accused of in that letter. [...] > > Debian stating to the FSF that we would prefer not to have to deal > > with RMS is not a punishment for RMS. > > Yes, I agree. But again that is not the group shaming part which I was > talking about. > > Stating that RMS "has shown himself to be misogynist, ableist, and > transphobic" is not simply expressing "that we would prefer not to have > to deal with RMS" - it is a strong accusation. Not a wild > out-of-the-blue accusation, but still an accusation. We agree that it is an accusation. I don't see what the problem is with that? Unless you believe the accusations to be false, it is fair to accuse someone of doing something if you believe the said something is wrong. If the accusations are strong, then that is only because the said things are *very* wrong. That's not the fault of the accuser; it is the fault of the accused. > Unless or until a fair trial has ruled that he is guilty of those > horrible crimes, in which case in becomes facts. What he is being accused of is not a crime in any jurisdiction that I am aware of. He is not a nice person towards fellow human beings, but most laws don't require you to be. You don't need a trial for ever
Re: Asking DPL to shorten Discussion Period for rms-open-letter
On Sat, Mar 27, 2021 at 10:41:57AM +0100, Jonas Smedegaard wrote: > Thanks for your judgements(!), Luke and Enrico. > > For the record, I do not defend actions of RMS. I defend his right to a > fair trial. Nobody is claiming Richard doesn't have the right for a fair trial. He is still a human being, and every human being has such a right. However, there is no trial here. There is just the statement that RMS has been a very annoying person for the past several decades, and that having him in a position of leadership, in the opinion of those people that signed the letter, causes more harm than good. *That is not a trial*. That is an opinion on the effects another person's behavior has to a community. It is not a very positive opinion about that person's behavior, and in that respect this may reflect on RMS' reputation, but *a reputation is not something that is decided by trial*. It is instead something that is decided by the common opinion of all the people in the community. A trial is meant to decide on who is to blame for something, and, if that can be determined, what the appropriate punishment for the crime would be. Debian stating to the FSF that we would prefer not to have to deal with RMS is not a punishment for RMS. It is not an assignment of blame. It is instead Debian stating that we don't like something, and can they please do something about the situation. Debian deciding that we don't want to cooperate with the FSF anymore, to the extent possible, if the FSF doesn't do what we ask of them, is not us punishing the FSF. It is us deciding that between having to deal with an organization with major organisational issues, in our opinion, and having to figure out alternative options for some of the FSF software, we would prefer the latter. XKCD 1357 applies here, with s/free speech rights/rights to a fair trial/. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Re: Costs of running a Debian foundation
On Wed, Mar 18, 2020 at 02:55:48AM -0400, Brian Gupta wrote: > > > On Wed, Mar 18, 2020 at 1:37 AM Wouter Verhelst wrote: > > > > On Wed, Mar 18, 2020 at 12:46:09PM +0800, Martin Michlmayr wrote: > > > So I'm more satisfied with the rationale of creating a Debian > > > foundation, although my concerns about the actual operations still > > > apply (i.e. how are you going to make sure you'll do a better job than > > > the TOs you're not happy with when there have been countless failures > > > of running non-profits in the past). > > > > I have to say that I share those concerns. > > > > Specifically, I believe that SPI was meant to be our foundation. That it > > grew into something more, and that it took several years for it to do > > what we needed it to do is unfortunate; but there is no reason to > > assume, from my point of view at least, that building another foundation > > to do what SPI couldn't do, will bring us more success. > > > > Brian, what's your view on that? > > First off, I'd like to reiterate that I don't expect to end relationships with > our current TOs, including SPI. (I stated this in my platform, but there was > enough potential for misunderstanding that I want to reiterate.) > > I also agree that when looking back at history, that SPI was meant to be the > Debian Foundation that I am advocating for now. However, the thought back > then, > was that since Debian was doing all the work to set up a non-profit, that it > wouldn't be that much more work to provide the same services to other FLOSS > projects. At one point this expansion of scope threatened to overwhelm SPI, > they > struggled for many years, but it appears they have found their stride now and > are successfully servicing over 40 projects today. This makes them one of the > largest homes for FLOSS projects today. It's a remarkable success story, > especially looking at how far SPI has come in not that long a time. > > That said, when you are servicing over 40 projects, your priorities need to > change, and you MUST look at what you can do for ALL your projects, not just > your founding project. > > In hindsight, it was a happy accident that SPI was created the way it was, and > grew into the multi-project home it did. > > However, we - as a project - need to adapt as well. We realize that SPI has > grown into something great but cannot support the Debian project fully and to > the extent we need. We are large enough and have enough requirements in legal > and support services that it warrants founding our own foundations that will > permanently be aligned with the ever evolving goals of the Debian project. > > What we do as a project isn't easy. We don't shy away from things because they > are hard, and have risk. We try to do things that we are right and worth > doing. > In this case, I'll agree, it's not going to be easy. It will be a lot of work. > However, there are reasons to be optimistic. > > 1) Experience: We have Project Members that have a lot of experience running >many different entities and know what has worked and what hasn't. > 2) Depth: We are a large and well-respected project. Many people want to help, >especially if they know it's going to help Debian. > 3) Options: We aren't taking away anything we currently have. Our current TOs >will remain there to support us, giving us time to do it right. > > FreeBSD Foundation works, Postgres Foundation works, KDE e.V. works, Gnome > Foundation works, so we can make Debian Foundations work, too. I'm wondering to what extent this is a US-centric view. Debian.ch and Debian France are Debian-specific TOs; SPI is not. Your explanation above gives a bit more rationale as to why creating a foundation as another TO might be a good idea, but it does not explain how it will avoid the XKCD 927 problem; that is, you're saying we have too many TOs to deal with, so you want to create another layer of TOs to handle the other TOs and now we have even more TOs to deal with. I can see that it might be a good idea to create another TO in the US to be Debian-specific, but I remain unconvinced that it is a good idea in general. -- Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22
Re: Costs of running a Debian foundation
On Wed, Mar 18, 2020 at 12:46:09PM +0800, Martin Michlmayr wrote: > So I'm more satisfied with the rationale of creating a Debian > foundation, although my concerns about the actual operations still > apply (i.e. how are you going to make sure you'll do a better job than > the TOs you're not happy with when there have been countless failures > of running non-profits in the past). I have to say that I share those concerns. Specifically, I believe that SPI was meant to be our foundation. That it grew into something more, and that it took several years for it to do what we needed it to do is unfortunate; but there is no reason to assume, from my point of view at least, that building another foundation to do what SPI couldn't do, will bring us more success. Brian, what's your view on that? -- Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22
Re: Proposal to overturn init systems premature GR
On Tue, Dec 03, 2019 at 11:40:15AM -0600, Gunnar Wolf wrote: > [ Removing tons and tons of personal Cc:s, I guess they all follow d-vote ] > > Ian Jackson dijo [Tue, Dec 03, 2019 at 04:15:02PM +]: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > I have been proposing that there should be an alternative to Guillem's > > proposal. I need a few more days to do this. (Guillem's proposal has > > IMO excellent framing but lacks suitable specific guidance. I hope we > > can make a version which combines Guillem's framing with some > > appropriate specific guidance, perhaps taken from one of the other > > proposals.) > > > > Sam has decided to cut short this process. We started this public > > discussion less than a month ago. This is very short. > > (...) > > Ian, please don't. > > Well, you did. But I must say, I'm not the least thrilled at seeing > this initiative. > > While I share Sam's impression that the whole discussion has been > (impressively!) very civil and productive, I do not think further > delaying will be beneficial to the project. Yes, Guillem's proposal > arrived quite late in the process, presenting a very different and > important view. Yes, probably it could be improved. However, stating > the discusion started less than a month ago... Is quite far from the > observed fact that it started no less than five years ago. No, that's not true. The issue has existed since five years ago. However, discussion on *this* GR has started only a month ago. A month is fairly short in Debian time to draft all the options on a ballot that is likely to be so contentions. That we've managed to get this far is amazing, but does not negate the fact that people are still working on their draft. If this option does not make progress in a few days, then yes, you're right. But I agree with Ian -- even if I'm unlikely to vote for that option -- that allowing it a fair chance to arrive onto the ballot is important. > We are trying to put closure to it. I think we can improve minutiae > forever, but will never reach a perfect solution that leaves everybody > happy. Perhaps, but the only way to do that is to allow every valid option to reach the ballot. I don't think that waiting a few more days is going to make the sky fall. There have been votes that took *far* longer than this one to be decided on. Historically, we've waited until discussion died before we called for vote. It feels wrong to not do the same now, on an issue that is likely to be this contentious. > That's the main reason to hold a GR. The available options > (Guillem's included) will most probably cover the opinions / feelings > of basically all developers. And if something is missing, as others > have stated, either a high rank for FD or a new GR following this one > can be the next possible action. So you're saying that instead of extending things for a few days now, you'd rather see the process started over again, which will take a *lot* longer than that? That seems... weird. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Re: Call for Votes on the Initit Systems GR
Hi Sam, On Tue, Dec 03, 2019 at 10:09:26AM -0500, Sam Hartman wrote: > > The minimum discussion period lapsed sometime Saturday. > So, as one of the authors of a proposal, I ask the secretary to please > prepare a ballot and start the vote. > As the DPL, I ask the secretary to extend the voting period by a week. This is the first time in the history of the project[1] that a call for vote is done *while people are still actively drafting options*. Usually we wait for discussion to die out before we call for votes. Even if that isn't the process set out in the constitution, it feels very disingenious and dishonest to not allow people to finalize their options. It is a break with precedent, and one that I think is not necessary. The sky isn't going to fall, and the world isn't going to end, if we postpone this a bit more. Even if you don't want this to be voted on over the holidays, you can still postpone it so that the vote happens *after* the holidays. Please don't make a bad situation worse. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Re: My analysis of the proposals
On Mon, Dec 02, 2019 at 08:36:11PM +0200, Uoti Urpala wrote: > On Mon, 2019-12-02 at 19:29 +0200, Wouter Verhelst wrote: > > Sysvinit has worked for over 20 years. Yes, it has warts, but the warts > > > I therefore disagree in the strongest terms to make this be about the > > position of sysvinit, except in so far as it is part of an abstract > > group of "not systemd" options that we are trying to decide upon. > > I don't understand what point you're trying to make. My point was that > what actual conflict there is, is in practice conflict between those > who want to stay with sysvinit, and those who want to use systemd; and > therefore the most practically important part of a resolution is how it > would apply to sysvinit support. Your message first contains a defense > of sysvinit, then a claim that "therefore" it should not be considered > to be about sysvinit. I don't see how that "therefore" would logically > follow. I grant you that I could have quoted better. Allow me to try to do that now. You wrote, in a message upthread, the following: > [...] I disagree: it's perfectly reasonable to consider sysv init > scripts obsolete, and consider "try to keep sysvinit at 2014 levels > indefinitely" activity a dead end. > > Note that I'm not saying that people shouldn't develop alternatives to > systemd. But to be taken seriously, they'd need to display some real > progress beyond sysvinit (and Upstart). Just "this allows to boot > without systemd" is not a worthwhile "alternative". This to me framed the rest of what you wrote, also in later messages. I should have replied to the above message rather than the later one, but I guess I was not careful enough. Sorry about that. Anyway, my point is that even if you think that sysvinit is now no longer a valid option, that is an opinion that reasonable people could disagree with. For those who think that sysvinit is good enough, and that the problems for which systemd provides a solution are not problems to begin with, there is nothing wrong with the premise of "try to keep sysvinit at 2014 levels indefinitely", on the contrary. So, while it's a valid question for Debian to decide whether to continue to support alternative solutions to systemd, I don't think it's reasonable for someone who is not involved with any of the alternatives to decide whether one of the available options is valuable to begin with. As such, I don't think, and vehemently disagree with your stated proposal, that we should decide anything on sysvinit in particular, other than through the more general question of "should Debian support anything that is not systemd". Thanks, -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Re: My analysis of the proposals
On Mon, Dec 02, 2019 at 03:59:58AM +0200, Uoti Urpala wrote:
> On Sun, 2019-12-01 at 18:43 -0500, Sam Hartman wrote:
> > > > > > > "Uoti" == Uoti Urpala writes:
> >
> > Uoti> IMO encouragement for supporting alternative systems could be
> > Uoti> reasonable, but only for actual new innovation; maintainers
> > Uoti> should be explicitly permitted to remove any existing sysvinit
> > Uoti> scripts and refuse addition of similar scripts. Systemd units
> > Uoti> should be no worse a basis to bootstrap a new system.
> >
> >
> > This is what I tried to capture with Proposal B.
> > I wrote a blog post yesterday which still should be on planet discussing
> > my thoughts about this and discussing some of the risks of that
> > proposal.
>
> Based on your blog post, your technological views seem similar to mine.
> Where my view differs, and why I think Proposal B is not particularly
> satisfactory, is more about the social view of opposition to systemd.
>
> Like you, I think that from a technological point of view you shouldn't
> assume that those who want alternatives to systemd would support
> sysvinit. However, as a matter of social reality, people who oppose
> systemd almost exclusively do want to keep using sysvinit. People who
> find systemd objectionable mostly just don't want to switch to it,
> without really caring about whether their current setup is a
> technological dead end or not.
While I prefer systemd on my personal systems, I don't think this
framing is in any way correct or fair.
Sysvinit has worked for over 20 years. Yes, it has warts, but the warts
are well-known and can fairly easily be dealt with. More importantly,
the concept of how sysvinit works ("here's a bunch of scripts that are
executed" is at a certain level easier to grasp than systemd's concepts.
You may be of the opinion that systemd is strictly and obviously better,
but that is a judgment call, one which reasonable people may disagree
with. There is nothing wrong with being of the opinion that booting with
sysvinit is easier to grasp and preferable over using systemd. It is
therefore still a valid alternative for as long as Debian does not make
the use of systemd mandatory.
I therefore disagree in the strongest terms to make this be about the
position of sysvinit, except in so far as it is part of an abstract
group of "not systemd" options that we are trying to decide upon.
--
To the thief who stole my anti-depressants: I hope you're happy
-- seen somewhere on the Internet on a photo of a billboard
Re: [draft] Draft text on Init Systems GR
On Thu, Nov 14, 2019 at 06:32:32PM -0800, Russ Allbery wrote: > Wouter Verhelst writes: > > I think a better solution is to accept that some maintainers simply > > won't have the time or inclination to maintain support for non-default > > init systems, and that such init scripts (or whatever) should therefore > > be packaged separately from the main package, maintained by someone who > > actually uses the init system in question. > > It's not clear that this is technically feasible, so I'm not sure that it > makes sense to mandate this solution in a GR. I'm not so sure about that. What do you think makes it not technically feasible? We have historically shipped init scripts with the daemon that they serve, but there is no reason why we wouldn't be able to change that behavior. There could definitely be a package "initscripts" that contains init scripts which call binaries not in the same package. (in fact...) -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Re: [draft] Draft text on Init Systems GR
On Thu, Nov 14, 2019 at 06:36:53PM +, Ian Jackson wrote: > CONTRIBUTIONS OF NON-SYSTEMD SUPPORT WILL BE ACCEPTED > > * Failing to support non-systemd systems when such support is >available, or offered in the form of patches (or packages), >*should* be treated as a release critical bug. For example: init >scripts *must not* be deleted merely because a systemd unit is >provided instead; patches which contribute support for other init >systems should be filed as bugs with severity `serious'. > >This is intended to provide a lightweight but effective path to >ensuring that reasonable support can be provided to Debian users, >even where the maintainer's priorities lie elsewhere. (Invoking >the Technical Committee about individual patches is not sensible.) > >If the patches are themselves RC-buggy (in the opinion of, >initially, the maintainer, and ultimately the Release Team) then of >course the bug report should be downgraded or closed. The problem with this is that it, essentially, promotes drive-by patching: someone would like to use a program, but it doesn't come with support for their init system. So they write that support, test it perfunctorily (enough for their use case), and file a bug against the package. The maintainer is now required to include it, because RC. But let's assume there's a critical bug in the support they wrote. Something that during the right phase of the moon could eat data. That's RC, too. Who's supposed to fix that bug now? The package's maintainers? They don't have the setup to test the patch. That seems unfair. The person who filed the data-eating bug? What's to say they even have the skills to do that? That doesn't seem fair, either. The person who initially wrote the support would be ideal, but they are now unavailable. The maintainer is now forced to choose between dropping the support again, resulting in (most likely) another attempt; investing a lot of time in fixing the bug; or leaving it unpatched (and allowing for their users to have their data eaten). I think a better solution is to accept that some maintainers simply won't have the time or inclination to maintain support for non-default init systems, and that such init scripts (or whatever) should therefore be packaged separately from the main package, maintained by someone who actually uses the init system in question. That would also fit well with... > * It is for users and maintainers of non-default init systems, and >the surrounding ecosystem, to test and debug init scripts and other >aspects of non-systemd support. It is also for maintainers of >non-default init systems, and the surrounding community, to decide >what level of compromised functionality is acceptable to users of >non-default init systems. ... this. [...] -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Re: [draft] Draft text on Init Systems GR
On Thu, Nov 14, 2019 at 04:16:58PM +, Ian Jackson wrote:
> Wouter Verhelst writes ("Re: [draft] Draft text on Init Systems GR"):
> > You can formally propose a GR today, and I recommend you do -- otherwise
> > we end up discussing things before the discussion period, and then you
> > need to sit and wait at least seven days during the *actual* discussion
> > period for no good reason.
>
> I see what you mean, but respectfully, I disagree. There is no real
> hurry about this - it is a long-term thing. It is worth taking the
> time to not just get the options right, but also keep everyone
> comfortable.
Sure.
> In particular, if the DPL were to formally propose a GR, everyone who
> wanted another option on the ballot would immediately be on the clock:
> we would have to get our alternative either agreed with the DPL, or
> seconded, within 7 days, if we wanted to be sure.
Strictly speaking, this is correct.
Having said that though, I would expect a DPL who proposes a GR to not
call for a vote (even though they would be allowed to do so) when people
are still drafting alternate options and/or amendments.
Additionally, the DPL has the ability to vary the discussion period in
*both* directions. Rather than shortening it to 7 days, they can also
lengthen it to 3 weeks.
> Given the febrile atmosphere that some of these systemd discussions
> generate I think we want at the very least the process to avoid any
> hint of anything that feels threatening.
Such a DPL could state the above in public, to clarify that they're not
going to hurry anyone -- but that this is something they want to see
happen (at some point in the reasonably close future).
> I also agree with the people who suggested that it would be best if
> options were drafted by people who actually agree with them.
This is the core of my argument, yes. I don't think that it is useful
for anyone (DPL or otherwise) to propose a GR with more options than
what they themselves would want to vote for.
(there is a difference between drafting an option and seconding one in
this regard though)
> It is of course helpful of the DPL to guide that process, but
> ultimately the way the governance system is supposed to work is that
> people put forward their _own_ options.
Exactly; and I did not feel like that was happening here.
Anyway, I also understand what Sam is trying to do, and I would rather
not sound like a whiner, so this'll be the last bit I'll say about this
;-)
[...]
--
To the thief who stole my anti-depressants: I hope you're happy
-- seen somewhere on the Internet on a photo of a billboard
Re: [draft] Draft text on Init Systems GR
On Mon, Nov 11, 2019 at 08:58:52AM -0500, Sam Hartman wrote: > >>>>> "Wouter" == Wouter Verhelst writes: > Wouter> Oh, right. Okay. I suppose that makes sense; the nbd-client > Wouter> init script hasn't been touched since I wrote the nbd-client > Wouter> systemd unit, and so I can't really guarantee that it will > Wouter> work very well anymore. > > Wouter> I guess I was misunderstanding what Sam was writing > Wouter> initially; I thought he just meant that "if you do early > Wouter> boot, then we don't care about other init systems", which > Wouter> seems like it would make the whole point moot. > > Wouter> Perhaps > Wouter> rather than that, the GR should say something like: > > Wouter> "Due to the higher level of complexity inherent to > Wouter> early-boot services, it is expected that the init scripts > Wouter> (or equivalent) for services initialized during early boot > Wouter> be maintained by the maintainers of the init system in > Wouter> question, rather than by the maintainers of the service's > Wouter> package" > > I like this sentence, and if we get significant support from those who > favor choice 1, I would accept that amendment. > Meanwhile, I think I can go as far as > > >Policy notes that early boot services like those started from > >/etc/rcS.d may be tied closely to the init system in use and thus may > >need to be handled differently for each init system > > well within the spirit of the current choice 1. That is definitely clearer, yes. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Re: [draft] Draft text on Init Systems GR
On Thu, Nov 07, 2019 at 01:04:20PM -0500, Sam Hartman wrote: > > This is a draft GR. I hope to be at a point where I could formally > propose a GR in a week, assuming discussion converges that fast. You can formally propose a GR today, and I recommend you do -- otherwise we end up discussing things before the discussion period, and then you need to sit and wait at least seven days during the *actual* discussion period for no good reason. Note that "proposing a GR" does not imply "calling for the vote"; that happens later, after the GR has been properly drafted and discussion on all amendments has ended. Note also that every accepted amendment resets the discussion period, and that while you have the ability (as DPL) to accept amendments without seconds, and to vary the discussion period by up to a week, you do not have the ability to eliminate the discussion period altogether. Therefore it would make sense to have a formal GR proposal today so tha amendments can be made. > At this point, the question is whether the choices that need to be on > the ballot are represented in this draft GR. > > I did not obtain a review of this version from someone who favors init > diversity. In my opinion, our GR procedure works best if every choice on the ballot was drafted by someone who actually wants it to happen; otherwise you run the risk of two problems: - You may end up with options on the ballot that don't actually represent the opinion of *any* developer, *at all*. This represents clutter, and needlessly wastes time of voting developers who will have to wade through reading a (number of) useless options that nobody really wants. - You will need to judge whether any proposed amendment matches the opinion of anyone who previously already agreed with that option, when you are not in the best position to do so. Every time you accept (or reject) an amendment, you run the risk of alienating whoever actually agreed with that proposal, possibly resulting in them proposing their own alternate option. This almost ended up happening for GR 2004_004, and that one was a mess. Given your above statement, I'm assuming that your preferred option is #3. Is that correct? > I didn't give them a lot of time, and they just wrote to let > me know that they weren't going to be able to do a review this week. > Based on the feedback from debian-devel I decided that getting text to > the community now was the most important thing. > If this text doesn't meet the needs of that community, we'll change the > text. I hope my actions demonstrate that I've tried to work with and > understand the needs of all sides here; that has been my intent. > > > > version 2330c05afa4 > > Using its power under Constitution section 4.1 (5), the project issues > the following statement describing our current position on Init > systems, Init system diversity, and the use of systemd features. This > statement describes the position of the project at the time it is > adopted. That position may evolve as time passes without the need to > resort to future general resolutions. The GR process remains > available if the project needs a decision and cannot come to a > consensus. > > Choice 1: Affirm Init Diversity > > Being able to run Debian systems with init systems other than systemd > continues to be something that the project values. With one > exception, the Debian Project affirms the current policy on init > scripts and starting daemons (policy 9.3.2, 9.11). Roughly, packages > should include init scripts to start services that are included. > Policy notes that early boot services like those started from > /etc/rcS.d may be tied closely to the init system in use. I don't see why this is relevant in the current discussion. My nbd-client package is one that is relevant here; it has a systemd unit, and an rcS init script (which is then ignored by systemd). If this choice wins, then init scripts remain mandatory. If you provide an rcS init script, then systemd units are also mandatory. So this is not an exception to the rule? It just means you have more work to do. > Init > scripts are the lowest common denominator across all init systems. > Packages may include support for init systems like systemd service > units in addition to init scripts. Current policy makes it an RC bug > to include a service unit without an init script. > > Policy editors are requested to amend policy; including a service unit > without an init script is appropriate for a non-maintainer upload but > should no longer be an RC bug. If this choice wins, then why should it not be an RC bug to not have an init script? That doesn't seem to make sense. > Policy editors are requested to > consider whether there are cases where removing an init script that > used to be provided should be RC because it would break a system on > upgrade. > > Once the community of users of an alternate init system have said that >
Re: Q to all candidates: should we have more ports?
So, now that all candidates have answered... On Mon, Apr 01, 2019 at 01:55:37PM +0200, Wouter Verhelst wrote: > Specifically today, These two words were meant to be a reference to today's date. > should we try to make Debian usable on any of the operating system kernels > that I quoted above? This, given that all of those were proprietary kernels, was meant to be a ridiculous proposition. I'm surprised that most candidates gave it real consideration. I'm sure they were simply trying their best to remain polite in the face of someone asking something stupid :-) Ah well. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard signature.asc Description: PGP signature
Q to all candidates: should we have more ports?
Hi all, One thing that Debian has historically been good at, is to produce ports for various architectures. However, we're not the most widely ported; Gentoo, for instance, has been ported to Interix and macOS[1]. NetBSD has a few ports that we do not have, and its pkgsrc is available for a large amount of other operating systems beyond NetBSD itself, including macOS, HPUX, IRIX, AIX, QNX, and Solaris[2]. Should we try to catch up with these other systems in terms of ports? Specifically today, should we try to make Debian usable on any of the operating system kernels that I quoted above? Thanks, [1] https://en.wikipedia.org/wiki/Gentoo/Alt#Gentoo_Prefix [2] https://en.wikipedia.org/wiki/Pkgsrc -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard signature.asc Description: PGP signature
Re: having public irc logs?
On Mon, Apr 10, 2017 at 06:33:06AM +, Gianfranco Costamagna wrote: > The problem is not Debian vs me, but Debian vs a lot of people keeping > logs on their personal laptops + some servers around the world. If you think that creating a central IRC log service will make people stop logging Debian channels, you need to think again. Many people don't keep logs as a personal choice, but because the default in many (most?) IRC clients is to enable logging. If you want that to change, you'll have to get all IRC clients in Debian to switch that off, which I think is unlikely to happen. Additionally, many of us don't log "just" Debian channels; instead, they log all their channels. For me, that includes stuff like a few upstreams who do lots of stuff on IRC, and FOSDEM channels. Creating a Debian IRC logging service will not make those go away. Since it's easier to enable logging as a global switch in many clients (indeed, I wouldn't be surprised to learn that in most cases it's the only option), people will still want to log Debian channels. And that's even ignoring the fact that "leaking things from IRC" is not, in my opinion, a viable threat that we should protect against. Although I don't agree with it, I can understand the argument "we might want to have a public IRC logging service to make things easier for people". I do not, however, buy the argument "we need a central IRC logging service for security". It makes no sense. -- < ron> I mean, the main *practical* problem with C++, is there's like a dozen people in the world who think they really understand all of its rules, and pretty much all of them are just lying to themselves too. -- #debian-devel, OFTC, 2016-02-12
Re: DPL Voting period
On Sun, Apr 09, 2017 at 12:01:42PM -0700, Steve Langasek wrote: > On Sun, Apr 09, 2017 at 08:25:06PM +0200, Kurt Roeckx wrote: > > It was always my understanding that this was the case, and as far > > as I know people have always stopped discussing after the > > campaigning was over. > > I think this is largely true, but it is not written into the constitution. > People's attitudes towards continued discussion on debian-vote during the > voting period are probably heavily influenced by their local laws about > campaign blackouts before elections in meatspace. I think that is rather irrelevant. It has been a longstranding tradition in Debian that we stop campaigning once the vote is running. While we can obviously always change that tradition, it feels wrong to just go ahead and do it without any prior discussion about the subject. > While discussion on debian-vote usually wraps up once voting starts, I don't > believe there's anything to be enforced here by the Secretary. To be fair, Kurt mailed in his personal name, he didn't use a secretary@ mail address or try to wear his secretary hat in any other way. -- < ron> I mean, the main *practical* problem with C++, is there's like a dozen people in the world who think they really understand all of its rules, and pretty much all of them are just lying to themselves too. -- #debian-devel, OFTC, 2016-02-12
Re: having public irc logs?
On Thu, Apr 06, 2017 at 08:44:20AM +, Gianfranco Costamagna wrote: > Hello Mehdi and Chris, > > > > Debian has a "we don't hide things" wording in his constitution. > > However we don't have a public irc log system, and most > > of the conversations between us are happening there. > > How do you relate to that issue? Do you see it as a problem, > > or do you think people should join irc to read our conversations? > > (channels protected by a passphrase are of course out of this question). Please no. Most of our IRC channels are public, and that's how it should be. However, there's a difference between "anyone can join and follow the conversation now", and "anyone can read me being in a bad mood and saying things I'll regret later for all eternity". For one thing, if you see me being in a bad mood and ranting aloud, you might want to ask what's going on, and I could realize that I'm misbehaving (as per our CoC). Not so with public IRC logs. We do have meetbot, whichi is useful for meetings. Some of us (me included) do keep their IRC client running "always"[1], and keep private logs pretty much forever. I have been known to sometimes quote from that IRC log publicly[2]. There is a world of difference between doing that and making *all* our IRC conversations public, however. Transparency is a good thing, but so is privacy. [1] Servers do get rebooted, and sometimes you forget to restart the clint. That's a detail, obviously. [2] See my .sig ;-) -- < ron> I mean, the main *practical* problem with C++, is there's like a dozen people in the world who think they really understand all of its rules, and pretty much all of them are just lying to themselves too. -- #debian-devel, OFTC, 2016-02-12
Re: Proposed GR: Repeal the 2005 vote for declassification of the debian-private mailing list
On Fri, Sep 16, 2016 at 08:27:13AM +, Anthony Towns wrote: > To me, Debian at it's best is kind of an extremist leader in > organisational transparency: You may be seeing things that I don't see. > - we released all our source code for everything before 'open source' >was even invented Free software was invented, though. > - we've had a completely open bug tracking system since the '90s Yes, true. > - we do almost everything on public mailing lists or public irc channels We also do a lot of things in hallway tracks or non-recorded rooms on debconf, in unrecorded sprints, or in private (as in, developer-to-developer) emails. > - when we make decisions by voting, we do it in public and make the tally >available and publicly auditable That's just a matter of protecting the democratic process, and has less to do with transparency as such. > - our technical committee operates completely in the open (and is >required to do so!) Actually, they're only required to vote (etc) in the open. There is a debian-ctte-private, and we have reason to suspect it is currently being used[1]. > - we encourage everyone interested/involved to come to our conferences True, but not as much as we encourage people who actually contribute to Debian to do so. > I'm sure there are more; I kinda want to claim meetbot, but apparently > that one was Ubuntu's. Pretty much all those things are or were hard > and people will give you plenty of reasons why you'd be crazy to do any > of them. I'm not sure that "pretty much all" those things were ever really hard. Releasing source code? Not much more so than releasing binaries. Public mailinglists? Private mailinglists are actually harder to do. Public IRC channels? same Everything else is just a matter of "we do it on a mailinglist", so that means we fall back on the "public mailinglist" bit. Am I missing something that you see but I don't? [1] https://lists.debian.org/debian-ctte/2016/09/msg1.html > > "[...] We promise (and have all > > members as testimonials) to restrict it's usage to topics that really need > > to > > be private" > > I don't think we could honestly make that promise (and thus I wouldn't > give a testimonial to it); it certainly hasn't been true in the past, > and (at least, aside from manual moderation of every mail) I don't think > there's any mechanism that would make it so. And "really needs to be > private" is a judgement call on which people will naturally differ, > in any event. Indeed. -- < ron> I mean, the main *practical* problem with C++, is there's like a dozen people in the world who think they really understand all of its rules, and pretty much all of them are just lying to themselves too. -- #debian-devel, OFTC, 2016-02-12
Re: Proposed GR: Repeal the 2005 vote for declassification of the debian-private mailing list
On Wed, Sep 21, 2016 at 03:27:19PM +, Anthony Towns wrote: > When I joined Debian I endorsed the social contract [0] which said > "we won't hide problems". "we won't hide problems" is not the same thing as "we'll put all our garbage out in the open"... -- < ron> I mean, the main *practical* problem with C++, is there's like a dozen people in the world who think they really understand all of its rules, and pretty much all of them are just lying to themselves too. -- #debian-devel, OFTC, 2016-02-12
Re: GR Proposal: replace "Chairman" with "Chair" throughout the Debian Constitution
Hi Marga, I second this amendment, although it introduces a minor awkwardness: On Fri, Jul 08, 2016 at 03:27:56PM +0200, Margarita Manterola wrote: > - The Technical Committee and/or its Chairman; > + The Technical Committee and/or its Chair; A "Chairman" is a person. A "Chair" may be an object. I don't think anyone will misinterpret your proposed new wording into thinking the TC has a physical chair that someone sits on, but the s/Chairmain/Chair/ you apply does to me seem to introduce some grammatical ambiguity that could make the text of the constitution less clear than it might be. Since I'm not a native English speaker, I'll assume for now that it's just me and that there's no problem; but if other people do feel the same way about this, perhaps now's the right time to do something about it? Once this GR passes, it's going to be hard to fix that... Regards, -- < ron> I mean, the main *practical* problem with C++, is there's like a dozen people in the world who think they really understand all of its rules, and pretty much all of them are just lying to themselves too. -- #debian-devel, OFTC, 2016-02-12 signature.asc Description: PGP signature
Re: GR: Constitutional Amendment to fix an off-by-one error and duplicate section numbering
On Fri, Sep 25, 2015 at 05:51:45PM +0100, Ian Jackson wrote:
> Wouter Verhelst writes ("Re: GR: Constitutional Amendment to fix an
> off-by-one error and duplicate section numbering"):
> > Having given this some more thought, I believe I've come to understand
> > why you don't see this to be such a crazy idea as I believe it is.
>
> > This works for votes where the electorate (either the TC or all DD's for
> > a GR) wish to overrule some other developer's opinion. If the overruling
> > vote wins and makes supermajority, then the other developer in question
> > has been overruled. If the overruling vote wins but does *not* make
> > supermajority, we in effect ask the other developer in question to
> > either "please" or "pretty please, with sugar on top" (depending on
> > whether the TC or the project as a whole voted) change things, without
> > requiring said change.
>
> Exactly.
>
> > Things become rather murky, however, when we're voting on a change to
> > the constitution or a Foundation Document, which also requires a 3:1
> > supermajority.
> >
> > If a vote to make a change the constitution wins, but does not make its
> > required supermajority, then what? Did we just add a paragraph "we think
> > this is a good idea, but you're not required to follow this bit of
> > procedure" to the constitution? That seems pointless, and would probably
> > make the constitution very hard to read if it happens a lot.
>
> Which is why in those cases my proposal does not do that.
Yes it does.
> > Do we throw said change away? We probably can't, because it's still a
> > non-binding resolution, or something.
>
> In these cases, my proposal produces `FD'.
It does not.
> > Put otherwise, the idea of a "non-binding change to the constitution"
> > seems to make no sense.
>
> I entirely agree.
Good.
> > In other words, while I understand where you're coming from and why you
> > believe this change is desirable, I think it does have some dangerous
> > side effects that you may not have considered. I therefore strongly urge
> > you (and everyeone who's seconded the original proposal) to reconsider,
> > and decide whether you really believe the above-described scenario is in
> > any way desirable, and I further urge you to come up with a solution to
> > that problem before this is brought to a vote.
>
> I think if you read my proposal again you will see that it doesn't
> have the bad effect you identify.
If you're referring to the casting vote exception in the proposal, you
urgently need to reread §5.1.7 of the constitution: the DPL has a
casting vote for GRs!
--
It is easy to love a country that is famous for chocolate and beer
-- Barack Obama, speaking in Brussels, Belgium, 2014-03-26
Re: GR: Constitutional Amendment to fix an off-by-one error and duplicate section numbering
On Sat, Sep 26, 2015 at 12:41:39PM +0200, Wouter Verhelst wrote: > If you're referring to the casting vote exception in the proposal, you > urgently need to reread §5.1.7 of the constitution: the DPL has a > casting vote for GRs! Actually, you were referring to sections (iv) and (v) of the proposal. That does move the proposal from what I consider to be "coo coo crazy" to "a terribly bad idea". If an option 1 did not reach its supermajority requirements, but an option 2 would win under the current rules, then due to condorcet under your proposed scheme and due to the fact that we just spent over a month to come to no result it is extremely likely that a next vote is going to produce the same result, unless something major changes between the two votes. In other words, you'd condemn us to perpetual further "discussion". If option 1 did not make supermajority by a wide margin, it is possible that its supporters will decide it's not worth getting it on the ballot anymore, thereby resulting in option 2 being the most likely winner, in the absense of strategic voting. But we actually do have a previous vote outcome, so people who did not vote strategically in the previous round due to lack of data now no longer have such a restriction. Rather than eliminating strategic voting (as you claim you're doing), you're actually encouraging it. As said, I think this is a terrible idea. -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 signature.asc Description: PGP signature
Re: GR: Constitutional Amendment to fix an off-by-one error and duplicate section numbering
Hi Ian,
Having given this some more thought, I believe I've come to understand
why you don't see this to be such a crazy idea as I believe it is.
On Tue, Sep 01, 2015 at 12:20:05PM +0100, Ian Jackson wrote:
> Kurt Roeckx writes ("Re: GR: Constitutional Amendment to fix an off-by-one
> error and duplicate section numbering"):
> > So I understand that if there is no winner, and so maybe not
> > even a normal majority (that doesn't even exist anymore?) for it,
> > it becomes a statement of opinion?
>
> No. I'm not even sure what that paragraph of yours means. (If there
> is no winner, how could "it" become a statement of opinion ? What
> would "it" be ?) As for `normal' majorities, that is already dealt
> with by Condorcet. Something that most people disagree with cannot
> become the Condorcet winner because it will be defeated by FD/SQ.
>
> The intent of this change is that if the Condorcet(CSSD) winner does
> not meet the supermajority requirement, it is still the winning
> outcome of the whole vote, but only as a non-binding statement of
> opinion.
This works for votes where the electorate (either the TC or all DD's for
a GR) wish to overrule some other developer's opinion. If the overruling
vote wins and makes supermajority, then the other developer in question
has been overruled. If the overruling vote wins but does *not* make
supermajority, we in effect ask the other developer in question to
either "please" or "pretty please, with sugar on top" (depending on
whether the TC or the project as a whole voted) change things, without
requiring said change.
Things become rather murky, however, when we're voting on a change to
the constitution or a Foundation Document, which also requires a 3:1
supermajority.
If a vote to make a change the constitution wins, but does not make its
required supermajority, then what? Did we just add a paragraph "we think
this is a good idea, but you're not required to follow this bit of
procedure" to the constitution? That seems pointless, and would probably
make the constitution very hard to read if it happens a lot.
Do we throw said change away? We probably can't, because it's still a
non-binding resolution, or something.
If the non-winning change to the constitution just adds a few things
that aren't contradicted by the old constitution, then we could probably
get away with adding an awkward paragraph. If it wanted to change
existing procedure, however, then we effectively have to throw it away
anyway, because it can't even be there as a statement of opinion, other
than one which says "we think this is good, but you can't do it because
the constitution says it's not good", and that seems like an even worse
idea.
Put otherwise, the idea of a "non-binding change to the constitution"
seems to make no sense.
This is a problem, too.
Let's assume the desire to change the constitution is due to a crisis in
the project. Such GR's tend to have several options on the ballot,
rather than just one. Let's further assume that the change to the
constitution would resolve the crisis, as would several other options,
but that "not doing anything" would not, as I believe is most likely in
such cases.
If the condorcet winner doesn't make supermajority, it would not resolve
the situation (and might in fact make matters worse). In such cases,
under the current rules, another option would win, which presumably
would resolve the crisis as well.
In other words, while I understand where you're coming from and why you
believe this change is desirable, I think it does have some dangerous
side effects that you may not have considered. I therefore strongly urge
you (and everyeone who's seconded the original proposal) to reconsider,
and decide whether you really believe the above-described scenario is in
any way desirable, and I further urge you to come up with a solution to
that problem before this is brought to a vote.
Thanks,
--
It is easy to love a country that is famous for chocolate and beer
-- Barack Obama, speaking in Brussels, Belgium, 2014-03-26
signature.asc
Description: PGP signature
Re: Restated Amendment: We Choose Wording of the Day
Hi Kurt, On Wed, Sep 09, 2015 at 12:34:15PM +0200, Kurt Roeckx wrote: > On Wed, Sep 09, 2015 at 08:49:03AM +0100, Philip Hands wrote: > > I second the below amendment. > > I think that makes 5 second now, so I'll update the page with it > later. It's now over a week since that mail, and the vote.debian.org page still doesn't list that amendment (it also incorrectly lists this GR under "Decided"). Ping? -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 signature.asc Description: Digital signature
Re: Restated Amendment: We Choose Wording of the Day
Hi Sam, On Fri, Sep 04, 2015 at 02:28:20PM +, Sam Hartman wrote: >- GENERAL RESOLUTION STARTS - > > >Constitutional Amendment: TC Supermajority Fix > >Prior to the Clone Proof SSD GR in June 2003, the Technical >Committee could overrule a Developer with a supermajority of 3:1. > >Unfortunately, the definition of supermajorities in the SSD GR has a >off-by-one error. In the new text a supermajority requirement is met >only if the ratio of votes in favour to votes against is strictly >greater than the supermajority ratio. > >In the context of the Technical Committee voting to overrule a >developer that means that it takes 4 votes to overcome a single >dissenter. And with a maximum committee size of 8, previously two >dissenters could be outvoted by all 6 remaining members; now that >is no longer possible. > >This change was unintentional, was contrary to the original intent >of the Constitution, and is unhelpful. > >For the avoidance of any doubt, this change does not affect any >votes (whether General Resolutions or votes in the Technical >Committee) in progress at the time the change is made. > >Therefore, amend the Debian Constitution as follows: > > Index: doc/constitution.wml > === > --- doc/constitution.wml (revision 10982) > +++ doc/constitution.wml (working copy) > @@ -913,7 +913,7 @@ > > >An option A defeats the default option D by a majority > - ratio N, if V(A,D) is strictly greater than N * V(D,A). > + ratio N, if V(A,D) is greater or equal to N * V(D,A) and > V(A,D) is strictly greater than V(D,A). > > >If a supermajority of S:1 is required for A, its majority > ratio > > > > > > >Constitutional Amendment: Fix duplicate section numbering. > >The current Debian Constitution has two sections numbered A.1. >This does not currently give rise to any ambiguity but it is >undesirable. > >Fix this with the following semantically neutral amendment: > > - Renumber the first section A.1 to A.0. > > >- GENERAL RESOLUTION ENDS - I second this amendment. However, as I've said in <20150903164145.gb23...@grep.be>, I think the better fix is to update 6.1.4 as follows: -4. Overrule a Developer (requires a 3:1 majority) +4. Overrule a Developer (requires a 2:1 majority) This way, the off-by-one change that was introduced with CSSD is reverted *for the TC*, while the supermajority definition isn't. I say "change", because I don't buy the argument that it's a "bug"; I think the removal of the "X + one" requirement would be a bug. However, I do accept that requiring 3 + 1 votes in favour per opposing vote is problematic for the TC, so I do agree that reducing the required number of votes is desirable. The above does that. To clarify, I've always interpreted a "majority" to mean "One vote more than X over Y". This definition is easily proven correct when one considers a simple majority: to get a simple majority, strictly more than 50% of the vote is required (otherwise you don't have a majority, you have an equilibrium). While the constitution doesn't specifically refer to 1:1 simple majorities (it doesn't need to, since a result that doesn't manage to reach simple majority wouldn't be the condorcet winner), I think it would be inconsistent and wrong for us to change the constitution in this manner. If that argument manages to convince you, I would appreciate it if you could update your proposal in that manner. Having said that, I don't feel strongly enough about it to make this a formal amendment; while I think the change would be undesirable for regular GRs, I doubt it would make much difference in practice, so I'm not going to pursue this unless someone pokes me. Regards, -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 signature.asc Description: Digital signature
Re: GR: Constitutional Amendment to fix an off-by-one error and duplicate section numbering
Hi Ian, On Tue, Sep 01, 2015 at 12:20:05PM +0100, Ian Jackson wrote: > The intent of this change is that if the Condorcet(CSSD) winner does > not meet the supermajority requirement, it is still the winning > outcome of the whole vote, but only as a non-binding statement of > opinion. > > So for example, suppose in a TC vote we have: > > A "we overrule the maintainer [6.1(4)]: this patch to comply with > policy must must be applied" > > B "we set policy [6.1(1)]: the policy is wrong and must be changed" > > and votes are 5x A,B,FD 2x B,FD,A I interpret that as: 5x "I think we should overrule the maintainer; but if we don't, then at least updating policy to match reality is an acceptable compromise". 2x "We should update policy; overruling the maintainer is the worst possible outcome, and I'd rather do nothing than see that happen". > The overall Condorcet winneer is A but only by a 5:2 majority, so the > TC does not overrule. Right. > With the existing rules A is eliminated early, leaving B the Condorcet > winner. This is a bizarre outcome: the winning option was disfavoured > by 5/7ths of the TC ! However, on the other hand, it is the *only* outcome (in your example) of which all voters agree that it would a preferable outcome to that of restarting the whole process. That is also an important outcome of that vote; it is, to all involved, an acceptable compromise position. > With the new scheme, A is the Condorcet winner (the `prospective > winner' in the wording proposed in the GR text). But it fails its > supermajority. > > So `prospective winning resolution text becomes a non-binding > statement of opinion'. Ie, the TC is treated as having said: > > A' "we advise [6.1(5)]: we disagree with the maintainer; this patch > to comply with policy should be applied" > > This makes a lot more sense as an outcome. If the maintainer has previously said that he thinks A is the worst possible option and *all* of the TC agrees that updating policy to match reality is, at least, an acceptable compromise (as in this example), then option A will most likely result in "nothing happens" (i.e., "further discussion"), whereas option B would have produced a (suboptimal) resolution. > The maintainer can continue to diregard the disputed policy, because > the TC hasn't mustered the certainty needed to overrule the > maintainer; but, the policy is not altered. I'm not sure why "accepting the compromise position as the winner" is in any way an undesirable outcome to you. In effect, having a non-binding "winner" outcome is hardly different from having "further discussion" discussion win the vote (precisely because it's not binding). In your example, *all* voters have said that they prefer B over FD. I fail to see how your suggested scheme is an improvement. -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 signature.asc Description: Digital signature
Re: Strategic Voting Re: General resolution: Changes to the Standard Resolution Procedure
On Thu, Sep 03, 2015 at 02:43:04PM +, Sam Hartman wrote: > In conclusion, endless discussion is not a win. And I think this > strategic voting fix may bring us there. If I were to put together an > amendment that fixed the strictly greater issue but did not tackle the > strategic voting issue, would people second? Absolutely. Let's not fix issues unless they exist. I don't think the "strategic voting" issue exists in Debian, and so I don't think we should try to "fix" it. I accept that the off-by-one "error" exists for the TC, although I think the easier fix is to require a 2:1 supermajority for cases where the TC currently requires a 3:1 supermajority; this would again reduce the required number of votes to be more in line with what is indeed a more workable number for the TC, while not changing the semantics for regular GRs. -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 signature.asc Description: Digital signature
Re: [DRAFT #3] Maximum term for tech ctte members
On Mon, Nov 24, 2014 at 04:53:10PM +0100, Stefano Zacchiroli wrote: An exception to the uniformity of the effects of transitional measures is max. I haven't touched it partly because it doesn't seem to have received much attention as of lately, and partly because it seems to actually have as a goal that of quickly converging to the desired term limit. That's not my perception. Out of all the proposals, I prefer max because it is elegant and simple; the other proposals involve slightly more complex formulas that require more effort to understand. I don't think max has such a goal of quickly converging (at least it's not what I like about it). As such, I would appreciate it if you could change that option to, say, postpone the first term expiration to 6 months after the passing of the GR, rather than one month. If you don't do that, I'll have to propose it myself, but I'd rather avoid that ;-) -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141128083657.gb25...@grep.be
Re: [DRAFT] Maximum term for tech ctte members
On Sun, Nov 23, 2014 at 02:43:46PM +0100, Stefano Zacchiroli wrote: On Sat, Nov 22, 2014 at 03:46:49PM +, Philip Hands wrote: I think since this is a tie-breaker situation which will presumably rarely happen, it doesn't really matter much. How about: I don't think this is a problem that is worth solving with extra complexity in the text of the Constitution. If a tie ever happens, I think we can count on the responsibility of the involved CTTE members to agree between them on who should step down; and possibly on the fact that they will all resign. I would hope that to be possible, too, yes, but I wouldn't gamble the stability of one of our most core institutions on having to change the constitution to fix an issue when people are fighting over it on the street... But I bite. I don't think it is a good idea to tie the tie breaking rule to specific technology (the email message used for the appointment, IDs in the Debian user database, etc). If people really want to add a tie breaking rule, the most straightforward one is specifying that *the DPL* will break any tie. That's probably the best option. It would also seriously reduce the amount of extra complexity for a tie breaking rule. I would feel more comfortable if it were explicitly mentioned, though. If a problem ever occurred due to this, technically the DPL could claim urgent action and do it under 5.1.3, but I would find that reasoning strained. After all, the constitution gives the DPL the power to *assign* someone to the committee, but not to remove someone; that is far from the same thing. -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141124085041.ga29...@grep.be
Re: [DRAFT] Maximum term for tech ctte members
On Sat, Nov 22, 2014 at 03:46:49PM +, Philip Hands wrote: Philip Hands p...@hands.com writes: Wouter Verhelst wou...@debian.org writes: On Tue, Nov 18, 2014 at 11:33:10AM +0100, Stefano Zacchiroli wrote: [...] 2. A member of the Technical Committee is said to be more senior than another if they were appointed earlier, or were appointed at the same time and have been a member of the Debian Project longer. In the event that a member has been appointed more than once, only the most recent appointment is relevant. I think it makes more sense to have someone who was previously a member of the TC have more seniority, before age within the project: I think since this is a tie-breaker situation which will presumably rarely happen, it doesn't really matter much. How about: For the purpose of determining seniority, simultaneous appointments are deemed to have taken place in the order of names in the mail that announced their appointment. The TC can then decide how they're going to do the ordering at appointment time, and that's then clear to all -- no need to come up with lots of words that might still not give a distinct result. That would work too, I suppose. -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141123120453.ga24...@grep.be
Re: [DRAFT] Maximum term for tech ctte members
On Tue, Nov 18, 2014 at 11:33:10AM +0100, Stefano Zacchiroli wrote: [...] 2. A member of the Technical Committee is said to be more senior than another if they were appointed earlier, or were appointed at the same time and have been a member of the Debian Project longer. In the event that a member has been appointed more than once, only the most recent appointment is relevant. I think it makes more sense to have someone who was previously a member of the TC have more seniority, before age within the project: A member of the Technical Committee is said to be more senior than another if they were appointed earlier. In the case where two members of the Committee were appointed at the same time, then total time served on the Committee (including previous appointments in the event of a member being appointed more than once) and membership time in the Debian Project as a whole will be considered, in that order. Other than that, looks good. -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141122085144.gb8...@grep.be
Re: Re: [DRAFT] Maximum term for tech ctte members
On Tue, Nov 18, 2014 at 02:44:42PM +0100, Svante Signell wrote: Hi, 6.2. Composition 1. The Technical Committee consists of up to 8 Developers, and should usually have at least 4 members. 2. When there are fewer than 8 members the Technical Committee may recommend new member(s) to the Project Leader, who may choose (individually) to appoint them or not. 3. When there are 5 members or fewer the Technical Committee may appoint new member(s) until the number of members reaches 6. 4. When there have been 5 members or fewer for at least one week the Project Leader may appoint new member(s) until the number of members reaches 6, at intervals of at least one week per appointment. Why not avoid the casting vote problem by stipulating that the number of members should always be an odd number. The problem with that is that if an odd number of members recuse themselves because they feel that they are involved somehow and wouldn't be able to vote fairly, you again have an even number. -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141122085431.gc8...@grep.be
Re: [DRAFT] Maximum term for tech ctte members
On Sat, Nov 22, 2014 at 10:34:25AM +0100, Stefano Zacchiroli wrote: On Sat, Nov 22, 2014 at 09:51:44AM +0100, Wouter Verhelst wrote: On Tue, Nov 18, 2014 at 11:33:10AM +0100, Stefano Zacchiroli wrote: 2. A member of the Technical Committee is said to be more senior than another if they were appointed earlier, or were appointed at the same time and have been a member of the Debian Project longer. In the event that a member has been appointed more than once, only the most recent appointment is relevant. I think it makes more sense to have someone who was previously a member of the TC have more seniority, before age within the project: A member of the Technical Committee is said to be more senior than another if they were appointed earlier. In the case where two members of the Committee were appointed at the same time, then total time served on the Committee (including previous appointments in the event of a member being appointed more than once) and membership time in the Debian Project as a whole will be considered, in that order. Considering the likelihood of a situation in which the two alternative approach lead to different results, is it worth an increase from 60 words to 77 (including a parenthetical)? I'm not so sure this is very unlikely. First of all, the DAM tends to approve NM applications in batch; sometimes in a large batch. As a result, most people in the Project are a member of Debian for the same amount of time, to the day. Due to the birthday paradox and the higher rate of rotation of people serving on the TC as a result of this change, a situation where two people are in Debian for the same amount of time ar both concurrently serving on the TC is likely to occur at some point. Second, a proposal to review two TC members at the same time will make it likely that the replacement members are appointed at the same time, too. If an odd number of people then resigns from the TC, you will at some point have the situation where the least senior of the two most senior people shares an appointment date with someone else. If the originally-resigning people did not serve on the TC for very long prior to their resignation, this situation may persist for a few years, increasing the likelihood of the next item on the list of things considered to determine seniority comes into play. If the goal of this proposal is to increase the amount of fresh ideas in the TC, then the difference between A person having been in Debian for 15 years of which 8 as a member of the TC and A person having been in Debian for 15 years of which 4 as a member of the TC should be in favour of the latter. I do agree that the wording is suboptimal and could use some improvement, though. -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141122121935.gi8...@grep.be
Re: Alternative proposal: support for alternative init systems is desirable but not mandatory
On Fri, Oct 17, 2014 at 09:44:16AM +0200, Lucas Nussbaum wrote: Hi, It is now clear that we will have a vote on this issue. I think that we should use this opportunity to clarify the Project's position, and that's not something that would be achieved if Further Discussion were to win. I am therefore bringing forward an alternative proposal, deeply inspired from the Advice: sysvinit compatibility in jessie and multiple init support option of the TC resolution on init system coupling[1], which was originally written by Russ Allbery[2] and was then amended by many participants to the discussion in February 2014. [1] https://lists.debian.org/debian-ctte/2014/02/msg00575.html [2] https://lists.debian.org/debian-ctte/2014/02/msg00447.html - begin proposal -8 Debian has decided (via the technical committee) to change its default init system for the next release. The technical committee decided not to decide about the question of coupling i.e. whether other packages in Debian may depend on a particular init system. However, the technical committee stated in #746715 that [it] expects maintainers to continue to support the multiple available init systems in Debian. That includes merging reasonable contributions, and not reverting existing support without a compelling reason. The Debian Project states that: Software should support as many architectures as reasonably possible, and it should normally support the default init system on all architectures for which it is built. There are some exceptional cases where lack of support for the default init system may be appropriate, such as alternative init system implementations, special-use packages such as managers for non-default init systems, and cooperating groups of packages intended for use with non-default init systems. However, package maintainers should be aware that a requirement for a non-default init system will mean the software will be unusable for most Debian users and should normally be avoided. Package maintainers are strongly encouraged to merge any contributions for support of any init system, and to add that support themselves if they're willing and capable of doing so. In particular, package maintainers should put a high priority on merging changes to support any init system which is the default on one of Debian's non-Linux ports. For the jessie release, all software that currently supports being run under sysvinit should continue to support sysvinit unless there is no technically feasible way to do so. Reasonable changes to preserve or improve sysvinit support should be accepted through the jessie release. There may be some loss of functionality under sysvinit if that loss is considered acceptable by the package maintainer and the package is still basically functional, but Debian's standard I would like to see the above clause modified like this: There may be some loss of functionality under sysvinit if the package is still basically functional. Rationale: I don't think that the maintainer believes the loss of functionality is acceptable is a good test for whether the cost is worth the benefit. Rather, that test should be about how hard is it for a maintainer to support the alternative init system. If a maintainer thinks that, say, a power manager written to read /sys/power directly but control things through systemd is useless without the ability to suspend the system, they might well remove all support for non-systemd systems; if someone else believes otherwise and sends in a patch, under the proposed language the maintainer would be able to reject such patches. As such, in the spirit of §2.1.1 of the consitution, I would therefore like to see something along the lines of in the absense of patches, it's okay for a maintainer to remove support for non-default init systems if they have no desire to maintain that support themselves, but maintainers should not reject patches implementing such support without a sound technical reason. This will allow Debian to support non-default init systems if someone steps forward and does the work, but should not stand in the way of people who just don't care and don't want to see their work doubled (or tripled, or quadrupled, or ...) by alternative init systems. requirement to support smooth upgrades from wheezy to jessie still applies, even when the system is booted with sysvinit. The Debian Project makes no statement at this time on sysvinit support beyond the jessie release. This resolution is a Position Statement about Issues of the Day (Constitution 4.1.5), triggering the General Resolution override clause in the TC's resolution of the 11th of February. The TC's decision on the default init system for Linux in jessie stands undisturbed. However, the TC resolution is altered to add the additional
call for votes on code of conduct GR
Hi, I'd like to call for votes on the code of conduct GR. Thanks, -- It is easy to love a country that is famous for chocolate and beer -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26 signature.asc Description: Digital signature
Re: The Code of Conduct needs specifics
On Mon, Mar 24, 2014 at 08:47:43AM +0100, Raphael Hertzog wrote: Hi Solveig, On Mon, 24 Mar 2014, Solveig wrote: I can write specific amendments, if somebody is willing to sponsor them :) Please do. I tend to agree with what Steve said. It doesn't hurt to have a list of don't Actually it does. The danger of having a list of do nots is that people will do something which is not on the list, and then point to it and say see, it's allowed by the code of conduct when pointed out that they're being a dick. The proposed code of conduct is not meant to be a law text; it is not meant to be all-encompassing. It is meant to show people what the right way to move forward is, and it tries to do so in a positive sense. This is after some discussion at debconf; my initial draft was phrased much more negatively. The point is that we're aiming this towards the contributors that we want to keep (to prevent them from straying from the path, or from unknowingly misbehaving), not towards those that we don't want on our mailinglists. Debian's listmasters already kick people off our mailinglists if they misbehave, with or without this code of conduct. I think that's a good thing, and we should keep that; in fact, the proposed text explicitly empowers them to continue doing so. It is not very detailed on the specifics, but that's a feature, not a bug. In addition, a list of do nots will make people assume that the project is in a worse state than it actually is. To paraphrase one participant of the CoC BoF during debconf, when the draft CoC was still somewhat negative: I get the feeling, if I read this code of conduct, that Debian is a very problematic community with lots of problems. I don't want our code of conduct to produce that feeling. Instead, the goal of my proposed CoC is that medium administrators (listmasters, IRC ops, ...) will interprete and enforce it within their own interpretation, and that people who misbehave will simply be removed from our lists (after due warnings, and with full review from the rest of the project, but without a big and complicated procedure and/or many avenues for trolls to use up the project's limited resources through appeal procedures). -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ signature.asc Description: Digital signature
Re: The Code of Conduct needs specifics
Hi Solveig, [I didn't have a lot of time this morning, so I could only fire off a quick mail down the thread. This mail does deserve a more in-depth answer, however, so here goes] On Mon, Mar 24, 2014 at 02:31:54AM +, Solveig wrote: [...] I think if you do something, do it right. Lots of feminists, who work on these questions since years, collectively, and are concerned by the problem, have documented not only *why* have a CoC, but also *how* - not following their advice is silly and wrong. https://en.wikipedia.org/wiki/Not_invented_here I'm sorry, but that characterisation is wrong. I did not pull the proposed Code of Conduct out of thin air; while I did write the text from scratch, I have looked at, and drawn inspriation from, a number of CoCs before drafting it. This included the codes from Ubuntu, KDE, and GNOME, to name a few, but there were more (I don't recall all of them, but I mention a few more in the video of the bof at debconf). I don't think it's fair to call it not invented here when most of my inspiration comes from other, existing, codes of conduct. So, what's their advice, and what's missing? Please read the whole of these pages: http://adainitiative.org/2014/02/howto-design-a-code-of-conduct-for-your-community/ I have read that, and I disagree with it, as I've explained in 20140321094129.ga24...@grep.be (and elsewhere in this thread). http://geekfeminism.wikia.com/wiki/Code_of_conduct That doesn't have much content beyond a table of codes of conduct of several communities, and a note for each on how well they do on the three points you list below. Out of fourteen in that table, one (the Django CoC) scores yes on all three, one (the Rust CoC) scores yes on two out of the three, and one (the Drupal one) scores one yes. Everything else is a no or a Some. You're not going to convince me that what you propose is the best way to do something when, according to your own argument, almost everyone else does it differently. 1 * List specific common behaviors that are not okay 2 * Include detailed directions for reporting violations 3 * Have a defined and documented complaint handling process The proposed CoC doesn't list specific behaviours, That's correct, since I'm not convinced that such a list is useful (quite the contrary, in fact) has no clear way to report violations and there is no sanction planned (or no way to have it happen). This thing only says be nice (or don't be a dick). This is not correct. There is a whole section in case of problems dedicated to what to do when things don't go the way we want them to. Your suggestion of a conduct@ address does have some merit, and I'd be inclined to agree that something like that could be a good thing to include. Beyond that, I don't think the code of conduct needs to be specific on what will happen when someone goes astray; those are procedures that do not belong in a CoC. http://knowyourmeme.com/memes/wheatons-law Saying be nice? Cute, but doesn't work, and it even helps harassers going away with stuff. My proposed code of conduct is not an anti-harassment policy, nor does it try to be. Rather than enumerating badness[1], it tries to point out the kind of behaviour that we want to see in our community. Rather than telling people You're welcome to do anything on our communication media, as long as it's not one of long list, it tries to empower people through being positive, which I believe (as did several people during the BoF with me) is a better way to convince people of the merits of a CoC. For the avoidance of doubt: that's not to say I think harassment is okay (it is not), nor that an anti-harassment policy is necessarily wrong (it may be a good idea to pursue this, although I don't think I'm the right person to do so). But the goal of a code of conduct, in my eyes, should not be to discourage bad behaviour; instead, a code of conduct should encourage good behaviour. A list of don'ts doesn't do that; worse, it may actively detract from dos in the same document. [1] http://www.ranum.com/security/computer_security/editorials/dumb/ [...] Since *lots* of people don't see what's bad with sexist jokes, or asking for body mensurations, or stalking you and publish your personal data, it does make sense to list what's inappropriate. It won't be complete, but if it catches 90% of bad behaviours, it's 90% we won't have to argue about. Also, with exemples, it's easier to see if a given situation is similar to those listed. Yes, but it makes it much harder for the 10% when it isn't. To quote from your example: it's easy to say that stalking, or sexist jokes, or publishing personal data, is not being respectful towards other people. If someone behaves like that on our lists, it will be well within listmasters' prerogative to take action (as they already do today). However, if you add a list that contains the first two in this example but not the third, then suddenly the argument publishing personal
Re: The Code of Conduct needs specifics
On Mon, Mar 24, 2014 at 01:43:18PM +0100, enr...@enricozini.org wrote: [...] Solveig's email made me think of a different use case, though: telling those we want to keep, but who are new on our mailing list, what they can expect. Something along the lines of: Things like these are not supposed to happen to you. If they do, it's a bug, please report it to people. I think it's difficult to word that in a way which will not also have the negative consequences that I'm afraid of. You're welcome to try, of course ;-) If something happened that made you uncomfortable and you don't see it in this list and are unsure it's a bug, you can ask people in full confidentiality. This seems sensible, regardless of whether the CoC has a list. If we do indeed end up with a conduct@ address, I suppose that could be a good place to point people to in this context. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140324203147.ga31...@grep.be
Re: The Code of Conduct needs specifics
On Mon, Mar 24, 2014 at 06:09:25PM +, Mark Brown wrote: On Mon, Mar 24, 2014 at 09:25:37AM +0100, Wouter Verhelst wrote: In addition, a list of do nots will make people assume that the project is in a worse state than it actually is. To paraphrase one participant of the CoC BoF during debconf, when the draft CoC was still somewhat negative: I get the feeling, if I read this code of conduct, that Debian is a very problematic community with lots of problems. I don't want our code of conduct to produce that feeling. There's been a very strong and quite successful push recently to convince organisations to adopt codes of conduct so at this point the usual suggestion for people worrying about it being a sign of problems is to point people at the list of other organisations doing the same thing. There is indeed a large group of organisations having a code of conduct. However, the list of organizations with a code of conduct with such a list is short. So this argument doesn't really hold, IMO. The usual reasoning for explicitly enumerating things is the thing Solveig mentioned about people being (or professing to be) too inept to realise what appropriate behaviour is. Personally I do tend to share some of the concerns about rules lawyering and evasion with that but it's a reasonable view and I suspect you don't win either way. I could see how a separate document, with an explicit list of do nots, could usefully be linked from the further reading section. I think we should not make such a list authoritative. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140324203518.gb31...@grep.be
Re: The Code of Conduct needs specifics
On Mon, Mar 24, 2014 at 01:19:11PM -0700, Russ Allbery wrote: In general, I understand where Wouter is coming from, and the points that Steve made about inspiring people to behave better in public. However, this one paragraph really lept out at me. Wouter Verhelst wou...@debian.org writes: This Code of Conduct is afraid to scare away potential contributors; so a lot of effort has been put into making this a positive, welcoming Code of Conduct rather than a negative, scary one. I think this is a mistake. The experiences of other groups have mostly convinced me that the point of a Code of Conduct should be to scare away potential contributors who cannot or are unwilling to behave according to the standards that we expect of our community, and to reassure the people who would be injured by violations of those standards that we're serious about declaring those people unwelcome in our project. Not welcoming them and attempting to quietly encourage them to become better people (which doesn't work). Indeed. Perhaps I should clarify that, personally, I don't see someone who is prone to aggressive and abusive behaviour as a potential contributor in the above-quoted paragraph, and I don't think the project should, either. I think that people who have no respect for their peers, regardless of their technical abilities, should have no place in our community. [...] If you want a diverse and welcoming atmosphere, particularly for people who aren't interested in aggressive communication patterns or who are historically excluded, you have to not welcome the people who make the environment hostile and uncomfortable for the people you want to attract. This is absolutely true. However, I don't think you can do that through a code of conduct; people who are abusive and aggressive tend to have little consideration for other people's words. Instead, you should gear your *actions* (in this case bans, whether temporary or permanent in nature; law enforcement if thing get *really* serious) towards making the environment not welcome for such people. The proposed code tries to institutionalize and further encourage what is effectively already happening. Put otherwise, a code of conduct should be geared towards who will read and heed it, not towards who will blatantly violate it, even in the face of requests to stop doing so. It's not exactly a zero-sum game, but it is a choice. You can choose to attract one type of project participant or the other, but not both at the same time. I think the Code of Conduct presents an opportunity for us to be clear about what type of project participant we're interested in, and what type of project participant we're not interested in, and that we shouldn't be afraid to be a bit confrontational here. I think the current text does attempt to be clear about what we're interested in. Having a list of things that we want to see implies people can infer what we're not interested in, even if it's not explicit. I don't think being confrontational is very helpful in this kind of document. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ signature.asc Description: Digital signature
Re: what should the DFSG apply to?
On Sat, Mar 22, 2014 at 03:42:43PM +0800, Paul Wise wrote: I believe the DFSG should ensure equality of access to works in Debian. Thus it is my opinion that all items in the DFSG should apply to the contents of all source and binary packages in Debian main and that we should amend the DFSG to replace all uses of the words program and software with work. You mean you want to go through GR 2004_003 *again*? -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140323071213.ga26...@grep.be
Rationale for CoC proposal A
Hi list, I'm sorry to be doing this in the middle of campaigning, but this will come to a vote pretty soon, and I don't think I want to wait until it's too late. Candidates can ignore this (unless they want to comment, of course). I'd like to propose a rationale for option one on the ballot, if I may: Rationale: Allowing the DPL to update the Code of Conduct will make it easier to adapt it to changing circumstances, without having to go through a lengthy GR procedure. One of the roles of the DPL is to mediate in case of conflict; therefore, the DPL is in an ideal position to detect when an update to the code of conduct may be necessary. If the DPL were to go rogue and replace the Code of Conduct by a blank page (or similar), we already have sufficient procedures to recall or override the DPL. Thanks, -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ signature.asc Description: Digital signature
Re: what should the DFSG apply to?
On Sun, Mar 23, 2014 at 03:25:46PM +0800, Paul Wise wrote: On Sun, Mar 23, 2014 at 3:12 PM, Wouter Verhelst wrote: You mean you want to go through GR 2004_003 *again*? That GR passed and was about the SC, not the DFSG. Personally I think it was a mistake to not change the terminology used in the DFSG at the same time as changing the terminology in the SC. My point is that that GR was highly divisive, and had far-reaching repercussions beyond what the original proposers had expected. We have a consensus now that everything in Debian should be free, even those parts that some don't consider to be software. While some parts of the DFSG could be interpreted differently when viewed in isolation, as part of the Social Contract and with the context it is clear that this is not meant. If we put this to a vote again, I'm sure many of the old arguments will pop up again, resulting in a lot of heated words, which isn't very useful if you're not trying to change the intended meaning. I'd like to avoid that. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140323074052.gc26...@grep.be
Re: Rationale for CoC proposal A
On Sun, Mar 23, 2014 at 02:45:10AM -0500, Ean Schuessler wrote: What if the DPL begins to consider persistent disagreement with the DPL as a form of flaming? We can then override the DPL's decision, or recall the DPL. Also, there is a second option on the ballot. You don't have to agree with me... - Wouter Verhelst wou...@debian.org wrote: I'd like to propose a rationale for option one on the ballot, if I may: Rationale: Allowing the DPL to update the Code of Conduct will make it easier to adapt it to changing circumstances, without having to go through a lengthy GR procedure. One of the roles of the DPL is to mediate in case of conflict; therefore, the DPL is in an ideal position to detect when an update to the code of conduct may be necessary. If the DPL were to go rogue and replace the Code of Conduct by a blank page (or similar), we already have sufficient procedures to recall or override the DPL. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/16041386.67041395560710985.javamail.r...@newmail.brainfood.com -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140323075445.gd26...@grep.be
Re: GR proposal: code of conduct
On Wed, Mar 19, 2014 at 06:31:13PM -0700, Russ Allbery wrote: While it's probably too late in this process to change what we're going to vote on, I just ran across this today, and it may be of general interest in the context of codes of conduct. http://adainitiative.org/2014/02/howto-design-a-code-of-conduct-for-your-community/ So, I've read that, and I'm pretty much in disagreement with what they say. They advocate an approach of enumerating badness, which I don't think is a good idea. The main reason why it seems to do so is because the bad guys will otherwise start arguing with you about semantics. That may be a good way if there are a lot of avenues for the banned people to appeal their ban, but AIUI that just isn't the case in Debian. Someone who's banned from our mailinglists can complain to listmasters that the ban wasn't fair (and explain their case), or maybe appeal to the DPL if that didn't help, but that's about it. There is no hearing or anything of the sort, and since most bans are just for a few weeks anyway. More than that really isn't necessary IMO. As others have said, posting on our mailinglists is a privilege, not a right. If you abuse that privilege, we have the right to ban you from it, and there's no reason we should give abusers a lot of consideration. We should not ban for years on end by default, but then we're not doing that. As I'm sure you'll know, the downside of enumerating badness is that the enumeration will never be complete. Therefore, the suggested code of conduct deliberately tries to explain what you should do (in a positive sense), and is somewhat vague in what you shouldn't do, so as to leave room for reasonable interpretation. I think that's a far better approach than what's advocated in the above link. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ signature.asc Description: Digital signature
Re: Both DPL candidates: handling social conflict
On Thu, Mar 20, 2014 at 11:27:31PM +0100, Cyril Brulebois wrote: Sorry for the slight hijack but: | Date: Thu, 20 Mar 2014 19:29:19 +0100 | From: Neil McGovern n...@halon.org.uk | To: debian-vote@lists.debian.org | Subject: Re: Both DPL candidates: handling social conflict | X-Mailer: Apple Mail (2.1874) ^^^ Seriously? While I understand the question, I'm not sure this is very relevant. Yes, Debian is about promoting the cause of free software; and yes, actually *using* free software is a very good (first) way to promote its cause. However, Debian is not a cult. I do not believe we should require anyone in Debian to use free software and free software only for their private computer usage. This includes their mail client, even their mail client which they use for Debian. I sure hope I'm not alone in that belief. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ signature.asc Description: Digital signature
Re: GR proposal: code of conduct
On Mon, Mar 10, 2014 at 12:12:33AM +0100, Andreas Barth wrote: * Wouter Verhelst (wou...@debian.org) [140308 02:21]: So rather than accepting this amendment, I propose that we modify paragraph 3 read as follows, instead: --- 3. Updates to this code of conduct should follow the normal GR procedure. However, the DPL or the DPL's delegates can add or remove links to other documents in the Further reading section after consultation with the project and without requiring a GR. --- The idea here is that a DPL can add a link to something considered useful, while normal DD's can still add such a link through a GR if the DPL is opposed. How's that sound? Just a minor point, I think we should put the or the DPL's delegates in () because according to the constitution the DPL could delegate these powers anyways (and so this part is just repeating what our constitution says, and not something special for this decision here). Yes, that sounds slightly better. So, basically, we have now: - My original proposal, which has received enough seconds, - Neil's amendment A, which adds the current mailinglist CoC to the further reading section. I have accepted that amendment in 20140308012109.ga...@grep.be, and no sponsors have objected, so under A.1.5 of the constitution my original proposal is replaced by Neil's amendment A. - Neil's amendment B, which I have not accepted (and which I will not accept either) and which has received enough seconds. However, I have suggested some minor adjustments, and Neil seems to have accepted them (though not formally so). If Neil were to formally accept my amendment to his amendment to my GR proposal (or possibly, Andreas' amendment to my amendment to Neil's amendment to my GR proposal -- still with me? ;-), that would end us up with two options on the ballot rather than three (not counting FD), which I think would be a plus. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ signature.asc Description: Digital signature
Re: GR proposal: code of conduct
On Mon, Mar 10, 2014 at 06:54:51PM +0100, Kurt Roeckx wrote: On Mon, Mar 10, 2014 at 01:34:31PM +, Neil McGovern wrote: Formally accepted :) So I inserted that after 2, and it now reads: ol liThe Debian project decides to accept a code of conduct for participants to its mailinglists, IRC channels, and other modes of communication within the project. liThe initial text of this code of conduct replaces the mailinglist code of conduct at http://www.debian.org/MailingLists/#codeofconduct liUpdates to this code of conduct should follow the normal GR procedure. However, the DPL (or the DPL's delegates) can add or remove links to other documents in the Further reading section after consultation with the project and without requiring a GR. liThe initial text of the code of conduct follows, in markdown format. /ol Can you confirm that that was your intention? Not what I meant, but I'll grant you there's some room for confusion here. I have accepted Neil's original proposal to drop the second item in the above, and make it an extra entry in the further reading section. Under A.1.2, that means my original proposal and Neil's amendment A should now be considered one and the same thing, both using Neil's text (unless any of the seconders of my original proposal were to object, which so far nobody has done and which would surprise me, given the seconders of the original proposal and of Neil's first amendment are largely the same people) I interpret all that as meaning Neil's second amendment must now be based upon his first amendment (which, indeed, his proposal as sent was not). It would therefore read: ol liThe Debian project decides to accept a code of conduct for participants to its mailinglists, IRC channels, and other modes of communication within the project. liUpdates to this code of conduct should follow the normal GR procedure. However, the DPL (or the DPL's delegates) can add or remove links to other documents in the Further reading section after consultation with the project and without requiring a GR. liThe initial text of the code of conduct follows, in markdown format. /ol i.e., dropping item 2 (and adding the text of his amendment A to the further reading section). A strict reading of Neil's original text would indeed imply the above is wrong, but I would be surprised if that were his intention, given that he proposed that change in the first place... -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ signature.asc Description: Digital signature
Re: GR proposal: code of conduct
On Mon, Mar 10, 2014 at 09:03:19PM +0100, Kurt Roeckx wrote: The first one is now: ol liThe Debian project decides to accept a code of conduct for participants to its mailinglists, IRC channels, and other modes of communication within the project. liUpdates to this code of conduct should be made by the DPL or the DPL's delegates after consultation with the project, or by the Debian Developers as a whole through the general resolution procedure. liThe initial text of the code of conduct follows, in markdown format. /ol It adds the following text at the end of the initial text: pre - The [Mailing list code of conduct](http://www.debian.org/MailingLists/#codeofconduct) is useful for advice specific to Debian mailing lists /pre === And I understand that your understanding is that the second one should be: === ol liThe Debian project decides to accept a code of conduct for participants to its mailinglists, IRC channels, and other modes of communication within the project. liUpdates to this code of conduct should follow the normal GR procedure. However, the DPL (or the DPL's delegates) can add or remove links to other documents in the Further reading section after consultation with the project and without requiring a GR. liThe initial text of the code of conduct follows, in markdown format. /ol It adds the following text at the end of the initial text: pre - The [Mailing list code of conduct](http://www.debian.org/MailingLists/#codeofconduct) is useful for advice specific to Debian mailing lists /pre === In which case I should just add the link to the mailling list CoC initial text since all options now have that. Yes, that's what I think should be done. Neil, can you confirm? -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140310211907.gb7...@grep.be
Re: GR proposal: code of conduct
On Wed, Mar 05, 2014 at 06:05:45PM +, Neil McGovern wrote: On Wed, Mar 05, 2014 at 05:53:48PM +, Neil McGovern wrote: Seconded, but I'd also like a couple of amendments which I'll add in another mail. And here's those amendments. Amendment A - move mailing list CoC text to further reading Justification: I think that it's better to keep the CoC as a general purpose document, rather than have it specific to each medium. The information at http://www.debian.org/MailingLists/#codeofconduct is still useful as it stands. I'm hopeful Wouter will accept this one, as I don't think it substantially changes the CoC. - participants to its mailinglists, IRC channels, and other modes of communication within the project. -2. The initial text of this code of conduct replaces the mailinglist - code of conduct at http://www.debian.org/MailingLists/#codeofconduct - -3. Updates to this code of conduct should be made by the DPL or the +2. Updates to this code of conduct should be made by the DPL or the DPL's delegates after consultation with the project, or by the Debian Developers as a whole through the general resolution procedure. -4. The initial text of the code of conduct follows, in markdown format. +3. The initial text of the code of conduct follows, in markdown format. # Debian Code of Conduct [snip] - Debian has a [diversity statement](http://www.debian.org/intro/diversity) - The [Debian Community Guidelines](http://people.debian.org/~enrico/dcg/) by Enrico Zini contain some advice on how to communicate effectively. +- The [Mailing list code of + conduct](http://www.debian.org/MailingLists/#codeofconduct) is useful for + advice specific to Debian mailing lists - After some consideration, I accept this amendment. The original goal of my proposed CoC was to replace the original the mailinglist code of conduct, as I considered it of somewhat limited use. To keep it and point to it would therefore somewhat defeat my original purpose. However, it is now clear that listmasters disagree; and as there are reasonable arguments for some of the things in the mailinglist coc, even though I think they should probably be in a different kind of document, I accept that my proposed CoC is not a replacement. So it does make sense to keep it, even if that's not what I had planned for. Amendment B - Updates to the CoC should be via developers as a whole Justification - I believe that this document should have the strength of being a whole project statement. Being able to be updated by a single person doesn't feel comfortable with me. I'm less convinced Wouter will accept this, but I think it should be on the ballot! - 2. The initial text of this code of conduct replaces the mailinglist code of conduct at http://www.debian.org/MailingLists/#codeofconduct -3. Updates to this code of conduct should be made by the DPL or the - DPL's delegates after consultation with the project, or by the Debian - Developers as a whole through the general resolution procedure. - -4. The initial text of the code of conduct follows, in markdown format. +3. The initial text of the code of conduct follows, in markdown format. # Debian Code of Conduct - The reason for that clause in my proposal was some discussion (not sure anymore whether it was during the BoF or on -project) where most people seemed to be in favour of allowing the DPL to make changes, rather than having to go through what might be a lengthy and tiresome GR procedure; but my original idea was to use a GR, too. In other words, I might not be as opposed to this as you think ;-) Having said that, I do think the further reading section should *not* require a GR to be updated. Useful documents get written all the time, and adding such a link to the document should not be controversial, no matter what. So rather than accepting this amendment, I propose that we modify paragraph 3 read as follows, instead: --- 3. Updates to this code of conduct should follow the normal GR procedure. However, the DPL or the DPL's delegates can add or remove links to other documents in the Further reading section after consultation with the project and without requiring a GR. --- The idea here is that a DPL can add a link to something considered useful, while normal DD's can still add such a link through a GR if the DPL is opposed. How's that sound? -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ signature.asc Description: Digital signature
Re: GR proposal: code of conduct
On Fri, Mar 07, 2014 at 06:37:41PM +0100, Kurt Roeckx wrote: On Wed, Feb 12, 2014 at 11:59:42AM +0100, Wouter Verhelst wrote: == 1. The Debian project decides to accept a code of conduct for participants to its mailinglists, IRC channels, and other modes of communication within the project. So I've been wondering under which part of the constituion I should be putting all the options. Are they position statements? More like a nontechnical policy document. But that's also 4.1.5 ;-) -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140308012759.gb...@grep.be
Re: GR proposal: code of conduct
Hi, Op maandag 24 februari 2014 08:47:57 schreef Alexander Wirt: Sorry for being late. No worries -- we don't always have the time :) That morning I found the time to read the CoC in detail. In that mail I speak primary for myself and not all listmasters. But I collected some opinions from the others forehand, therefore I hope that what I write is in line with the other listmasters. Thanks I am quite happy with the CoC as it is, I just have a few supplementary notes. - the CoC, can only be an extension to our (lists.d.o) Coc [1], as there are missing the mail/list specific parts. Hm. The whole point of this exercise was to replace that code of conduct with a more generic and up-to-date one, so if you feel that this isn't good enough, then that's a bug. Can you be more specific about the bits that you think should not be removed from the current mailinglist coc? I am also not that happy with having several documents with the name 'Code of Conduct', maybe we can find a solution somehow. Yes, that would seem to be obvious; I don't think we need several codes of conduct. - I always found the netiquette [2] a very useful source, maybe we can add a link to it to the document. Good idea. - The administrators will divulge any bans to all Debian Developers for review. I know that this is the case for lists.d.o now, but I never saw other anything from other services. I have seen several such announcements from owner@bugs.d.o now, too. Are _all_ other administrators of 'Debian communication forums' aware of that change? If we go that way, we should probably move away from announcing them on -private and move to something else. Like an mbox on master, or something else (and in my eyes - non-public). I don't think it's necessary to move that. While the code of conduct says that bans should be made public to Debian Developers, it does not say how, where, in what manner, or even if bans should be made public _only_ to Debian Developers (although we might be somewhat more explicit about that). This is intentional; I think review of bans is a good thing, and I do think we should have it, but I don't want a document like this to impose any workflow on anyone. As such, personally I don't expect this to result in a major increase (other than has already happened) of such announcements to -private. I could be mistaken, of course. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ signature.asc Description: This is a digitally signed message part.
Re: GR proposal: code of conduct
Op woensdag 26 februari 2014 15:25:25 schreef u: On Wed, 26 Feb 2014, Wouter Verhelst wrote: Hi, *snip* - the CoC, can only be an extension to our (lists.d.o) Coc [1], as there are missing the mail/list specific parts. Hm. The whole point of this exercise was to replace that code of conduct with a more generic and up-to-date one, so if you feel that this isn't good enough, then that's a bug. Can you be more specific about the bits that you think should not be removed from the current mailinglist coc? Your goals are honorable, but I am not sure if this possible. Let me see: I have some example that I don't want to lose, but most are for example not suitable for IRC: - Do not send spam; see the advertising policy below. (the advertising policy is the interesting part) Right, that one. I'm not sure this belongs in a code of conduct, for the same reason that we shouldn't publish bans for trolls or spammers. A code of conduct should be about conduct, i.e., social behaviour, not about don't be a pest. That doesn't mean we should not have a do not spam policy, nor that we cannot publish such a policy; just that I don't think it should be part of a code of _conduct_. In addition, personally I am not convinced that this part of the current code of conduct is very efficient in fighting spam, but then I am not in your shoes. Do you believe otherwise? If so, can you clarify? - Send all of your e-mails in English. Only use other languages on mailing lists where that is explicitly allowed (e.g. French on debian-user-french). A clause like Please use the appropriate language for the medium you are using. In Debian, this is usually English, but there are exceptions (e.g. use French on the debian-user-french mailinglist, or Dutch on the #debian-nl IRC channel). could work. Having said that, I should note that my very first draft[1] did still contain this clause (or a similar one, at least); I'm not sure anymore why it was removed. [1] https://lists.debian.org/debian-project/2013/05/msg00060.html - Make sure that you are using the proper list. In particular, don't send user-related questions to developer-related mailing lists. Some of our communication channels have topic-specific subdivisions; please use the appropriate one for your topic, possibly with an example? - Wrap your lines at 80 characters or less for ordinary discussion. Lines longer than 80 characters are acceptable for computer-generated output (e.g., ls -l). - Do not send automated out-of-office or vacation messages. - Do not send test messages to determine whether your mail client is working. - Do not send subscription or unsubscription requests to the list address itself; use the respective -request address instead. - Never send your messages in HTML; use plain text instead. - Avoid sending large attachments. While I agree that these are useful suggestions (and that therefore they probably should be retained), these sound more like technical guidelines; I don't think a code of _conduct_ should contain technical explanations on how to configure your mail client. So I would suggest that for these things, we create something else (not a code of conduct) that is maintained by you, our listmasters. The (proposed) code of conduct could obviously refer to it from the further reading section, if that seems appropriate. Does that make sense? Additionally, the bits about large attachments and HTML sound like things that could more easily be done by a filter. If we don't want large attachments, we should make it technically impossible for people to send them (while making sure that those who try will get an informative bounce message). - Do not quote messages that were sent to you by other people in private mail, unless agreed beforehand. I believe such a clause was originally part of the Be open item in my draft, but it got edited out. We could add it back, of course... - When replying to messages on the mailing list, do not send a carbon copy (CC) to the original poster unless they explicitly request to be copied. Well, heh. On that one, I think the current code of conduct is a mistake, because most mail clients make it very hard to do that. Yes, some mail clients do have a list reply option, but some will only send the reply to the mailinglist on which the person replying received the mail in question; any cross-posted mailinglists will be dropped, which is not always the right thing to do. Yes, one can edit the list of recipients and remove non-list recipients, but then those recipients who explicitly asked to be Cc'd somewhere up the thread will not receive those requested copies. I think we should default to what tools make easy, not to the option which requires manual work. I understand that this is the current policy, and if there is a strong feeling that we should retain it, I won't oppose keeping it. But my personal opinion
Re: GR proposal: code of conduct
Hi, Op donderdag 13 februari 2014 14:13:40 schreef Alexander Wirt: On Thu, 13 Feb 2014, Wouter Verhelst wrote: If indeed listmasters do object (which I don't think will be the case, but of course I can't read their minds), then obviously we'll need to work with them to fix that. Indeed, if what we propose is in line with what listmasters believe should be done, then this issue would be moot, anyway. in my case it is more the lack of time to dive into that process. I still think we should comment it. Can you give me a reasonable time estimate? I want to push this forward, but I also do value your input. If there's no reply forthcoming from you, however, then these two goals are conflicting... -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- 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/32420579.77qxmeh...@grep.be
Re: GR proposal: code of conduct
On Wed, Feb 12, 2014 at 10:49:51PM +, Ian Jackson wrote: Wouter Verhelst writes (Re: GR proposal: code of conduct): 2. The initial text of this code of conduct replaces the mailinglist code of conduct at http://www.debian.org/MailingLists/#codeofconduct Is this overriding the listmasters then? I'll leave it up to the secretary to decide whether this is, indeed, overriding listmasters, but I don't think it is, or should be. I think it would be better to get an opinion from the listmasters. If the listmasters are happy with the GR then clearly it's not overruling them. If they are unhappy with it then given that they're mostly going to be implementing it we should hear about it and take their comments on board! I would be happy to second this GR provided that the listmasters approve, or at least don't object. I don't want to CC the listmasters in this thread on -vote because they probably don't want a zillion crossposts. As the proponent and editor, would you send them a mail asking their opinion ? I did actually already do that (by mail to listmaster@, on 2013-11-27, with Message-ID: 5295bda8.80...@debian.org), but never got a reply. Whether that is because the mail was forgotten, or because they just agreed with it and didn't think it therefore required a reply or something else entirely, I cannot say. But given the level of consensus I had already achieved on -project, and given the fact that I do think it is mostly in line with their current policies, means I thought it better to move this forward. If indeed listmasters do object (which I don't think will be the case, but of course I can't read their minds), then obviously we'll need to work with them to fix that. Indeed, if what we propose is in line with what listmasters believe should be done, then this issue would be moot, anyway. So, we have a Foundation Document, or a Position Statement that's agreed by GR, and then can be changed by the DPL to a delegate. I don't think this is entirely constitutional... I think this would be dealt with by a rubric at the top of the GR which says: The Debian Project adopts the following Position Statement under 4.1.5 of the Constitution. (This is not a Foundation Document.) That sounds reasonable, yes. The position statement really only is the we accept a code of conduct part. Everything else isn't. The part saying the DPL can change the CoC surely is part of the position statement. Yes, obviously. What I meant was the bits on top, excluding the CoC itself; as in, the concept of a CoC and its procedures is what the vote is about, not the actual text of the CoC. Maybe that means I should not put the text of the code of conduct inline with the rest of the GR? If so, I'll happily do so. I think you should indent it, or put it in an appendix, or something. Yes, that would work, too. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- 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/20140213102353.ge16...@grep.be
GR proposal: code of conduct
Hi all, This is to propose a general resolution under §4.1.5 of the constitution to propose a Debian code of conduct. This code of conduct has been drafted during debconf, and been refined during a BoF session there and in a discussion on the debian-project mailinglist. For more details, please see 52790de1.20...@debian.org There has been a delay since the thread on -project; this was due to the fact that it was pointed out to me, in private, that before imposing some procedure on the listmasters, it *might* have been good to ask for their input, which indeed I had failed to do. I did send them an email in December, but have thus far not received a reply; and January has been busy for me, being involved in organizing FOSDEM *and* in a debconf bid. I went over the thread quickly just now because there were still a few outstanding issues; I think I incorporated all comments (interested parties can see diffs for my last few changes through http://anonscm.debian.org/gitweb/?p=users/wouter/coc.git;a=history;f=coc.markdown). I did consider posting this to -project once more, but decided against i; I think the current draft is pretty close to consensus (if it hasn't already achieved that), and any further changes can easily be done through the normal GR procedure. I am therefore asking for seconds to this proposal, with apologies for the fact that this has taken far too long. GR text follows: == 1. The Debian project decides to accept a code of conduct for participants to its mailinglists, IRC channels, and other modes of communication within the project. 2. The initial text of this code of conduct replaces the mailinglist code of conduct at http://www.debian.org/MailingLists/#codeofconduct 3. Updates to this code of conduct should be made by the DPL or the DPL's delegates after consultation with the project, or by the Debian Developers as a whole through the general resolution procedure. 4. The initial text of the code of conduct follows, in markdown format. # Debian Code of Conduct ## Be respectful In a project the size of Debian, inevitably there will be people with whom you may disagree, or find it difficult to cooperate. Accept that, but even so, remain respectful. Disagreement is no excuse for poor behaviour or personal attacks, and a community in which people feel threatened is not a healthy community. ## Assume good faith Debian Contributors have many ways of reaching our common goal of a [free](http://www.debian.org/intro/free) operating system which may differ from your ways. Assume that other people are working towards this goal. Note that many of our Contributors are not native English speakers or may have different cultural backgrounds ## Be collaborative Debian is a large and complex project; there is always more to learn within Debian. It's good to ask for help when you need it. Similarly, offers for help should be seen in the context of our shared goal of improving Debian. When you make something for the benefit of the project, be willing to explain to others how it works, so that they can build on your work to make it even better. ## Try to be concise Keep in mind that what you write once will be read by hundreds of persons. Writing a short email means people can understand the conversation as efficiently as possible. When a long explanation is necessary, consider adding a summary. Try to bring new arguments to a conversation so that each mail adds something unique to the thread, keeping in mind that the rest of the thread still contains the other messages with arguments that have already been made. Try to stay on topic, especially in discussions that are already fairly large. ## Be open Most ways of communication used within Debian allow for public and private communication. As per paragraph three of the [social contract](http://www.debian.org/social_contract), you should preferably use public methods of communication for Debian-related messages, unless posting something sensitive. This applies to messages for help or Debian-related support, too; not only is a public support request much more likely to result in an answer to your question, it also makes sure that any inadvertent mistakes made by people answering your question will be more easily detected and corrected. ## In case of problems While this code of conduct should be adhered to by participants, we recognize that sometimes people may have a bad day, or be unaware of some of the guidelines in this code of conduct. When that happens, you may reply to them and point out this code of conduct. Such messages may be in public or in private, whatever is most appropriate. However, regardless of whether the message is public or not, it should still adhere to the relevant parts of this code of conduct; in particular, it should not be abusive or disrespectful. Assume good faith; it is more likely that participants are unaware of their bad behaviour than that they intentionally try to degrade the
Re: GR proposal: code of conduct
On Wed, Feb 12, 2014 at 11:40:17AM +, Neil McGovern wrote: Hi Wouter, Thanks for all your work on helping bring this together so far, but I think this ballot is troubling on a number of reasons. On Wed, Feb 12, 2014 at 11:59:42AM +0100, Wouter Verhelst wrote: 1. The Debian project decides to accept a code of conduct for participants to its mailinglists, IRC channels, and other modes of communication within the project. How do you see this being effective? Are you envisioning it being agreed to as part of the NM process perhaps? I'm not sure that would send out the right message; we don't want just DDs to abide by a code of conduct; we want every contributor on our communication channels to do so. Additionally, how core is this to the project - could it be viewed as a Foundation Document? I don't think we should see it that strict. The reason I want to put this before the developer body as a whole is that we should have the developers agree on the principle of an enforceable code of conduct. However, it is certainly possible that some future situation would abide by the letter, but not the spirit, of this code; in that case, I think having a difficult-to-modify document would be positively harmful. IRC channels are particularly interesting, as they also hold additional standards to be upheld. The actual text seems to be somewhat geared towards mailing lists, True. I don't think this is entirely unreasonable, because -- let's face it -- Debian communications *are* mostly mailing lists. We do have other channels, but everything of importance is done by mail. and then has other communication mechanisms bolted in to it. I didn't want to come up with an enumeration of all possible and impossible communication methods used by Debian; that would necessarily be somewhat limiting. I do think having a clause in that regard is necessary for that reason, but am welcome to other formulations that would clarify the meaning -- keeping in mind that I'm not a native English speaker ;-) As an obvious omission, IRC ops aren't on https://www.debian.org/intro/organization. Yes, and that's something which should be fixed IMO, but not necessarily as part of this GR. 2. The initial text of this code of conduct replaces the mailinglist code of conduct at http://www.debian.org/MailingLists/#codeofconduct Is this overriding the listmasters then? Fair question. I was under the impression that the code of conduct had not changed in the past decade; given that, I thought that, certainly, the current listmasters wouldn't have been involved in its authoring very much if that were true. Given that background, I would not have considered it overriding the listmasters. A quick perusal of the CVS logs shows me wrong, however, and given that, the question isn't undeserved. Regardless, I think the proposed code of conduct doesn't contradict current behaviour of listmasters; it only ratifies it (and where it doesn't, that's a bug in my proposed text). Indeed, some parts of the current code of conduct are not present in the proposed one; but these are merely the bits that are unenforceable (the do not spam and use common sense bits), should be enforced through technical means rather than social ones (the don't send HTML and don't send large attachments ones), etc. I'll leave it up to the secretary to decide whether this is, indeed, overriding listmasters, but I don't think it is, or should be. 3. Updates to this code of conduct should be made by the DPL or the DPL's delegates after consultation with the project, or by the Debian Developers as a whole through the general resolution procedure. So, we have a Foundation Document, or a Position Statement that's agreed by GR, and then can be changed by the DPL to a delegate. I don't think this is entirely constitutional... The position statement really only is the we accept a code of conduct part. Everything else isn't. Maybe that means I should not put the text of the code of conduct inline with the rest of the GR? If so, I'll happily do so. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ signature.asc Description: Digital signature
Re: GR proposal: code of conduct
On Wed, Feb 12, 2014 at 06:25:12PM +, Ben Hutchings wrote: On Wed, 2014-02-12 at 11:59 +0100, Wouter Verhelst wrote: [...] ## Assume good faith Debian Contributors have many ways of reaching our common goal of a [free](http://www.debian.org/intro/free) operating system which may differ from your ways. Assume that other people are working towards this goal. Note that many of our Contributors are not native English speakers or may have different cultural backgrounds ## Be collaborative [...] Is this last paragraph complete? It is at least missing a full stop and following blank line. It is, though it indeed misses a full stop there. The error was introduced in http://anonscm.debian.org/gitweb/?p=users/wouter/coc.git;a=commitdiff;h=fa60ac6b67051bf10294f5b57f1e92188e9e05de;hp=a341fed0106959bdf6ed7292bf62ca56ffb3c9ef I've committed a change to my git repository to remedy that; I don't think this minor change needs me to restart the procedure, but further updates will contain the fixed text. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ -- 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/20140212214734.gc16...@grep.be
Proposed amendment (was: Re: GR: Selecting the default init system for Debian)
On Sat, Jan 25, 2014 at 08:20:35PM +0900, Charles Plessy wrote: Le Thu, Jan 23, 2014 at 04:14:41AM +0100, Wouter Verhelst a écrit : On Thu, Jan 23, 2014 at 09:58:14AM +0900, Charles Plessy wrote: In that case, I think that the project should decide via using this or that system (“vote with the feet”). For the packages where init scripts are a limitation, just depend on systemd, upstart, openrc, or combinations of them, and if and only if it is not possible to install Debian because pairs of core packages depend on different single init systems, let's vote. So, let me get this straight. Hi Wouter, OK, let's be straight :) You're saying let's do nothing until the entire system breaks because of a component that nobody really cares about, so that we can _then_ try to start a procedure which will take weeks (if not months) to maybe unbreak it, leaving the system in an utterly broken state in the meantime? What I am saying is: Let's allow the Debian system to evolve freely: the result will not be breakage, but systemd as a de facto default. This argument has been brought up before (indeed, even by me), and has been debunked by several people. There are several problems with that approach for the choice of init system: First, a change of MTA, FTP server, or browser produces a user-visible change in an area that most users will care about. An init system does not--and note the most in the previous sentence. Second, it is possible to define the interface which an MTA, FTP server, or web server should provide to the rest of the system (e.g., serve files in this directory by default, or send mails to remote users if passed to the sendmail binary) without going into too much technical detail on how exactly the MTA, FTP daemon, or web server needs to do so, and also without sacrificing features that we might want. The same is not true for init systems. For instance, while we could just declare that all packages need to provide initscripts (which then means that even sysv-rc could still be used), that really is just the status quo, and we might as well not bother. I am personally convinced that we *do* need a better init system. I don't actually care _which_ init system that is, and am contend to leave that decision to the people who do. But we should not retain the status quo. If you think systemd will become the de facto default, then why not just throw out the years of bickering and bikeshedding and just decide that _now_? We should have made a decision on this subject years ago. The debate is reducing the quality of our mailing lists, is holding the entire project hostage, and we're *still* no closer to an answer. Even the TC seems to be having difficulties reaching a decision. So, let me propose the following amendment, then: - If this option wins, the project secretary, in the presence of at least two other Debian Developers, will roll a dice. If the dice comes at rest with 1 or 2 facing up, systemd will become the default init system for Debian. If the dice comes at rest with 3 or 4 facing up, upstart will become the default init system for Debian. If the dice comes at rest with 5 or 6 facing up, openrc will become the default init system for Debian. - I am looking for seconds. And no, that's not a joke; at this stage the debate is essentially deadlocked, and I am doubtful that the debate will *ever* reach a conclusion which will be the best on a technical and/or political level. All available options feature some things that the others don't, all have downsides, and none of the available options will ever be a perfect solution. We could discuss this ad infinitum and end up with a non-solution, or we could just bite the bullet and make a decision. At this point, I think any decision is better than no decision, even if that decision is the throw of a dice. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ signature.asc Description: Digital signature
Re: GR: Selecting the default init system for Debian
Before I forget, there's one thing I wanted to say about this: On Sun, Jan 19, 2014 at 01:01:44AM +0100, Guillem Jover wrote: [...] Option A [...] Option B [...] Option C [...] Option D [...] Option E [...] Option F [...] Option G [...] Please don't do that. If you want to propose a GR, please only propose those options that you actually want to see win. When seconding, please only second those options that you actually want to see win (or lose against NOTA, so nobody will ever bring it up again). A ballot with too many options is never a good ballot, and no matter how hard you try you'll always miss one or two possibilities. That would mean we'd get a ballot with 8 or 9 options, which is too many in my opinion. When drafting a GR text for an option that you think is not the best option, the result will be that you'll end up with a text that those people who *do* think is the best option don't want to support. They'll not be willing to vote for or second those options then, or (worse) will try to propose their own amendment which is different, but only in small details--resulting in yet *another* option on the ballot. If enough people actually think some option in your list deserves being put on the ballot, rest assured they'll propose amendments and get them seconded. I have enough faith in our developers that this will happen. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ signature.asc Description: Digital signature
Re: Proposed amendment (was: Re: GR: Selecting the default init system for Debian)
On Sat, Jan 25, 2014 at 05:31:50PM +0100, Holger Levsen wrote: Hi, On Samstag, 25. Januar 2014, Wouter Verhelst wrote: So, let me propose the following amendment, then: - If this option wins, the project secretary, in the presence of at least two other Debian Developers, will roll a dice.[...] - I am looking for seconds. And no, that's not a joke; Well, my option this is hard, my brain hurts, lets go shopping was a joke and essentially the same as the above. If you cannot wrap your mind around a problem, please dont declare defeat for the whole project or propose silly solutions. Just because the problem is too hard for some, doesnt mean there aint sensible solutions. Rolling a dice aint one of them. I'm not saying that rolling a dice is the best option. But I *do* think it is a better option than 'further discussion', so if this ever gets to a vote I will most definitely rank this above NOTA. We need to make a decision on this subject. I'm still hoping the TC will be able to make that decision, but it remains possible that they don't. If that is the case, and this does come to a vote, I want to have this option on the ballot. Think of it as a last resort. I do want to go with the technically correct choice, if we as a project can make it. But if the technical committee fails to make a decision, and if a GR does the same, we'd end up with no decision. If given that option and rolling a dice, then I think rolling a dice is the lesser of the two evils. -- This end should point toward the ground if you want to go to space. If it starts pointing toward space you are having a bad problem and you will not go to space today. -- http://xkcd.com/1133/ signature.asc Description: Digital signature
