Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Mon, Jan 05, 2009 at 11:37:01PM +0100, Joerg Jaspert wrote: I think its best we end up with 2 options on the vote, 1) Increase requirements to 2Q [3:1] 2) Increase requirements to Q [3:1] and also the usual Further Discussion, which would be for everyone who wants to keep the current state of 5 people. That, IMO, should fit everyone. It seems to me it's a mistake to attribute to FD any meaning other than let the discussion continue. If I prefer the current arrangement, I don't want to vote for further discussion, I want to vote for *stop the discussion*. If Further Discussion wins a vote which lacks an explicit status quo option, how does one interpret it? Clearly, none of the options were good enough, but was the problem that people don't want to change or that people want to change it to some other value not listed? Hence, a third option keep the requirement as it is would probably be a good idea. -- Antti-Juhani Kaijanaho, Jyväskylä, Finland http://antti-juhani.kaijanaho.fi/newblog/ http://www.flickr.com/photos/antti-juhani/ signature.asc Description: Digital signature
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Joerg Jaspert writes (Re: Discussion: Possible GR: Enhance requirements for General Resolutions): On 11622 March 1977, Charles Plessy wrote: The goal of this GR is still unclear to me, and I would welcome a preamble that clearly explains what problem is being solved. The goal is to change the needed seconds for a GR. I think you've misunderstood Charles's question. We understand that you would like to change the number of seconds. The question, which I would like to see you answer as well, is what the _purpose_ of that change would be. What problem(s) would be (perhaps partially) solved, or what improvements do you think would result ? Thanks, Ian. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Stephen Gran sg...@debian.org wrote: This one time, at band camp, MJ Ray said: Many DDs ignore -project and even most stuff on -vote unless/until it looks likely to get enough seconds, don't they? You're the one making the assertion, I think the onus is on you to prove it. Previously, I noted that fewer than 80 people participated in even the hotly disputed lenny blobs GR discussion. That suggests to me that lots of DDs aren't participating until the vote. It's hard to prove that a group is ignoring something, but disproof is simple: please could all DDs reading this email mjr-possiblegr at debian.org. I'll count with from -f possiblegr.mbox | wc -l in a week. The discussion so far on this topic has, to my mind, suggested the opposite reading. We've seen postings from several people who don't normally post to -vote (and they've been fairly uniformly in support of the ideas being proposed, at a glance), which suggests to me that we have more lurkers than you are assuming. Cross-checking names of posters to this thread on -project with an index of posters to -vote finds *no* new participants. That comes down to how one defines normal in normally post to -vote. Here's a summary list of concerns I mentioned in other emails:- 1. 2Q is unjustified and excessive; [...] Why 30? Why not 130? Why not 300? The particular number is unjustified. I personally would be happy with a higher number, but 30 is a conservative first start. Would you be happier if the suggestion was 4Q or 10Q? Not if it's still unjustified. If we're groping in the dark, let's grope somewhere near to our current position, instead of leaping about the room and possibly slamming into a brick wall. If 10Q is ever seriously considered, it seems better to replace the SRP with a different, more consensual, voting system. I'm not good at interpreting complex constitutions, but [...] Yep, I got it wrong, thanks to the unusual meaning of quorum in the debian constitution - compare with http://www.dict.org/bin/Dict?Form=Dict2Database=*Query=quorum What about the other two concerns: the obvious spoiler effect; and defending proposals during the discussion period? The 'obvious' spoiler effect - is that the idea that proposals with no supporters probably won't make it to a GR? That's a feature. In short, it's the idea that you can keep a compromise amendment off of the ballot by proposing a similar-but-slightly-more-extreme one, then letting the compromise amendment fail due to seconder fatigue and the reluctance of some DDs to second multiple options. We currently have two examples where options which didn't exceed 2K seconds went on to win the vote. Does a higher seconding requirement risk of introducing something similar to the threshold effect from elections (such as the German and Turkish national elections) into getting onto a GR ballot? I think the ability to second multiple options (which Don Armstrong initially argued against) may reduce it, but I also suspect seconder fatigue (similar to voter fatigue) means it'll still exist. Why is defending an option you are proposing a problem, and how is it worsened by increasing the number of required seconds over the current situation? It is a problem because it encourages division rather than consensus-building. It's much harder to develop a compromise when many participants have already publicly announced their preferred solution. It is worsened by increasing the number of required seconds because that increases the probability of uncompromising defenders *before* many DDs are necessarily aware of the proposal. If anything, it seems like increasing the number of required seconds means an incentive to have a wider discussion before proposing the GR, which if anything will widen the opportunity to build consensus, and if consensus can't be reached, make it possible to create a few compromises that people could live with before pretending we can resolve our difference in 2 weeks with a vote looming. So no compromises can be found in two weeks? Does increasing the number of required seconds mean that some proportion of DDs will be probably spending even more time developing GRs and the rest of us will have to spend even more time watching them? How will the unannounced pre-proposal discussions be wider than the GR discussion period which is announced to all DDs? The 2 weeks is a minimum, not a requirement - but if the required discussion period is essentially useless and just for filtering out small errors, should it be shortened? Regards, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
MJ Ray m...@phonecoop.coop (07/01/2009): Previously, I noted that fewer than 80 people participated in even the hotly disputed lenny blobs GR discussion. That suggests to me that lots of DDs aren't participating until the vote. It's hard to prove that a group is ignoring something, but disproof is simple: please could all DDs reading this email mjr-possiblegr at debian.org. I'll count with from -f possiblegr.mbox | wc -l in a week. Even for people who might try and follow those lengthy so-called discussions, extra-long mails like Ron's or yours makes it likely that From→mark-as-read actions appear. I wouldn't call your hiding foo at bar in one of them a simple disproof of anything. Mraw, KiBi. signature.asc Description: Digital signature
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
* MJ Ray [Wed, 07 Jan 2009 10:04:50 +]: It's hard to prove that a group is ignoring something, but disproof is simple: please could all DDs reading this email mjr-possiblegr at debian.org. I'll count with from -f possiblegr.mbox | wc -l in a week. o/` I am speechless, speechless That's how you make me feel When I'm with you I am lost for words, I don't know what to say Helpless and hopeless, that's how I feel inside o/` -- Another MJ (In other words, I don't understand what possible correlation there could be between people following or not an experiment by you *deep buried in a thread pattern*, and people seconding an amendment they agree with, knowing it still needs, say, 12 seconds.) -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Justin Nozuka - After Tonight -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Cyril Brulebois k...@debian.org wrote: MJ Ray m...@phonecoop.coop (07/01/2009): It's hard to prove that a group is ignoring something, but disproof is simple: please could all DDs reading this email mjr-possiblegr at debian.org. I'll count with from -f possiblegr.mbox | wc -l in a week. Even for people who might try and follow those lengthy so-called discussions, extra-long mails like Ron's or yours makes it likely that From→mark-as-read actions appear. I wouldn't call your hiding foo at bar in one of them a simple disproof of anything. If that email address gets lots of responses, it simply disproves my claim that no DDs are watching this sort of discussion. If it gets no responses, it still doesn't prove my claim, but how could I prove it? At least I'm trying to check if my belief is wrong, instead of just contradicting other people. In case thread-killing is significant, I'll post it as a new thread. Hope that helps, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Ron r...@debian.org wrote: [...Wouter Verhelst's counts...] Those results are not surprising, and if anything make it clear we can easily get more seconds for notable issues than is currently required. How many more is debatable, but this isn't very good evidence for your assertion that 30 people is a very high bar. So provide other evidence, or at least point towards it. I'm using what I've got and I can't use what I've not got. [...] The _formal_ discussion period is limited in length, and IMO quite short. Far too short in fact to actually achieve a real, well considered, consensus in that time. OK, so this proposal means people would spend more time on each GR. I feel that's probably a bad consequence. MJ Ray wrote: [...] also, it's 30 DDs, not 30 people. I'm not sure what you aim to imply there? Are DDs more like sheep than 'people' are or vice versa? Neither. Just there are vote discussion posters who are not DDs. 1. 2Q is unjustified and excessive; The justification (or perhaps 'last straw') is the poor quality of recent vote options, where many people even had quite some difficulty figuring out what the difference between any two options were. [...] I was amongst those having difficulty, as I noted in http://www.news.software.coop/debian-lenny-gr-and-the-secretary/417/ I don't understand how 2Q would necessarily have made it easier, rather than longer and noisier. The exaggeration about how big a change this is seems excessive, but I don't think 30 / 1000 is by most normal scales of excess. What normal scales for seconding? 2. the obvious spoiler effect may exclude consensus options prematurely (interaction of thresholds and Condorcet voting); Sorry, but that sentence is just entirely self-contradictory and unparseable to me ... Whatever effect you speak of is not 'obvious' to me, and if options _had_ consensus clearly there'd be more than 30 people supporting them and they wouldn't be excluded ... Do the different views reduce to: do we believe options should reach consensus before the start of the SRP? [...] Loaded explanations like unjustified and excessive only work if you are preaching to the choir. For the rest of us, that will need to be backed up with some justification of your own if we are to understand what injustice and excess really concerns you here. I've been done! The explanations are loaded because they're not explanations: they're a summary of concerns, as requested previously. My limited justification can be found in messages like http://lists.debian.org/debian-project/2008/12/msg00197.html but I'd welcome justification of 2Q - instead of simple contradictions like these. I don't think a 600% increase is a conservative step. Fortunately this is just an error in your math :) Let's see: It was, but not in that way. If 5 = 100% then 30 = 600%. [... *larger* warring factions? ...] Well if you really believe that might be a problem, then surely you'd be in favour of my actually radical suggestion to raise this threshold to something like 80% of people in the keyring? Not this threshold, but I think I'd second replacing the SRP with something radical that required a relatively high %age. I would prefer any replacement to be time-limited unless there's good reason to be sure it works better than the current way. Alternatively, would it make the path of least resistance ignore everyone else whenever possible because they'll never get 30 or 60 DDs together? Are you saying that if I ever vote with some faction I will never be able to cross the floor and vote with a different group of people who I agree more with on some totally different topic? No. I'm suggesting that GRs would become too rare to be a concern for almost all activities. [vote options defined by a ballot jury] Wait, I'm confused again ... if you are worried about secret groups of 30 people having too much power to influence the project, where are we going to get this jury from, and who will watch the watchers? I'd use a public group selected at random from the keyring, but I'm not strongly attached to that method. [... what goes on in -vote ... not attractive ...] should you really be surprised that we'll build our own consensus to rise up and stop you from doing that? Stop *me*? In 5+ years, I think I've put one amendment on a ballot. I feel that misdirected personal attacks do more to divide the project than any number of discussions. It's not really rocket science, not once you've seen it once or twice before. So please name the other places you've seen it, to convince everyone. [...] I don't want to join the ranks of people who just repeat themselves over and over and over in the vain hope that this will win people over to their way of thinking. Instead of repeating oneself, one could try posting evidence and explaining reasoning, instead of simply making opposite claims and complaining about other views. :-(
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Le Tue, Jan 06, 2009 at 08:50:36AM +0100, Lucas Nussbaum a écrit : Agreed: there's no point discussing which number of seconders you want to require now, we just need a ballot with several options. I would also like options: - to explicitely say that we want to stay with 5 (no further discussion needed) - that we want to increase the requirements to 10. (it would probably be a popular compromise between the current 5 and Q) Hi all, The goal of this GR is still unclear to me, and I would welcome a preamble that clearly explains what problem is being solved. For the moment I do not know if the problem is the multiplication of the amendments in the Lenny GR, the fact that the lenny GR could even being started, the fact that an override vote could be started to force a delegate to postpone his decisions, or a mixture of both. Since none of this year's GRs were rejected by Further Disucussion, I will assume that the problem is the multiplication of amendments in the Lenny GR. Hi hope that Jörg will clarify this in his GR proposal. I think that allowing a proposer to call for vote on an arbitrary subset of amendments is the best answer to the atrocious problem we faced with the Lenny GR (together with changes on the supermajority system, but it is too early to vote in a hurry on this issue). Are there people interested in drafting such an amendment in the case the voting would be started? (do not hesitate to answer in private if you want to limit the traffic on this list). Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Joerg Jaspert wrote: Hi, I have felt for some time that the low requirement for seconds on General Resolutions is something that should be fixed. We are over 1000 Developers, if you can't find more than 5 people supporting your idea, its most probably not worth it taking time of everyone. this will mean that future GRs would need 30 other people to support your idea. While that does seem a lot (6times more than now), considering that a GR affects more than 1000 official Developers and uncounted amounts of other people doing work for Debian, I think its not too much. Especially as point b only requires 15 people, 3 times the amount than now, in case there is a disagreement with the DPL, TC or a Delegate. I agree that actual quote is to low, but I don't think things will change with an higher quote. FYI in Switzerland: for a GR resolution we need 100 000 subscribers, i.e. 2% of potential voters (4.3% of actual voters), and it is more difficult that seconding a Debian GR. Anyway, since 2000 it was called more than 30 times [1] (and all but twice the GR was rejected). For this reason, I think an higher quote probably will not reduce the number of GRs. ciao cate [1] not counting a lot more referendums and mandatory votes (i.e. government driven amendment to constitution), and not counting cantonal and local votes. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Joerg Jaspert jo...@debian.org wrote: In general, that's correct. In particular, if you need 30 people just to *start* the discussion period, that's going to kill many potential options before they have any chance of building consensus and others will be far too entrenched by the time public discussion starts; also, it's 30 DDs, not 30 people. You wont need Q, 2Q, Q^1024 people to start a discussion period. This whole thread didnt need a single second to run like it is, usually all our flames don't need them. Yes, this is not the formal discussion period, but if you fear you wont get enough seconds, or might not be sure its the best to do, going the way I did with this seems to be ok, and able to draw attention from people. There's not a discussion period and a formal discussion period. There's *the* discussion period and a bunch of DDs shooting the breeze like this. Many DDs ignore -project and even most stuff on -vote unless/until it looks likely to get enough seconds, don't they? Of course I do defend what I want. Yet, I still read and keep in mind what others think. OK, thanks. I hope no-one minds, but it didn't read like that yet. Here's a summary list of concerns I mentioned in other emails:- 1. 2Q is unjustified and excessive; I did justify it. If you cant find 30 people out of 1000 that are in the project, why bother 1000 to vote on it?. Why 30? Why not 130? Why not 300? The particular number is unjustified. I'm not good at interpreting complex constitutions, but I think a GR could pass with (3Q/2)+1 votes preferring it to Further Discussion. Requiring more seconds than votes in support seems a bit unusual, to put it mildly. Is there any other voting system that has that? 3. it favours organised campaign groups who gather in secret before springing discussion on debian lists; Umm. If you think so. I do, based on what I've seen of other groups. Raising the number of required seconds too high would give a strong incentive for something like political parties to form within the debian project (you support my manifesto and I'll support yours - that sort of thing) and I think that could cause *really* harmful divisions. What about the other two concerns: the obvious spoiler effect; and defending proposals during the discussion period? I'd welcome other examples, particularly if the minimum is equivalent to anything like the 30 or 60 in the original proposal. Which 60? Its 30 (2Q) or its 15 (Q) what seems to be wanted. I assumed that where 2K is currently (4.2.2.2), it would become 4Q (because K becomes 2Q in general, and Q only for the number of sponsors of Delaying a decision of a Delegate or the DPL). I see that's not at all clear in the proposal - sorry for my confusion. Could you please repost http://lists.debian.org/debian-vote/2008/12/msg00503.html as a proper patch to the constitution (wdiff or whatever), to avoid this sort of confusion? So you think if something is clearly found to be a mistake at some point, the DDs wouldnt be able to admit it and revert it? It *only* takes 30 people to start that. I think that:- *if* requiring 30 seconds is a mistake in general *then* requiring 30 seconds to revert it is also a mistake. Could we have a limited-time trial first? Because:- *if* requiring 30 seconds works well *then* requiring 30 seconds to make it permanent won't be a problem. Won't it? Thanks, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Mon, 05 Jan 2009, MJ Ray wrote: Ron r...@debian.org wrote: Do you really think it would have been difficult to obtain 2Q seconds for a resolution to recall the previous vote, and postpone it until some of the more obvious glitches had been better ironed out? [...] Yes, based on the summary of other votes by Wouter Verhelst and others. I don't really think you can extrapolate from examples of past votes that got considerably more seconds than they required to suggest that proves we'll have trouble getting enough seconds for important issues. In fact if past votes had regularly got 600+% more seconds than they had required that would suggest to me that some large proportion of people didn't actually understand the system they were participating in. It makes _no_ difference how many people second once the required number is reached, so except in a few rare cases I _would_ quite expect most thinking people (the type I'd most prefer to be involved in any vote) to resist the urge to post more of them just for the me too value of it. Those results are not surprising, and if anything make it clear we can easily get more seconds for notable issues than is currently required. How many more is debatable, but this isn't very good evidence for your assertion that 30 people is a very high bar. So, are supporters hoping this situation will change, only a few well-connected DDs will be able to propose GRs, or what? I don't consider myself well-connected, but I don't really have much doubt that I'd be able to get 30 people to put their hand up if I had an issue of project-wide importance that we needed to decide upon in a way that would be suitable for a vote. If I couldn't do that, I'd expect to lose anyway, and approach the problem in some other manner. We seem to have totally lost the goal of making decisions that affect many or all developers by consensus. The process of building consensus revolves around satisfying the concerns of people who see problems with your planned course of action to arrive at a Better Solution. If you can't get the consensus of around 30 people to begin with, it doesn't take a degree in advanced math or political science or military strategy to arrive at the conclusion that you are a LONG WAY from having the consensus of the whole project. In general, that's correct. In general? You have some specific counter example in mind where just 5 people really do represent a consensus of the project?? In particular, if you need 30 people just to *start* the discussion period, Other people already answered this. It only needs _one_ person to post about something to start a discussion. The _formal_ discussion period is limited in length, and IMO quite short. Far too short in fact to actually achieve a real, well considered, consensus in that time. You need to start this process WAY BEFORE it ever gets to a formal last chance for discussion period. Else you are just certain to still have disagreements by the time the vote _must_ be held, and the looming vote can only further polarise opinions. With a vote imminent, the incentive to find workable compromise is minimal indeed. that's going to kill many potential options before they have any chance of building consensus Many _potential_ options need to be 'killed' or integrated with other options to build the larger consensus. This is an absolutely essential part of the process. If we have 1021 potential voters and they all separate into groups of 5 to push their own option or else, then we will have ... wait for it ... 204 options on each ballot. And that's before some people second more than one option ... I have lots of stupid ideas every day. I don't for a minute believe that all of them are worthy of inflicting on other people. But sometimes I do need to inflict them on a just a couple of people before their true stupidity is apparent and they can be shelved. And occasionally, surprisingly, one tiny little part of that idea will be the seed for something bigger. Learning when to let go of the crappy bits is a valuable lesson. Ideas are like children, most people think their own are completely faultless. and others will be far too entrenched by the time public discussion starts; also, it's 30 DDs, not 30 people. I'm not sure what you aim to imply there? Are DDs more like sheep than 'people' are or vice versa? If people can't recognise a truly Better idea just because it wasn't the first one to gain some measure of support, then we are already doomed and the rules for voting don't matter squat anyhow. so I've moved from seeking amendments, to emphasising the profound problems in the proposal ... Here's a summary list of concerns I mentioned in other emails:- 1. 2Q is unjustified and excessive; The justification (or perhaps 'last straw') is the poor quality of recent vote options, where many people even had quite some difficulty figuring out what the difference between any
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Mon, Jan 05, 2009 at 07:01:17PM +0100, Michael Goetze wrote: MJ Ray wrote: to reduce GRs, having another way for developers to ask a question that nearly always gets answered might help. Such as, say, writing an email to debian-de...@ldo? Eh, -devel is for technical issues pertaining to more than a single or a few package(s). I don't think it's a help desk. Michael -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Charles Plessy writes (Re: Discussion: Possible GR: Enhance requirements for General Resolutions): The goal of this GR is still unclear to me, and I would welcome a preamble that clearly explains what problem is being solved. For the moment I do not know if the problem is This is a good way to look a the situation and to that end I'll give my personal view on each of those distinct possible criticisms: the multiplication of the amendments in the Lenny GR, I don't think this is a problem. Our voting system can cope well enough and the difficulty of comprehending six rather than three options is not all that great. the fact that the lenny GR could even being started, Well, I think a GR was inevitable. People feel strongly about these issues and there is no reasonable compromise between the positions of the `hardliners' and the eventual victors in this vote. So I think it's appropriate for there to have been a vote. You may say `but we decided this last time' - but we decided it only for etch and not for lenny. The last time, we (collectively) specifically preferred the option of reopening the question now. the fact that an override vote could be started to force a delegate to postpone his decisions, That's supposed to be possible and I don't think that was the problem. But I would like to suggest two other possible criticisms: that so many of the options on the ballot were so poorly worded that the decision to impose a 3:1 requirement on some of the options gave many people the impression of unfairness That the ballot options were poorly drafted could arguably be explained in part by the requirement to work around the decisions of the Secretary. But it was also, I think, exacerbated by a lack of appropriate assistance from the kind of people who enjoy reviewing this kind of language. There were few people who were keen enough on procedural matters that they wanted to assist people in upholding the RMs' decisions who weren't simultaneously of the view that what was really being done was to undermine the Foundation Documents. I think that allowing a proposer to call for vote on an arbitrary subset of amendments is the best answer to the atrocious problem we faced with the Lenny GR I'm afraid that I must disagree most strongly. If effective, that would give the proposer an ability to control explicitly the options on the ballot - for example, by excluding compromise views. That's one of the most effective mechanisms for subverting any kind of democratic process. And in any case proponents of amendments could instead propose their versions as separate GRs. That might result in them being voted on simultaneously but on separate ballots, leading to the possibility of mutually contradictory conclusions. Ian. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
This one time, at band camp, MJ Ray said: Joerg Jaspert jo...@debian.org wrote: Many DDs ignore -project and even most stuff on -vote unless/until it looks likely to get enough seconds, don't they? You're the one making the assertion, I think the onus is on you to prove it. The discussion so far on this topic has, to my mind, suggested the opposite reading. We've seen postings from several people who don't normally post to -vote (and they've been fairly uniformly in support of the ideas being proposed, at a glance), which suggests to me that we have more lurkers than you are assuming. Here's a summary list of concerns I mentioned in other emails:- 1. 2Q is unjustified and excessive; I did justify it. If you cant find 30 people out of 1000 that are in the project, why bother 1000 to vote on it?. Why 30? Why not 130? Why not 300? The particular number is unjustified. I personally would be happy with a higher number, but 30 is a conservative first start. Would you be happier if the suggestion was 4Q or 10Q? I'm not good at interpreting complex constitutions, but I think a GR could pass with (3Q/2)+1 votes preferring it to Further Discussion. Requiring more seconds than votes in support seems a bit unusual, to put it mildly. Is there any other voting system that has that? Basic math says that in the described two way vote, if an option wins by 1.5Q, and the vote needs 3Q to be quorate, the number of people who have voted for the option is 2.25Q, which is more than the proposal. I don't think this is an argument against the proposal, unless I'm mistaking what you're talking about. What about the other two concerns: the obvious spoiler effect; and defending proposals during the discussion period? The 'obvious' spoiler effect - is that the idea that proposals with no supporters probably won't make it to a GR? That's a feature. Why is defending an option you are proposing a problem, and how is it worsened by increasing the number of required seconds over the current situation? If anything, it seems like increasing the number of required seconds means an incentive to have a wider discussion before proposing the GR, which if anything will widen the opportunity to build consensus, and if consensus can't be reached, make it possible to create a few compromises that people could live with before pretending we can resolve our difference in 2 weeks with a vote looming. -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
This one time, at band camp, Stephen Gran said: Basic math says that in the described two way vote, if an option wins by 1.5Q, and the vote needs 3Q to be quorate, the number of people who have voted for the option is 2.25Q, which is more than the proposal. I don't think this is an argument against the proposal, unless I'm mistaking what you're talking about. Eh, ignore this. It was based on a (mis)memory of a requirement for the vote as a whole to have 3Q voters. The way devotee currently works, it seems each option needs 3Q to pass quorum requirements. This means that it's not 2.25Q who voted for the option, but a minimum of 3Q. I'm still not sure how this helps your argument, but I thought I'd mention I was wrong in my first reading. -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On 11622 March 1977, Charles Plessy wrote: The goal of this GR is still unclear to me, and I would welcome a preamble that clearly explains what problem is being solved. The goal is to change the needed seconds for a GR. For the moment I do not know if the problem is the multiplication of the amendments in the Lenny GR, No. the fact that the lenny GR could even being started, No, as the change of the requirements will *not* mean that such a GR cant be started. Nor should it mean this. the fact that an override vote could be started to force a delegate to postpone his decisions, Reread my proposal, I deliberately made that only need half the seconds than normal GRs. -- bye, Joerg aj vorlon: would it be less subtle if we replaced red, green and yellow with black, white and a shade of grey? vorlon aj: and this is what a necrotic port looks like? aj vorlon: the arch qualification table, halloween edition? aj vorlon: i heard a faint pinging, and went to the firewall and what greeted my eyes? AN m68k RISED FROM THE GRAVE!!! -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
MJ Ray wrote: to reduce GRs, having another way for developers to ask a question that nearly always gets answered might help. Such as, say, writing an email to debian-de...@ldo? -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Hi :) Neil McGovern wrote: Thanks for bringing this up. I feel that 2Q is possibly too large however. I'd suggest: Therefore the Debian project resolves that: a) Section 4.2 of the Debian Constitution is amended, replacing all references to K with Q. b) 4.2.7 is reworded to state: Q is half of the square root of the number of current Developers. Q need not be an integer and is not rounded. So we have Q people in case of floor(Q)==Q and floor(Q)+1 otherwise? Cheers, Bernd -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Ron r...@debian.org wrote: On Fri, 02 Jan 2009, MJ Ray wrote: In the past, I've seen considerable resistance to vote topics being discussed outside -vote, unless they're by one of a few popular DDs. Do supporters of nQ expect this situation to change, only those popular DDs be able to propose GRs, or can someone suggest acceptable ways of recruiting seconds outside -vote? Do you advocate the current situation to NOT change? [...] No. I accept a change may be worthwhile, but 2Q seems very high and suggested without reason. (See my other messages on the topic.) Do you really think it would have been difficult to obtain 2Q seconds for a resolution to recall the previous vote, and postpone it until some of the more obvious glitches had been better ironed out? [...] Yes, based on the summary of other votes by Wouter Verhelst and others. So, are supporters hoping this situation will change, only a few well-connected DDs will be able to propose GRs, or what? We seem to have totally lost the goal of making decisions that affect many or all developers by consensus. The process of building consensus revolves around satisfying the concerns of people who see problems with your planned course of action to arrive at a Better Solution. If you can't get the consensus of around 30 people to begin with, it doesn't take a degree in advanced math or political science or military strategy to arrive at the conclusion that you are a LONG WAY from having the consensus of the whole project. In general, that's correct. In particular, if you need 30 people just to *start* the discussion period, that's going to kill many potential options before they have any chance of building consensus and others will be far too entrenched by the time public discussion starts; also, it's 30 DDs, not 30 people. By way of example, this proposal was not some off-the-hip idea of Joerg's. It has already been discussed to the point of little (or rather no) objection in another forum, and has in-principle support from quite a few people. Could someone link to that discussion, please? It may contain answers to questions being asked now. You'll note it was not proposed as a vote, even though it could easily get the required number of seconds to do so, but rather as a discussion point to further build that consensus among a wider forum, and hone some of the little (but important) details. I applaud that it appeared pre-proposal[!], but I think the emphasis is on building a majority (not consensus). The discussion so far seems to have consisted of Joerg[*] and others defending the proposal as it currently stands, rather than engaging in any consensus-building. There was one question[+] but no follow-up on that in a week, so I've moved from seeking amendments, to emphasising the profound problems in the proposal, in the hope of getting follow-up or at least avoiding that first public draft continuing. * - http://lists.debian.org/debian-project/2008/12/msg00191.html http://lists.debian.org/debian-project/2008/12/msg00192.html http://lists.debian.org/debian-project/2008/12/msg00193.html + - http://lists.debian.org/debian-project/2008/12/msg00195.html That you seem to now be waging a 'campaign' against it, does seem to indicate that you have quite missed the point. How about we drop this war-word 'campaign', Fine by me: I didn't introduce 'campaign' to this aspect of the discussion. and you instead come up with a concise list of your concerns, so that we make take them to build a better proposal rather than load them into a vote option as ammunition to try and shoot it down. I don't want this to get just enough support to squeak by, I want everyone to agree on the problem and give their best to finding a solution that they like. Here's a summary list of concerns I mentioned in other emails:- 1. 2Q is unjustified and excessive; 2. the obvious spoiler effect may exclude consensus options prematurely (interaction of thresholds and Condorcet voting); 3. it favours organised campaign groups who gather in secret before springing discussion on debian lists; 4. it encourages defending proposals too early, during the discussion period. I think your comparisons to local government councils as 'similar' organisations is a misdirection. You say any constituent may take something to the council which they must then vote on. [...] No, I never said that. Any constituent may ask something of the council which (as I understand it) we must then answer - it rarely results in a vote because most questions are matters of fact. However, DDs have nothing similar in the debian project - to reduce GRs, having another way for developers to ask a question that nearly always gets answered might help. But if one thinks comparisons to local government councils are a misdirection, what about company boards or the ICANN At Large? Or what about providing some other, better comparisons or analyses from *outside*
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Michael Goetze mgoe...@mgoetze.net wrote: MJ Ray wrote: to reduce GRs, having another way for developers to ask a question that nearly always gets answered might help. Such as, say, writing an email to debian-de...@ldo? On inspection, that works more than I thought, but it seems to work better for some tasks (ftpmaster team seem to answer ~70% of questions asked about that work there, for example) than others. IIRC there's no certainty that anyone in particular reads debian-devel, so how often does asking on debian-devel work? Regards, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Do you advocate the current situation to NOT change? [...] No. I accept a change may be worthwhile, but 2Q seems very high and suggested without reason. (See my other messages on the topic.) After all the mails in the thread, I *think* I go and propose something very similar to what I initially had, and then either propose an amendment myself that takes the lower value of Q only[1], or wait for someone else to do that. I think its best we end up with 2 options on the vote, 1) Increase requirements to 2Q [3:1] 2) Increase requirements to Q [3:1] and also the usual Further Discussion, which would be for everyone who wants to keep the current state of 5 people. That, IMO, should fit everyone. [1] Yes, the proposer can also propose an amendment. And doesnt need to accept it to change the initial proposal, so ending up with two vote options. (Assuming it gets enough seconds). In general, that's correct. In particular, if you need 30 people just to *start* the discussion period, that's going to kill many potential options before they have any chance of building consensus and others will be far too entrenched by the time public discussion starts; also, it's 30 DDs, not 30 people. You wont need Q, 2Q, Q^1024 people to start a discussion period. This whole thread didnt need a single second to run like it is, usually all our flames don't need them. Yes, this is not the formal discussion period, but if you fear you wont get enough seconds, or might not be sure its the best to do, going the way I did with this seems to be ok, and able to draw attention from people. You'll note it was not proposed as a vote, even though it could easily get the required number of seconds to do so, but rather as a discussion point to further build that consensus among a wider forum, and hone some of the little (but important) details. I applaud that it appeared pre-proposal[!], but I think the emphasis is on building a majority (not consensus). The discussion so far seems to have consisted of Joerg[*] and others defending the proposal as it currently stands, rather than engaging in any consensus-building. Of course I do defend what I want. Yet, I still read and keep in mind what others think. Here's a summary list of concerns I mentioned in other emails:- 1. 2Q is unjustified and excessive; I did justify it. If you cant find 30 people out of 1000 that are in the project, why bother 1000 to vote on it?. 3. it favours organised campaign groups who gather in secret before springing discussion on debian lists; Umm. If you think so. I'd welcome other examples, particularly if the minimum is equivalent to anything like the 30 or 60 in the original proposal. Which 60? Its 30 (2Q) or its 15 (Q) what seems to be wanted. Also, if this reform doesn't work and we have trouble finding 30 seconds for necessary resolutions, then I fear we'll have trouble finding 30 seconds for another internal-policy bugfix resolution. I'd feel safer if this was a limited-time trial at first, or at least the previous SRP could be used to modify it, as a safeguard. So you think if something is clearly found to be a mistake at some point, the DDs wouldnt be able to admit it and revert it? It *only* takes 30 people to start that. -- bye, Joerg madduck and yes, the ftpmasters are not the most clueful people pgp0ULUM2pH8f.pgp Description: PGP signature
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Mon, Jan 05, 2009 at 05:42:20PM +0100, Bernd Zeimetz wrote: Neil McGovern wrote: Thanks for bringing this up. I feel that 2Q is possibly too large however. I'd suggest: Therefore the Debian project resolves that: a) Section 4.2 of the Debian Constitution is amended, replacing all references to K with Q. b) 4.2.7 is reworded to state: Q is half of the square root of the number of current Developers. Q need not be an integer and is not rounded. So we have Q people in case of floor(Q)==Q and floor(Q)+1 otherwise? I.e., ceil(Q) ? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On 05/01/09 at 23:37 +0100, Joerg Jaspert wrote: Do you advocate the current situation to NOT change? [...] No. I accept a change may be worthwhile, but 2Q seems very high and suggested without reason. (See my other messages on the topic.) After all the mails in the thread, I *think* I go and propose something very similar to what I initially had, and then either propose an amendment myself that takes the lower value of Q only[1], or wait for someone else to do that. I think its best we end up with 2 options on the vote, 1) Increase requirements to 2Q [3:1] 2) Increase requirements to Q [3:1] and also the usual Further Discussion, which would be for everyone who wants to keep the current state of 5 people. That, IMO, should fit everyone. Agreed: there's no point discussing which number of seconders you want to require now, we just need a ballot with several options. I would also like options: - to explicitely say that we want to stay with 5 (no further discussion needed) - that we want to increase the requirements to 10. (it would probably be a popular compromise between the current 5 and Q) It would be better if you could draft a ballot with all those options yourself (maybe together with someone else). That way, we would have a unified, comprehensible set of options. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | signature.asc Description: Digital signature
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Hi all, we could even go further and change towards a paradigm similar to Demexp (demexp.org): permanent vote. For non-anonymous votes it is very easy: when the number of seconders is more than half of the number actively voting developers, the GR is accepted. We could for instance define it as half the number of voters to the yearly DPL election. Have a nice day, (and please stop cross-posting). -- Charles Plessy -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Sat, Jan 03, 2009 at 05:27:26PM -0800, Don Armstrong wrote: On Sat, 03 Jan 2009, Chris Waters wrote: On Fri, Jan 02, 2009 at 09:17:28AM +1100, Ben Finney wrote: (Don has, after subsequent argument, modified this to “… that you don't plan on ranking above Further Discussion”.) Bad, bad idea! What if you are planning to rank Further Discussion as 1, but staill have a compromise you'd be willing to accept that you think is _far_ better than anything _else_ that's been proposed? If you're willing to accept a compromise, you rank it above further discussion. The very point of ranking FD above an option is to indicate that you don't find a specific option an acceptable solution at all, and would rather have futher discussion than accepting it. I still don't see any reason why someone shouldn't be able to propose an option they find less unacceptable than the options already on the table. Just because you don't want any of them doesn't mean that you can't think some options are worse than others. I am also offended at the suggestion that ranking FD highly means you can't accept compromise. And how are we going to police this nonsense? Check the votes afterwards and sanction someone if they proposed or seconded an option and then didn't support it with their vote? That's just stupid. In fact, the whole notion of restricting options is stupid. If we're going to go to the trouble of having a vote, we owe it to ourselves to make sure that the right options are all available. -- Chris Waters | Pneumonoultra-osis is too long xt...@debian.org | microscopicsilico-to fit into a single or xt...@speakeasy.net | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
This one time, at band camp, Chris Waters said: I am also offended at the suggestion that ranking FD highly means you can't accept compromise. I'm sorry if you feel offended, but that's exactly what FD is supposed to mean. The only reason to vote FD is if you can't compromise on any of the options on the ballot. -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Sun, Jan 04, 2009 at 10:07:51PM +, Stephen Gran wrote: This one time, at band camp, Chris Waters said: I am also offended at the suggestion that ranking FD highly means you can't accept compromise. I'm sorry if you feel offended, but that's exactly what FD is supposed to mean. The only reason to vote FD is if you can't compromise on any of the options on the ballot. Hogwash! If that's the case, we should simply discard any rankings on a ballot below FD, AND we need to start offering an option for I prefer none of these, but would be willing to compromise. Because not wanting any of the options, but still having (strong) opinions on which are more and which are less desirable is still a valid position--one I find myself in frequently IRL. So, according to your view of voting, if I actually would prefer further discussion (meaning that literally, and not with whatever magical special meaning you think it has on a Debian ballot), but am still willing to compromise and have opinions about which of the options I don't like are better than others, what should I do? Not express my honest opinion (that further discussion would be better)? And possibly allow my very-least-favorite option to win through inaction? That's ridiculous! If I followed your suggestion about what it's supposed to mean (according to whom, BTW?), I couldn't vote honestly--I would have to vote strategically, supporting positions I don't support, unless I gave up hope completely. Sorry, not going to happen. -- Chris Waters | Pneumonoultra-osis is too long xt...@debian.org | microscopicsilico-to fit into a single or xt...@speakeasy.net | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Chris Waters xt...@debian.org writes: So, according to your view of voting, if I actually would prefer further discussion (meaning that literally, and not with whatever magical special meaning you think it has on a Debian ballot), but am still willing to compromise and have opinions about which of the options I don't like are better than others, what should I do? You should rank the options in the order you prefer them: by your description, rank “Further Discussion” as 1, one or more other options as 2, some other option(s) as 3, and so on to reflect your preferences. Why is this such a confusing issue? -- \ “Liberty, n. One of imagination's most precious possessions.” | `\ —Ambrose Bierce, _The Devil's Dictionary_, 1906 | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Fri, 02 Jan 2009, MJ Ray wrote: Don Armstrong d...@debian.org wrote: If an option can't get seconds enough to pass K (or Q), it doesn't have support in the DD population or the proposers are lazy, and don't want to find enough support. In either case, people's time shouldn't be wasted with the effort required to run a vote and vote in it. Amen. In the past, I've seen considerable resistance to vote topics being discussed outside -vote, unless they're by one of a few popular DDs. Do supporters of nQ expect this situation to change, only those popular DDs be able to propose GRs, or can someone suggest acceptable ways of recruiting seconds outside -vote? Do you advocate the current situation to NOT change? Indeed the whole purpose of this proposal is that things MUST change. It seems quite clear that recent (ab)uses of the GR process have had little positive and immense negative affects on the project. And I don't mean that in the sense that My Favourite Option May Have Lost -- I mean that it created massive division and even outright hostility between members of a project that was only just beginning to show some signs of healing from the rifts created by previous votes. Do you really think it would have been difficult to obtain 2Q seconds for a resolution to recall the previous vote, and postpone it until some of the more obvious glitches had been better ironed out? Release early and often is not a principle we should transmute to calling votes. We seem to have totally lost the goal of making decisions that affect many or all developers by consensus. The process of building consensus revolves around satisfying the concerns of people who see problems with your planned course of action to arrive at a Better Solution. If you can't get the consensus of around 30 people to begin with, it doesn't take a degree in advanced math or political science or military strategy to arrive at the conclusion that you are a LONG WAY from having the consensus of the whole project. By way of example, this proposal was not some off-the-hip idea of Joerg's. It has already been discussed to the point of little (or rather no) objection in another forum, and has in-principle support from quite a few people. You'll note it was not proposed as a vote, even though it could easily get the required number of seconds to do so, but rather as a discussion point to further build that consensus among a wider forum, and hone some of the little (but important) details. That you seem to now be waging a 'campaign' against it, does seem to indicate that you have quite missed the point. How about we drop this war-word 'campaign', and you instead come up with a concise list of your concerns, so that we make take them to build a better proposal rather than load them into a vote option as ammunition to try and shoot it down. I don't want this to get just enough support to squeak by, I want everyone to agree on the problem and give their best to finding a solution that they like. I think your comparisons to local government councils as 'similar' organisations is a misdirection. You say any constituent may take something to the council which they must then vote on. A better comparison of that scope would be the tech-ctte. Any developer can take a matter to them. The similarity is that both groups of 'voters' are an 'expert panel' anointed by their peers to make such a decision. A better comparison to the case we are concerned with here would be a referendum or plebiscite, where every constituent, informed or not, is called upon to cast their lot for one option or another. I don't know of anywhere else in the world where such a small minority can call for a poll of that magnitude. They are very expensive to run, in every sense of that word, and so come with very great risks for all concerned. I don't believe the initially proposed levels of 2Q and Q are too high, or will prove stifling for genuine issues that concern the project as a whole. If anything I believe they are still too low for a consensus based system to resort to a vote, but it is a conservative step in the right direction, the effect of which we will be able to then gauge. If it really is a terrible mistake, and proves so in practice, I likewise don't think we'll have any trouble finding 30 seconds for a resolution to reverse or modify it in some more suitable way. As a further practical proof of practicing what I'm hoping for here, you may note that I say this not as a member of the self-select few that are regulars in these forums, but as a concerned member of a project who just wants to Get The Things Done That We Are Supposed To Be About. Minimising the number of votes we hold where the options have been composed by small warring factions that are hostile to each other's opinions seems to be a good start to minimising the time I must waste being conscripted to one militia or the other, against my will and better judgement, for the final
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, Jan 03, 2009 at 06:41:56PM +1030, Ron wrote: It seems quite clear that recent (ab)uses of the GR process have had little positive and immense negative affects on the project. And I don't mean that in the sense that My Favourite Option May Have Lost -- I mean that it created massive division and even outright hostility between members of a project that was only just beginning to show some signs of healing from the rifts created by previous votes. Those affects on the projects are part of a _social_ problem: lack of consensus about the importance of release schedule. Some find it more important to release than e.g. ensuring consensus on the purity of what we release. Others have the opposite opinion. Raising the bar of getting items on GRs will not solve this underlying social problem. Is a technical solution to a social problem. And as such it will fail. The technical aspect of raising the bar will no doubt succeeed, however: higher thresholds will move more of the decision making process from happening among all voters to only among politically active ones (those actively participating at the d-vote mailinglist). The question is not if we want less hostility in the project (because this technical change cannot change that). The question is how much noise reduction we want in our voting process. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAklfXgoACgkQn7DbMsAkQLhHewCeNrhoqCQWp1Q9sAczP8tx5uOs q6MAnR6NXoIfmiU2V6FcCIXzt5+b7Ih+ =MsSj -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Mon, Dec 29, 2008 at 09:47:39PM -0800, Russ Allbery wrote: I'm not sure that I find it usefully different, unless what you're proposing is a compromise that you hope everyone will be able to agree upon. I think that's a hugely important ability. I'm also worried that setting the thresholds too high for alternatives may skew the available options in the direction of the opinions of those who spend too much time following the political process and away from the rank-and-file who are more concerned with making an operating system. For this reason, while I support the idea of increasing the number of supporters to _start_ a GR, I'd like to keep the number required to add an _alternative_ at K! Once we realize that there's really a decision to make, I think we should make sure that as many options are on the table as possible! Otherwise we risk being forced to decide between two extremist positions (one possibly represented by none of the above/further discussion) with no compromises available. Writing options that you don't personally agree with is full of problems. It's very difficult to be objectively fair in capturing an option that you don't believe in and wouldn't argue for. I'd much rather see the people who really believe in an option step forward to propose it. I think that too few people bother to track the active political discussions (I'm one who usually doesn't) to make that a viable position. Furthermore, it prevents those who support the status quo from proposing _anything_, even a compromise they could live with. And I think that's a _very_ bad idea! Personally, I think that if you're willing to rank something higher than at least _one_ of the available options (including further discussion), you should be allowed to propose it. With Condorcet voting and Further Discussion, there seems to be little point in trying to flesh out a ballot with all possible distinct options just out of some sense of completeness. If one of those options that no one seconded turns out to be what the rest of the project who wasn't participating in the proposal process wanted, that's what Further Discussion is for (and I expect that to be quite rare). The problem is that because we don't have an official none of the above, further discussion is usually interpreted as none of the above. And, as you say, voting for further discussion is fairly rare, for exactly that reason. Furthermore, if we're going to make it harder to get GRs started, I think it's _vital_ that we make sure the GRs are done right, and IMO, that means making sure that all the options are on the table. As far as I'm concerned, the ideal outcome of a GR discussion isn't a ballot with all options represented. It's a project-wide consensus on the best course of action. That sounds like a wonderful goal in a perfect world and absolutely _terrifying_ in the real world we actually live in! If this were an ideal world, and we were all perfectly logical machines, we wouldn't need to vote because the ideal solution to every problem would be equally obvious to everyone. But it's not and we aren't, so I think it is _vitally_ important to offer options to help avoid the dictatorship of the overly-political. -- Chris Waters | Pneumonoultra-osis is too long xt...@debian.org | microscopicsilico-to fit into a single or xt...@speakeasy.net | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Fri, Jan 02, 2009 at 09:17:28AM +1100, Ben Finney wrote: (Don has, after subsequent argument, modified this to “… that you don't plan on ranking above Further Discussion”.) Bad, bad idea! What if you are planning to rank Further Discussion as 1, but staill have a compromise you'd be willing to accept that you think is _far_ better than anything _else_ that's been proposed? I think the best solution is simply to say, don't propose (or second) something you're not willing to live with. -- Chris Waters | Pneumonoultra-osis is too long xt...@debian.org | microscopicsilico-to fit into a single or xt...@speakeasy.net | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Fri, Jan 02, 2009 at 12:50:21PM +0100, Bernhard R. Link wrote: * Adeodato Simó d...@net.com.org.es [090101 23:36]: No. In my opinion, an option in the ballot is (should be) a very scarce resource. Like you would in a situation of limited water supply in a boat shared with friends, you should act responsibly and not consume one unit unless painstakingly necessary. I massively disagree here. Me too. In fact, I might go so far as to say that I couldn't possibly disagree more! [ 1 ] Harder to start GRs, but just as easy to add an option [ 4 ] Harder to start GRs or add options [ 3 ] Further discussion [ 2 ] No. Just no. :) Part of the problem is that we never have no, just no on our ballots, so the only alternative is to vote further discussion, even if you have no interest whatsoever in any further discussion, and, as far as you're concerned, the matter is settled. The flip side of this is that people can be (I know I can be) reluctant to vote further discussion, because it feels like you're voting no, just no. So, if it's harder to add options, people are more likely to vote for choices they really don't like. (I know that I have.) -- Chris Waters | Pneumonoultra-osis is too long xt...@debian.org | microscopicsilico-to fit into a single or xt...@speakeasy.net | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Sat, 03 Jan 2009, Chris Waters wrote: On Fri, Jan 02, 2009 at 09:17:28AM +1100, Ben Finney wrote: (Don has, after subsequent argument, modified this to “… that you don't plan on ranking above Further Discussion”.) Bad, bad idea! What if you are planning to rank Further Discussion as 1, but staill have a compromise you'd be willing to accept that you think is _far_ better than anything _else_ that's been proposed? If you're willing to accept a compromise, you rank it above further discussion. The very point of ranking FD above an option is to indicate that you don't find a specific option an acceptable solution at all, and would rather have futher discussion than accepting it. Don Armstrong -- Of course, there are cases where only a rare individual will have the vision to perceive a system which governs many people's lives; a system which had never before even been recognized as a system; then such people often devote their lives to convincing other people that the system really is there and that it aught to be exited from. -- Douglas R. Hofstadter _Gödel Escher Bach. Eternal Golden Braid_ http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Sat, 03 Jan 2009, Chris Waters wrote: Part of the problem is that we never have no, just no on our ballots, so the only alternative is to vote further discussion, even if you have no interest whatsoever in any further discussion, and, as far as you're concerned, the matter is settled. You can easily propose and/or second an option that reaffirms the status quo if you think the matter should be settled completely. If not enough people second it, then the status quo isn't acceptable to enough people in the project for it to be a viable option. So, if it's harder to add options, people are more likely to vote for choices they really don't like. (I know that I have.) The idea is to make it more difficult to add options so that options that have no chance of winning are not added. Secondarily, it's to try to get people to spend more time in the deliberation stage to perfect the options and achieve compromise before an option ends up on the ballot. Ideally this will mean that we'll have options that represent large parts of the project, with compromises that are acceptable to all of the project, with no options that are only acceptable to small parts of the project. Don Armstrong -- The attackers hadn't simply robbed the bank. They had carried off everything portable, including the security cameras, the carpets, the chairs, and the light and plumbing fixtures. The conspirators had deliberately punished the bank, for reasons best known to themselves, or to their unknown controllers. They had superglued doors and shattered windows, severed power and communications cables, poured stinking toxins into the wallspaces, and concreted all of the sinks and drains. In eight minutes, sixty people had ruined the building so thoroughly that it had to be condemned and later demolished. -- Bruce Sterling, _Distraction_ p4 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
* Adeodato Simó d...@net.com.org.es [090101 23:36]: The people who do care about such an option winning have at least as much freedom to decide as they did before the option was proposed. They can decide whether they want to propose their own wording, or to second the wording as already proposed, or anything else. No. In my opinion, an option in the ballot is (should be) a very scarce resource. Like you would in a situation of limited water supply in a boat shared with friends, you should act responsibly and not consume one unit unless painstakingly necessary. I massively disagree here. An option on an ballot is there to allow the voters to express what should be done. Without this it just ends up in a who suggested something in that direction first play. We don't need condorcet when we are afraid of people using the democracy introduced by it. (Too many options might be bad, but better having too many but to less, as the first suggestor throw out the water tank as he suggested everyone should drink salt water and there is enough of it...) Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Don Armstrong d...@debian.org wrote: On Tue, 30 Dec 2008, Wouter Verhelst wrote: In general, I believe it is okay to second a ballot option that you do not plan to rank first if you feel it is an important matter that you want to see resolved. The statement I second this proposal only means I want to see this voted on, not I support this statement, and I think that's a good thing. I disagree. We shouldn't be having votes or options on the ballot purely for the sake of having votes or options on the ballot. Our voting process exists to resolve conflicts in a manner that DDs support; having options that DDs do not support on the ballot does not help that process. Sorry - I'm with Wouter Verhelst on this. Having options on the ballot that only a small minority of DDs support can help resolve conflicts: it lays them to rest, demonstrating they fail in the wider DD population, rather than the DDs supporting them being able to blame the self-selecting subset who participate on debian-vote. Even if the number of seconds for a proposal is raised to something massive like 2Q, would it be worth keeping the number of seconds for a partial amendment at K? If we're going to have the trouble of votes, we might as well vote as comprehensively as possible... (To do this, I'd probably add to the end of A.1.2 A partial amendment is one which changes only one point of the resolution. and add to 4.2.1 after other Developers, the words or if it is a partial amendment sponsored by at least K other Developers, and keep K defined.) I'd also support voting on groups of conflicting proper amendments *before* voting on the full resolution options, as happens in councils, many business boards and so on. The aim is to have the most consensual of each of the necessarily alternative options in the main vote. The cost is a more complicated voting procedure, as far as I can see. (To do this, I'd probably replace single ballot that in A.3.1 with up to two ballots. If there are any partial amendments, a preliminary ballot includes a vote for each point of the original resolution and each non-partial amendment and with each vote having options for the original text and for each partial amendment to that point. The final ballot and replace , each amendment with (as amended by any preliminary ballot), each non-partial amendment (as amended by any preliminary ballot). I'd love a simpler solution if anyone knows one.) Regards, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Fri, 02 Jan 2009, MJ Ray wrote: Sorry - I'm with Wouter Verhelst on this. Having options on the ballot that only a small minority of DDs support can help resolve conflicts: it lays them to rest, demonstrating they fail in the wider DD population, If an option can't get seconds enough to pass K (or Q), it doesn't have support in the DD population or the proposers are lazy, and don't want to find enough support. In either case, people's time shouldn't be wasted with the effort required to run a vote and vote in it. rather than the DDs supporting them being able to blame the self-selecting subset who participate on debian-vote. If DDs who support them are unable to gather enough seconds via -vote, nothing stops them from finding other people who support the proposal using other methods. Furthermore, there are at least 103 DDs subscribed to -vote[1], so arguments about some self-selecting subset are a bit misplaced (not that that'll stop them from being made.) Even if the number of seconds for a proposal is raised to something massive like 2Q, would it be worth keeping the number of seconds for a partial amendment at K? If we're going to have the trouble of votes, we might as well vote as comprehensively as possible... Additional options on a ballot means that voters have to spend additional time to process the option and differentiate it between all other options. When multiplied by the number of people who vote, that becomes a non-trivial waste of voter's time for options which couldn't find enough seconders who actually support the option. If an option can't get enough seconds from people who support that option to satisfy K (or even Q), not enough people support it for it to have a chance of being supported by a majority of people in an election that meets quorum. Don Armstrong 1: 102 subscriptions with @debian.org$ addresses, anyway. (For comparison, there are 147 subscribed to -devel, 112 to -project, and 324 to d-d-a.) I've no clue about actual DD readership or whether people actually read it or /dev/null it. Maybe they use it in place of almanacs in their out buildings. -- Three little words. (In descending order of importance.) I love you -- hugh macleod http://www.gapingvoid.com/graphics/batch35.php http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On 31/12/08 at 12:35 -0600, Gunnar Wolf wrote: Don Armstrong dijo [Mon, Dec 29, 2008 at 04:18:02PM -0800]: (...) You should not be proposing or seconding an option that you don't plan on ranking first. (or high, as others have said in this thread) I am not sure about this... Sometimes you are interested in creating a rich enough set of options to get a fair spread of options to be voted on. Supporting/endorsing/seconding an option should not IMHO mean I want this option to be ranked high, but I believe this option should appear in the ballot - Even if you don't personally agree with it. I agree with that POV. GR are obviously a way to make decisions, but they are also a way to get an idea about the general opinion of developers. As such, it is sometimes useful to add options to the ballot, when the meaning of Further Discussion can be intrepreted in various ways. For example, in the recent developer status GR, we clearly needed an option to say I agree with those changes, and the way they were announced, because, even for DAM, it was probably unclear whether FD meant please go ahead or let's just discuss this further. Actually, this could be solved by allowing seconders to add a one-sentence summary of the reasons why they seconded something. For example, saying I don't support that option, but I think that it should be on the ballot. That rationale could be displayed on the vote page. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
* Ben Finney [Tue, 30 Dec 2008 11:43:44 +1100]: Don Armstrong d...@debian.org writes: You should not be proposing or seconding an option that you don't plan on ranking first. This seems quite wrong. Why should one not carefully and precisely phrase and propose an option that one does *not* agree with, in order to get it voted on? I can't believe I'm reading this. You should not write options you are not going to rank first, because the people who do care about that option winning should get to decide what's the wording that reflects their complete opinion and concerns. (On the other hand, I think seconding is different, and that it should be okay to second stuff even just because I think it's good for it to be on the ballot.) -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Que no te vendan amor sin espinas -- Joaquín Sabina, Noches de boda -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Adeodato Simó d...@net.com.org.es writes: * Ben Finney [Tue, 30 Dec 2008 11:43:44 +1100]: Don Armstrong d...@debian.org writes: You should not be proposing or seconding an option that you don't plan on ranking first. (Don has, after subsequent argument, modified this to “… that you don't plan on ranking above Further Discussion”.) This seems quite wrong. Why should one not carefully and precisely phrase and propose an option that one does *not* agree with, in order to get it voted on? I can't believe I'm reading this. I think perhaps you're reading more into it than I wrote. You should not write options you are not going to rank first, because the people who do care about that option winning should get to decide what's the wording that reflects their complete opinion and concerns. The people who do care about such an option winning have at least as much freedom to decide as they did before the option was proposed. They can decide whether they want to propose their own wording, or to second the wording as already proposed, or anything else. -- \ “I'm having amnesia and déjà vu at the same time. I feel like | `\ I've forgotten this before sometime.” —Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
* Ben Finney [Fri, 02 Jan 2009 09:17:28 +1100]: You should not write options you are not going to rank first, because the people who do care about that option winning should get to decide what's the wording that reflects their complete opinion and concerns. The people who do care about such an option winning have at least as much freedom to decide as they did before the option was proposed. They can decide whether they want to propose their own wording, or to second the wording as already proposed, or anything else. No. In my opinion, an option in the ballot is (should be) a very scarce resource. Like you would in a situation of limited water supply in a boat shared with friends, you should act responsibly and not consume one unit unless painstakingly necessary. This is, of course, my opinion, and you're welcome to disagree. Also, I'll probably won't be interested in discussing this any further, so please don't take my lack of answer to your next message as lack of disagreement. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Vanessa-Mae - Doun -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Adeodato Simó d...@net.com.org.es writes: * Ben Finney [Fri, 02 Jan 2009 09:17:28 +1100]: You should not write options you are not going to rank first, because the people who do care about that option winning should get to decide what's the wording that reflects their complete opinion and concerns. The people who do care about such an option winning have at least as much freedom to decide as they did before the option was proposed. They can decide whether they want to propose their own wording, or to second the wording as already proposed, or anything else. No. In my opinion, an option in the ballot is (should be) a very scarce resource. Agreed. I don't see what in my position you're disagreeing with, but I'm likewise no longer interested in this side discussion as I feel it's already resolved a few days ago. We can leave it here. -- \ “It is far better to grasp the universe as it really is than to | `\persist in delusion, however satisfying and reassuring.” —Carl | _o__)Sagan | Ben Finney -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Tue, 30 Dec 2008, Wouter Verhelst wrote: On Mon, Dec 29, 2008 at 04:18:02PM -0800, Don Armstrong wrote: 1: I'd be happier, though, if those proposing and seconding options would be more careful about the effects that their options may have, and be more vigilant about withdrawing options when more palletable options exist. You should not be proposing or seconding an option that you don't plan on ranking first. Anthony Towns seconded his own recall vote, as DPL. Do you think he should not have done that? He voted 21 (FD over recall), so no. Of coure, that option had more than 5 othere seconds, each of whom voted 12, so it didn't do anything to cause us to vote on an option that we wouldn't of had a need to vote on otherwise. Since 48 people voted 12, the K (or Q, 1.5Q or 2Q) seconds could have easily come from them. I seconded both proposal B and proposal D on 2004_004, and did not rank both equally at number one (rather, I voted proposal B at 1, and proposal D at 2). Do you think I should not have done that? That's fine, since you ranked them both highly. There's a benefit to seconding options which represent compromises that you support. There's no benefit to seconding options which you do not, just to see them go down in flames in the election. [If an option cannot get the required number of seconders from people who actually support it, it's almost assuredly going down in flames in the election.] In general, I believe it is okay to second a ballot option that you do not plan to rank first if you feel it is an important matter that you want to see resolved. The statement I second this proposal only means I want to see this voted on, not I support this statement, and I think that's a good thing. I disagree. We shouldn't be having votes or options on the ballot purely for the sake of having votes or options on the ballot. Our voting process exists to resolve conflicts in a manner that DDs support; having options that DDs do not support on the ballot does not help that process. I view seconding as a trial run for a particular option involving a smaller number of people who vouch their support for that option so that the entire project does not have to be involved in dealing with options that do not have wide enough support to even have a chance of winning. Making the seconding process more difficult by increasing the number of seconds and trying to avoid seconding options that we ourselves do not support will help keep the project at large from wasting time reading and understanding ballot options that are not widely supported. Don Armstrong -- There's nothing remarkable about it. All one has to do is hit the right keys at the right time and the instrument plays itself. -- Bach http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Tue, 30 Dec 2008, Joerg Jaspert wrote: Anyway 2Q is too much in my opinion. Q would be much more reasonable. See my reply to Bernd why I think its not. It seems like most people who responded preferred Q up to now. It might end up as an amendment otherwise. :) It would be also be good to add a sentence inviting the seconders to explain why they second the proposal. At least it would make the many formal mails to second proposals somewhat interesting to read (they could even be linked from the vote web page so that voters who have not taken part in the discussion can refer to the reasoning of those who have brought the option to the vote). As a must or as a should? A should would probably work. A should. There's no point forcing anyone to justify his acts, but it's better if he does IMO. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Don Armstrong dijo [Mon, Dec 29, 2008 at 04:18:02PM -0800]: (...) You should not be proposing or seconding an option that you don't plan on ranking first. (or high, as others have said in this thread) I am not sure about this... Sometimes you are interested in creating a rich enough set of options to get a fair spread of options to be voted on. Supporting/endorsing/seconding an option should not IMHO mean I want this option to be ranked high, but I believe this option should appear in the ballot - Even if you don't personally agree with it. -- Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Mon, Dec 29, 2008 at 04:18:02PM -0800, Don Armstrong wrote: 1: I'd be happier, though, if those proposing and seconding options would be more careful about the effects that their options may have, and be more vigilant about withdrawing options when more palletable options exist. You should not be proposing or seconding an option that you don't plan on ranking first. Hm. Anthony Towns seconded his own recall vote, as DPL. Do you think he should not have done that? I seconded both proposal B and proposal D on 2004_004, and did not rank both equally at number one (rather, I voted proposal B at 1, and proposal D at 2). Do you think I should not have done that? In general, I believe it is okay to second a ballot option that you do not plan to rank first if you feel it is an important matter that you want to see resolved. The statement I second this proposal only means I want to see this voted on, not I support this statement, and I think that's a good thing. There is also a somewhat more strategic reason why you may want to propose or second an amendment for vote: the more extremist options have less of a chance to actually win the vote; when your option is perceived to be the most extremist one on the ballot, you may want to second or propose another option that is even more extremist, so that yours won't look as bad, and will have a chance of getting more votes. This kind of behaviour is not the kind of behaviour that I would like to see from my fellow developers, but - I don't think it's actually happening; and - Raising the bar wrt seconds will make this much harder, anyway. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Tuesday 30 December 2008, Joerg Jaspert wrote: this will mean that future GRs would need 30 other people to support your idea. While that does seem a lot (6times more than now), The main reason I'm somewhat uncomfortable with this is that in practice not all 1000 developers participate in a vote, but only about 300 (367 in last vote) or so. The number of developers following d-vote is also a lot lower than the total number of DDs. So effectively requiring 30 supporters means that you'll need support from a substantial portion of DDs following d-vote. I personally feel it is important that minority opinions do have a chance to be reflected on a ballot: there has to be something to choose. Could/should we distinguish between the number of supporters needed to propose a GR (i.e. for the initial proposal) and the number of supporters needed for amendments? Problem there is of course the fact that proposals may end up as amendments and vice versa. The last vote has also shown one other issue. In some cases it turns out that proposed amendments should really e voted on separately. In that case it would be good if the secretary could propose a voting order when splitting a ballot, but currently there is no mechanism by which a vote can be delayed. Example: first vote on whether or not to release Lenny and then hold a separate vote on Exclude source requirements for firmware and Empower release team proposals (probably with a new discussion period to allow proposal of suitable amendments). Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Jonas Smedegaard wrote: On Tue, Dec 30, 2008 at 01:50:37AM +0100, Bernd Zeimetz wrote: b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)], as well as resolutions against a shortening of discussion/voting period or to overwrite a TC decision [§4.2(2.3)] requires floor(Q) developers to sponsor the resolution. c) the definition of K gets erased from the constitution. [§4.2(7)] what I'd like to add here is something in the lines of d) If a resolution will affect an upcoming release which is already frozen, the resolution needs twice the number of sponsors as defined in a). This should help to avoid that some random people try to stop a release in the latest moment if there's not a really good reason to do so. If we want Debian to be used in business (enterprise *gasp*) installations, we should at least be able to tell people when we're about to release, without having them to fear a delay for months or years due to a GR. I disagree: Debian release when ready, not in time. Which is good! If anyone creates a vote close to (expected) release, then they have a good reason to do that. Which we should not suppress by designing our rules to favor releasing in time. If there's a good reason to create the GR I'm sure they'd find enough sponsors. Realeasing in time becomes more and more important these days - so I can't see anything wrong here. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joerg Jaspert wrote: I have felt for some time that the low requirement for seconds on General Resolutions is something that should be fixed. We are over 1000 Developers, if you can't find more than 5 people supporting your idea, its most probably not worth it taking time of everyone. Agreed, as you mentioned it's been talked about on IRC a few times recently. a) The constitution gets changed to not require K developers to sponsor a resolution, but floor(2Q). [see §4.2(1)] In my opinion that's too high. I'd be more comfortable with K = Q. this will mean that future GRs would need 30 other people to support your idea. While that does seem a lot (6times more than now), Actually, 31 (depending on where you do the rounding/truncation which would have to be specified or there will be arguments). regards, Colin - -- Colin Tuckley | +44(0)1903 236872 | PGP/GnuPG Key Id Debian Developer | +44(0)7799 143369 | 0x1B3045CE Error 1232: Windows has run out of errors. Run Windows Update to download more. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAklZ8GwACgkQj2OPlhswRc5VDACeIOiS1PqtAV2UHnbL6PBvY5Zx H+YAoOu3jVtcVDhN/LnaKzUL59KoDB/i =h6uM -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Therefore the Debian project resolves that a) The constitution gets changed to not require K developers to sponsor a resolution, but floor(2Q). [see §4.2(1)] not sure if we need floor(2Q) here, but at least floor(Q). It is 2Q as I do want a seperation to the one in b) (to stop a delegate/DPL/the TC). And I dislike going below Q for any option, so b) has the lower, Q, and a is 2Q. Besides, its only 30 people with floor(2Q)... d) If a resolution will affect an upcoming release which is already frozen, the resolution needs twice the number of sponsors as defined in a). While I dislike the GR we just had so short before release I don't think making a special case for a release is good. If it is I want a special case for DAM too, every override of a DAM decision takes 6Q at least! Well, joking, the point is just that its an exception for one special case which I dislike. This should help to avoid that some random people try to stop a release in the latest moment if there's not a really good reason to do so. If we want Debian to be used in business (enterprise *gasp*) installations, we should at least be able to tell people when we're about to release, without having them to fear a delay for months or years due to a GR. Now, this proposal changes it from some random people counting to 5 up to 30. I think thats enough, if you find so many supporters for your GR, then yes, even a release might have to wait. -- bye, Joerg exa And mind you, I have always been respectful to every debian developer EXCEPT Branden. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
this will mean that future GRs would need 30 other people to support your idea. While that does seem a lot (6times more than now), Actually, 31 (depending on where you do the rounding/truncation which would have to be specified or there will be arguments). floor() in this case. Well, my idea was just to drop everything behind the .. So floor(), int(), whatever it is in your favorite language. :) -- bye, Joerg Oh mann, beim Backlog-Lesen sollte man weder essen noch trinken. Ihr schweine. -- Jörg Jaspert -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Tue, Dec 30, 2008 at 12:54:41AM +0100, Joerg Jaspert wrote: General Resolutions are an important framework within the Debian Project. Yet, in a project the size of Debian, the current requirements to initiate one are too small. Therefore the Debian project resolves that a) The constitution gets changed to not require K developers to sponsor a resolution, but floor(2Q). [see §4.2(1)] b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)], as well as resolutions against a shortening of discussion/voting period or to overwrite a TC decision [§4.2(2.3)] requires floor(Q) developers to sponsor the resolution. c) the definition of K gets erased from the constitution. [§4.2(7)] Hi Joerg, Thanks for bringing this up. I feel that 2Q is possibly too large however. I'd suggest: Therefore the Debian project resolves that: a) Section 4.2 of the Debian Constitution is amended, replacing all references to K with Q. b) 4.2.7 is reworded to state: Q is half of the square root of the number of current Developers. Q need not be an integer and is not rounded. Reasoning: a) Q people should be enough to start a GR. The use of the override a delegate's decision immediately is something that should not be taken lightly. This should still require 2Q. b) No more reference to K, tidy up. Keep the non-rounded float nature of Q. Cheers, Neil -- i get an error... i forget what it is ... but definitely an error, well, maybe a warning... or an informational message... but definitely an output Verbatim quote from #debian, irc.freenode.net, Sat Jan 12 00:31:16 GMT 2008 signature.asc Description: Digital signature
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Therefore the Debian project resolves that a) The constitution gets changed to not require K developers to sponsor a resolution, but floor(2Q). [see §4.2(1)] b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)], as well as resolutions against a shortening of discussion/voting period or to overwrite a TC decision [§4.2(2.3)] requires floor(Q) developers to sponsor the resolution. c) the definition of K gets erased from the constitution. [§4.2(7)] Thanks for bringing this up. I feel that 2Q is possibly too large however. I'd suggest: Therefore the Debian project resolves that: a) Section 4.2 of the Debian Constitution is amended, replacing all references to K with Q. b) 4.2.7 is reworded to state: Q is half of the square root of the number of current Developers. Q need not be an integer and is not rounded. Interesting, that makes it harder to stop a delegate as compared to my proposal. Not that thats bad. :) Reasoning: a) Q people should be enough to start a GR. The use of the override a delegate's decision immediately is something that should not be taken lightly. This should still require 2Q. Ok. Fine. b) No more reference to K, tidy up. Keep the non-rounded float nature of Q. Hm. Fine. So, those that spoke up yet mostly think Q instead of 2Q for normal GRs. Could change my text, its at least 3 times the size as of now, yes. Or we have 2 vote options, one for 2Q, one for Q. What makes more sense? Guess changing mine, to avoid confusion/too many options?! (All just dreaming ahead to a possible vote :) ) -- bye, Joerg * libpng2 no libpng3 no why ? because no yes no yes no yes bullshit no yes no yes no yes stop ? no when someday beep beep beep beep (Closes: #157011) -- Christian Marillat maril...@debian.org Thu, 29 Aug 2002 16:41:58 +0200 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Joerg Jaspert jo...@debian.org writes: Or we have 2 vote options, one for 2Q, one for Q. What makes more sense? Guess changing mine, to avoid confusion/too many options?! (All just dreaming ahead to a possible vote :) ) I don't think having options for 2Q and Q for resolution sponsoring makes the ballot too confusing, provided we don't end up with dozens of options. -- * Sufficiently advanced magic is indistinguishable from technology (T.P) * * PGP public key available @ http://www.iki.fi/killer * -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Joerg Jaspert jo...@debian.org wrote:
this will mean that future GRs would need 30 other people to support
your idea. While that does seem a lot (6times more than now),
considering that a GR affects more than 1000 official Developers and
uncounted amounts of other people doing work for Debian, I think its not
too much. Especially as point b only requires 15 people, 3 times the
amount than now, in case there is a disagreement with the DPL, TC or
a Delegate.
I think that's too much. A quick count of discussions around the
recent GR suggests that only 79 people participated and I'm sure
that included many non-DDs. Given that a reasonable ballot would
have 4 alternatives (one-off exception, permanent exception, no
exceptions ever and release team discretion) as well as
compromise options (which rarely appear at the minute), I think
finding 4 groups of 30 DDs from 79 posters is unlikely. If the
recent criticism of DDs who second worthy-but-not-preferred
options succeeds in discouraging them, it would be impossible.
What are the consequences of setting the bar too high? Well, I
think it would favour organised campaign groups, it encourages
clustering around flags too early rather than seeking compromises
and the first hint of voter fatigue will probably result in no
further options being added to the ballot. That would be fine if
people sought compromise *before* calling for seconds (as is
happening now) but there is no requirement for that and it
doesn't seem to have happened often in the archives.
What number of seconds do other systems require for a proposal?
If I remember rightly, my local council (3200 inhabitants - maybe
2400 eligible voters?) requires no seconds to put a question to a
council meeting (which must be addressed), one elected second to
propose a solution, something like 9 seconds to call an election
and one second to stand for election. It seems a remarkably
stable council.
My largest company (3 million voters) requires one elected second
to put a question to some meetings and I think five seconds for
others and two seconds to stand for election to the first
level (I don't know about higher levels).
I'd welcome other examples - or especially expert analysis.
In the absence of that, my current view is that floor(Q) for a GR
and floor(Q/2) for disagreements would be reasonable as the next
step. Why should it be more?
Note: I counted number of participants with the rc shell command:
; curl -s http://lists.debian.org/debian-vote/2008/^(10 11 12)^/ \
| sed -n -e '/DFSG/{;s/^.*em//;s/.*$//;p;}' | sort | uniq -c | wc -l
79
Hope that helps,
--
MJ Ray (slef)
Webmaster for hire, statistician and online shop builder for a small
worker cooperative http://www.ttllp.co.uk/ http://mjr.towers.org.uk/
(Notice http://mjr.towers.org.uk/email.html) tel:+44-844-4437-237
--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Dec 30, 2008 at 09:52:37AM +0100, Bernd Zeimetz wrote: Jonas Smedegaard wrote: On Tue, Dec 30, 2008 at 01:50:37AM +0100, Bernd Zeimetz wrote: b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)], as well as resolutions against a shortening of discussion/voting period or to overwrite a TC decision [§4.2(2.3)] requires floor(Q) developers to sponsor the resolution. c) the definition of K gets erased from the constitution. [§4.2(7)] what I'd like to add here is something in the lines of d) If a resolution will affect an upcoming release which is already frozen, the resolution needs twice the number of sponsors as defined in a). This should help to avoid that some random people try to stop a release in the latest moment if there's not a really good reason to do so. If we want Debian to be used in business (enterprise *gasp*) installations, we should at least be able to tell people when we're about to release, without having them to fear a delay for months or years due to a GR. I disagree: Debian release when ready, not in time. Which is good! If anyone creates a vote close to (expected) release, then they have a good reason to do that. Which we should not suppress by designing our rules to favor releasing in time. If there's a good reason to create the GR I'm sure they'd find enough sponsors. Realeasing in time becomes more and more important these days - so I can't see anything wrong here. What I find wrong is to design the fundamental rules so that release schedule is implicitly favored. Why require the double amount of sponsors for GRs close to release, if not because the release itself is considered valuable in itself? - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAklaJ+IACgkQn7DbMsAkQLiv9ACbBXLpWBEHxs9vGCppCbtwK9zF h8sAmgLhHcFg4sHAcAt9pEPU1+4aiXVH =GK8O -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Mon, Dec 29, 2008 at 04:18:02PM -0800, Don Armstrong wrote: Hi, 1: I'd be happier, though, if those proposing and seconding options would be more careful about the effects that their options may have, and be more vigilant about withdrawing options when more palletable options exist. You should not be proposing or seconding an option that you don't plan on ranking first. Well, let's say you should not propose or second an option you don't plan to rank above further discussion... Maybe you'll rank it lower than another option, but that's what the condorcet voting system allows us to (provide order of preference among acceptable options). An option that is not your favorite might still be very good for you as an outcome... :) Thanks, Guido -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Tue, 30 Dec 2008, Joerg Jaspert wrote: Therefore the Debian project resolves that a) The constitution gets changed to not require K developers to sponsor a resolution, but floor(2Q). [see §4.2(1)] not sure if we need floor(2Q) here, but at least floor(Q). It is 2Q as I do want a seperation to the one in b) (to stop a delegate/DPL/the TC). And I dislike going below Q for any option, so b) has the lower, Q, and a is 2Q. Besides, its only 30 people with floor(2Q)... I'd find 1.5Q more palatable. 30 people is not much when you compare it with 1000. But the ammount of people that are interested enough in Debian processes to actually notice there is something they would like to second is a lot less... In fact, while I find floor(1.5Q) acceptable, I'd rather have it at floor(Q). d) If a resolution will affect an upcoming release which is already frozen, the resolution needs twice the number of sponsors as defined in a). While I dislike the GR we just had so short before release I don't think making a special case for a release is good. If it is I want a special Agreed. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Tue, 30 Dec 2008, MJ Ray wrote: What are the consequences of setting the bar too high? Well, I think it would favour organised campaign groups, it encourages clustering around flags too early rather than seeking compromises This is a very compelling argument, and it convinced me that I shouldn't vote even for 1.5Q. I'd go for floor(Q) or less, but not more. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Tue, Dec 30, 2008 at 12:54:41AM +0100, Joerg Jaspert wrote: Practical changes: Taking the definitions of the latest GR we had, Current Developer Count = 1021 Q ( sqrt(#devel) / 2 ) = 15.9765453086705 Quorum (3 x Q ) = 47.9296359260114 this will mean that future GRs would need 30 other people to support your idea. While that does seem a lot (6times more than now), considering that a GR affects more than 1000 official Developers and uncounted amounts of other people doing work for Debian, I think its not too much. Well, I disagree on that point. I just had a look at the vote.debian.org pages, checking those votes where the number of seconds exceeded 10, and found only the following ones: - Proposal F on the last vote; 17 seconds - Proposal A on 2008_002 (membership); 21 seconds - Proposal A on 2007_004 (length DPL election); 20 seconds - Amendment A on 2006_001 (GFDL); 15 seconds - Proposal E on 2004_004 (sarge release after 2004_003): 16 seconds - Amendment on 2004_002 (status of non-free): 12 seconds That's 6 out of 16 votes where _one_ amendment or proposal had more than 10 seconds; many of them had more than one amendment or proposal, but none of them had two amendments or proposals with more than 10 seconds. Now I do realize and agree that many people will probably not second something anymore once a sufficient number of seconds has been issued; but I think that, all things considered, 30 may be too much. I'm not saying that raising the bar a bit isn't a good idea; and I also fully agree that having this number depend on the number of developers is a good idea. However, raising the bar sixfold in one go is pushing it, IMO. -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Ben Finney ben+deb...@benfinney.id.au writes: I think it can be a good idea to propose an option that one wants to see voted on, especially if one honestly thinks that option could represent the opinion of other people in the vote. This is what I disagree with for all the reasons that I already stated (and which I won't reiterate again). The formal proposal is essentially the first second towards putting it on the ballot. If you don't actually agree with the proposal, I don't think you should be doing either. I suspect we'll have to agree to disagree on this. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Joerg Jaspert jo...@debian.org writes: this will mean that future GRs would need 30 other people to support your idea. While that does seem a lot (6times more than now), Actually, 31 (depending on where you do the rounding/truncation which would have to be specified or there will be arguments). floor() in this case. Well, my idea was just to drop everything behind the .. So floor(), int(), whatever it is in your favorite language. :) It's not so much the function as it is the order of operations. It sounds like you meant 2 * floor(Q) instead of floor(2Q). :) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Dec 30, 2008 at 11:21:34AM +0100, Joerg Jaspert wrote: this will mean that future GRs would need 30 other people to support your idea. While that does seem a lot (6times more than now), Actually, 31 (depending on where you do the rounding/truncation which would have to be specified or there will be arguments). floor() in this case. Well, my idea was just to drop everything behind the .. So floor(), int(), whatever it is in your favorite language. :) I believe you wrote that Q is approx 15.9765453086705, so... floor(2Q) = 31 2(floor(Q)) = 30 :-) - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAklaYJ4ACgkQn7DbMsAkQLgWVgCgppAnjR3lNkz4iA0sLzMb9j6X BggAoJmJYHiqW/aYAtTG5jGHSda+WheF =orLI -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Wouter Verhelst wou...@debian.org wrote: [...] Well, I disagree on that point. I just had a look at the vote.debian.org pages, checking those votes where the number of seconds exceeded 10, and found only the following ones: I add the outcomes to the start of the line:- Proposal F chosen - Proposal F on the last vote; 17 seconds Proposal A chosen - Proposal A on 2008_002 (membership); 21 seconds Proposal A chosen - Proposal A on 2007_004 (length DPL election); 20 seconds Amendment A chosen - Amendment A on 2006_001 (GFDL); 15 seconds Proposal B chosen - Proposal E on 2004_004 (sarge release after 2004_003): 16 seconds Amendment chosen - Amendment on 2004_002 (status of non-free): 12 seconds So, in one case, the outcome was different to the most-seconded option. [...] Now I do realize and agree that many people will probably not second something anymore once a sufficient number of seconds has been issued; but I think that, all things considered, 30 may be too much. Yes and more generally: I think there are obviously some interactions between being the first proposal, the number of seconds gathered, the voting preferences (and so the outcome) and the current required number of seconds. It's this last element which makes this analysis so unreliable, but the others play a part. [...] However, raising the bar sixfold in one go is pushing it, IMO. I agree. There seems little rationale to support it. The more I've looked, the more places I've not found evidence for such a large seconding requirement and I know a few anecdotes about raising numbers too high and accidentally killing an organisation... Was 30 proposed as a let's propose something extreme and see if we can get something less-but-sufficient-to-kill-nearly-all-GRs through vanguard? Regards, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
[Stephen Gran] That just means that the number of people who think the vote is even worth having is not that different to the number of votes required to make it valid. That's probably not all that bad a thing, IMHO. If that is sound reasoning, then it is also a reason to have a higher number of required sponsors for amendments to foundation documents. That said, I think I agree that 2Q is too high but current K is too low. (Split the difference? Q + K/2) Another issue with raising the bar is that if you formally propose something before it is fully ready, such that it will need two or three small modifications, it would get very confusing who has seconded what versions of the text - guaranteed great fun for the Secretary role. Not a new issue, but it would get worse. I suppose this would serve as social engineering to encourage people to circulate drafts for awhile before proposing them. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
* Wouter Verhelst [Tue, 30 Dec 2008 18:21:58 +0100]: I'm still undecided whether I'm for Q, 2Q, or what. But: Well, I disagree on that point. I just had a look at the vote.debian.org pages, checking those votes where the number of seconds exceeded 10, and found only the following ones: I don't think that's a fair consideration. We all know a proposal needs 5 seconds, so if we see one we'd second has the 5 already, I think it's natural to pass. The popular proposal notwithstanding. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org A hacker does for love what other would not do for money. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Tue Dec 30 09:31, Russ Allbery wrote: Ben Finney ben+deb...@benfinney.id.au writes: I think it can be a good idea to propose an option that one wants to see voted on, especially if one honestly thinks that option could represent the opinion of other people in the vote. This is what I disagree with for all the reasons that I already stated (and which I won't reiterate again). The formal proposal is essentially the first second towards putting it on the ballot. If you don't actually agree with the proposal, I don't think you should be doing either. I'd also add that sometimes it seems like a good idea to make sure that an opinion which has been voiced but not yet proposed is there so you can demonstrate that the project really doesn't want it and you can cite this next time it's raised rather than have the possible ambiguity. Note that I don't think that's a good reason to call a vote, but to propose an amendment... maybe. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Frans Pop elen...@planet.nl wrote: On Tuesday 30 December 2008, MJ Ray wrote: I add the outcomes to the start of the line:- Proposal F chosen - Proposal F on the last vote; 17 seconds Eh, that's incorrect. Eh, that's unhelpful. I found both the email's terms and some of the more recent vote pages a bit confusing. I'm pretty sure I've suggested an improved layout to the secretary in the past, but it was ignored. Please correct any goofs if you've spotted them. Anyway, that's two out of seven, which makes the point I took stronger, not weaker. Regards, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Dear all, since it is rare that a GR is rejected by a majority of persons ranking Further discussion above all, I do not think that there is a need to make it more difficult to propose a GR. Nevertheless, in light of the painful firmware GR this year, I think that the following ideas can help to avoid such a situation to happen again. - Restrict the use of 3:1 supermajority to GRs proposing changes of our fundation documents. - Authorise the proposer of a GR to call for a vote on a subset of the amendments. - Authorise the Secretary to use non-email methods, as email voting seems to be is a repeated source of problems. Programs like Selectricity look like interesting alternative (http://selectricity.org/). - Ask the GR proposer to take part of the work load, for instance by gathering and counting the PGP-signed secondings and writing the vote.debian.org page. If despite this the Project would require ~15 seconders per GR and amendments, I suggest to think about a new place and/or method to handle the formal PGP-signed emails of the GR preparation procedure, otherwise debian-vote can really become unreadable. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Charles Plessy ple...@debian.org writes: in light of the painful firmware GR this year, I think that the following ideas can help to avoid such a situation to happen again. - Restrict the use of 3:1 supermajority to GRs proposing changes of our fundation documents. This restriction would not address the perceived problems with the gr_lenny_firmware ballot. Recall that “changes to the foundation documents” was the very justification for why the 3:1 supermajority requirements were applied as they were. What it seems is that some people (including you?) disagree with some others on *what* constitutes a change to foundation documents. That seems to be the point that needs better clarification. - Ask the GR proposer to take part of the work load, for instance by gathering and counting the PGP-signed secondings and writing the vote.debian.org page. I like this idea for its “share the load” effect, but I can see a change in conflict of interest if the person who proposes the GR also gets to write up the formal vote document. -- \“I installed a skylight in my apartment. The people who live | `\ above me are furious!” —Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Discussion: Possible GR: Enhance requirements for General Resolutions
Hi, I have felt for some time that the low requirement for seconds on General Resolutions is something that should be fixed. We are over 1000 Developers, if you can't find more than 5 people supporting your idea, its most probably not worth it taking time of everyone. Various IRC discussions told me that others feel the same. So here is a possible proposal. Probably needs en_GANNEFF cleanup, and might need other changes too, I try collecting them from replies. As this will change the constitution, if we ever go and vote on it, it will need a 3:1 to win. (see Constitution 4.1.2) Oh, note. While this is written as a GR, this is a discussion proposal only. I'm *not* calling for seconders with this mail. Thats also the reason for the reply-to/mail-followup-to header going to -project, please respect them. General Resolutions are an important framework within the Debian Project. Yet, in a project the size of Debian, the current requirements to initiate one are too small. Therefore the Debian project resolves that a) The constitution gets changed to not require K developers to sponsor a resolution, but floor(2Q). [see §4.2(1)] b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)], as well as resolutions against a shortening of discussion/voting period or to overwrite a TC decision [§4.2(2.3)] requires floor(Q) developers to sponsor the resolution. c) the definition of K gets erased from the constitution. [§4.2(7)] (Numbers in brackets are references to sections in the constitution). Practical changes: Taking the definitions of the latest GR we had, Current Developer Count = 1021 Q ( sqrt(#devel) / 2 ) = 15.9765453086705 Quorum (3 x Q ) = 47.9296359260114 this will mean that future GRs would need 30 other people to support your idea. While that does seem a lot (6times more than now), considering that a GR affects more than 1000 official Developers and uncounted amounts of other people doing work for Debian, I think its not too much. Especially as point b only requires 15 people, 3 times the amount than now, in case there is a disagreement with the DPL, TC or a Delegate. -- bye, Joerg Please, not the graphviz one again, I only just finished the therapy I had to start after I read it the first time. I'm sure this one was written by some sort of non-human entity. I would go for lawyers. pgpdMKqVlawtH.pgp Description: PGP signature
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Joerg Jaspert jo...@debian.org writes: a) The constitution gets changed to not require K developers to sponsor a resolution, but floor(2Q). [see §4.2(1)] This would mean that you need almost as many sponsors as is required for the quorum (2Q vs 3Q). I think that is too much. I think floor(Q) sponsors would be a more appropriate number. -- * Sufficiently advanced magic is indistinguishable from technology (T.P) * * PGP public key available @ http://www.iki.fi/killer * -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
This one time, at band camp, Kalle Kivimaa said: Joerg Jaspert jo...@debian.org writes: a) The constitution gets changed to not require K developers to sponsor a resolution, but floor(2Q). [see §4.2(1)] This would mean that you need almost as many sponsors as is required for the quorum (2Q vs 3Q). I think that is too much. I think floor(Q) sponsors would be a more appropriate number. That just means that the number of people who think the vote is even worth having is not that different to the number of votes required to make it valid. That's probably not all that bad a thing, IMHO. -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Tue, 30 Dec 2008, Joerg Jaspert wrote: Therefore the Debian project resolves that a) The constitution gets changed to not require K developers to sponsor a resolution, but floor(2Q). [see §4.2(1)] b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)], as well as resolutions against a shortening of discussion/voting period or to overwrite a TC decision [§4.2(2.3)] requires floor(Q) developers to sponsor the resolution. c) the definition of K gets erased from the constitution. [§4.2(7)] Whatever we decide to do should specifically modify the constitution; that is a) §4.2.1 is replaced with The Developers follow the Standard Resolution Procedure, below. A resolution or amendment is introduced if proposed by any Developer and sponsored by at least floor(2Q) other Developers, or if proposed by the Project Leader or the Technical Committee. b) §4.2.2.2 is replaced with If such a resolution is sponsored by at least floor(Q) Developers, or if it is proposed by the Technical Committee, the resolution puts the decision immediately on hold (provided that resolution itself says so). etc. I'd also suggest alternatively, that we change K to be floor(Q), and modify §4.2.1 to be 2K, §4.2.2.2 to be K, and §4.2.2.3 to be left alone, which would have the same effect, but with fewer changes (and we could define floor(Q) instead of assuming it to be known.) Because quorum is 3Q, this would mean that any option will have enough voters to conceivably win in an election. [I would also be ok with K==1.5Q, and requiring at least K developers for each step.] All that said, I'd be interested in seeing such a change made.[1] Don Armstrong 1: I'd be happier, though, if those proposing and seconding options would be more careful about the effects that their options may have, and be more vigilant about withdrawing options when more palletable options exist. You should not be proposing or seconding an option that you don't plan on ranking first. -- This message brought to you by weapons of mass destruction related program activities, and the letter G. http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Don Armstrong d...@debian.org writes: 1: I'd be happier, though, if those proposing and seconding options would be more careful about the effects that their options may have, and be more vigilant about withdrawing options when more palletable options exist. Absolutely agreed with this sentiment. You should not be proposing or seconding an option that you don't plan on ranking first. This seems quite wrong. Why should one not carefully and precisely phrase and propose an option that one does *not* agree with, in order to get it voted on? -- \ “The cost of education is trivial compared to the cost of | `\ ignorance.” —Thomas Jefferson | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, General Resolutions are an important framework within the Debian Project. Yet, in a project the size of Debian, the current requirements to initiate one are too small. Therefore the Debian project resolves that a) The constitution gets changed to not require K developers to sponsor a resolution, but floor(2Q). [see §4.2(1)] not sure if we need floor(2Q) here, but at least floor(Q). b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)], as well as resolutions against a shortening of discussion/voting period or to overwrite a TC decision [§4.2(2.3)] requires floor(Q) developers to sponsor the resolution. c) the definition of K gets erased from the constitution. [§4.2(7)] what I'd like to add here is something in the lines of d) If a resolution will affect an upcoming release which is already frozen, the resolution needs twice the number of sponsors as defined in a). This should help to avoid that some random people try to stop a release in the latest moment if there's not a really good reason to do so. If we want Debian to be used in business (enterprise *gasp*) installations, we should at least be able to tell people when we're about to release, without having them to fear a delay for months or years due to a GR. Cheers, Bernd - -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklZcF0ACgkQBnqtBMk7/3mSWQCgqxtj+r+8utnDbSFVfisvwgLt 9YkAoIsQ3gKZnKjol2kbP0Yz9ysMtTqx =PZiI -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Tue, 30 Dec 2008 00:54:41 +0100, Joerg Jaspert wrote:
I have felt for some time that the low requirement for seconds on General
Resolutions is something that should be fixed. We are over 1000
Developers, if you can't find more than 5 people supporting your idea,
its most probably not worth it taking time of everyone. Various IRC
discussions told me that others feel the same.
I agree that raising the barriers would be a good idea.
Cheers,
gregor
--
.''`. Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
: :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/
`. `' Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
`-NP: Tina Turner: The Best
signature.asc
Description: Digital signature
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Ben Finney ben+deb...@benfinney.id.au writes: Don Armstrong d...@debian.org writes: You should not be proposing or seconding an option that you don't plan on ranking first. This seems quite wrong. Why should one not carefully and precisely phrase and propose an option that one does *not* agree with, in order to get it voted on? Why vote on something no one actually wants? It just makes the ballot more complex and has the potential to add confusion and wording problems for no gain. If it's a viable option, it will get enough seconds in its own right. If it doesn't, it's so unpopular that there's no point in voting on it. The only case where I could see it making sense to second options one personally doesn't support is if one believes for some reason that there is a huge disconnect between the people reading debian-vote and seconding proposals and the project as a whole, so huge that an option that would win in the larger vote doesn't have enough advocates reading debian-vote to get sufficient seconds. This seems unlikely to me. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Russ Allbery r...@debian.org writes: Ben Finney ben+deb...@benfinney.id.au writes: Don Armstrong d...@debian.org writes: You should not be proposing or seconding an option that you don't plan on ranking first. This seems quite wrong. Why should one not carefully and precisely phrase and propose an option that one does *not* agree with, in order to get it voted on? Why vote on something no one actually wants? I don't know. I didn't know anyone was asking for that to happen. If it's a viable option, it will get enough seconds in its own right. Yes, certainly. I get the feeling you've excluded the middle between “propose an option one does not plan on raking first”, and “propose an option no-one wants on the ballot”. The only case where I could see it making sense to second options one personally doesn't support is if one believes for some reason that there is a huge disconnect between the people reading debian-vote and seconding proposals and the project as a whole, so huge that an option that would win in the larger vote doesn't have enough advocates reading debian-vote to get sufficient seconds. This seems unlikely to me. Another purpose, that I've seen recently a few times, is people proposing *several* discrete options for a ballot, carefully phrasing them to be distinct in order to clarify the meaning of the vote's result. According to Don's statement above, this is not a good reason to propose options. I disagree; I think it's commendable and in the spirit of his earlier statement (in the same message) to strive for clarity and precision in the ballot options. Further, there may be other reasons that both you and I haven't yet thought of. I think it's unwise to say pre-emptively that those are “should not” reasons also, merely because they're not options the proposer plans to rank first. -- \ “There is no reason anyone would want a computer in their | `\ home.” —Ken Olson, president, chairman and founder of Digital | _o__)Equipment Corp., 1977 | Ben Finney -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Tue, 30 Dec 2008, Ben Finney wrote: Another purpose, that I've seen recently a few times, is people proposing *several* discrete options for a ballot, carefully phrasing them to be distinct in order to clarify the meaning of the vote's result. If no one is going to rank those options highly, there's no purpose in proposing them. I could see someone drafting them as an option for someone else who planned on ranking them highly to actually propose and second. According to Don's statement above, this is not a good reason to propose options. I disagree; I think it's commendable and in the spirit of his earlier statement (in the same message) to strive for clarity and precision in the ballot options. Options that (almost) no one actually supports don't increase clarity. Our voting system isn't a survey of developers; it's a means of making decisions. Don Armstrong -- Whatever you do will be insignificant, but it is very important that you do it. -- Mohandas Karamchand Gandhi http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Ben Finney ben+deb...@benfinney.id.au writes: I get the feeling you've excluded the middle between “propose an option one does not plan on raking first”, and “propose an option no-one wants on the ballot”. I'm not sure that I find it usefully different, unless what you're proposing is a compromise that you hope everyone will be able to agree upon. I suppose that's a useful addition to Don's statement; I could see proposing that even though it wasn't one's first choice. Another purpose, that I've seen recently a few times, is people proposing *several* discrete options for a ballot, carefully phrasing them to be distinct in order to clarify the meaning of the vote's result. I think that's a good exercise to write clear proposals, but I don't see a reason to then formally propose all of them. I'd write them all up as part of that exercise and then propose the one that I agree with, offering the others to those who agree with them to put forward if they choose. Writing options that you don't personally agree with is full of problems. It's very difficult to be objectively fair in capturing an option that you don't believe in and wouldn't argue for. I'd much rather see the people who really believe in an option step forward to propose it. According to Don's statement above, this is not a good reason to propose options. I disagree; I think it's commendable and in the spirit of his earlier statement (in the same message) to strive for clarity and precision in the ballot options. Sure, I'm all for clarity and precision. I just don't see a reason to put the ones that no one wants to champion on the final ballot. With Condorcet voting and Further Discussion, there seems to be little point in trying to flesh out a ballot with all possible distinct options just out of some sense of completeness. If one of those options that no one seconded turns out to be what the rest of the project who wasn't participating in the proposal process wanted, that's what Further Discussion is for (and I expect that to be quite rare). As far as I'm concerned, the ideal outcome of a GR discussion isn't a ballot with all options represented. It's a project-wide consensus on the best course of action. When that happens, there's no need to have anything other than the consensus on the ballot, and if something went wrong with that process, there's always FD. I want to be working towards agreement, not towards getting everyone's starting position on the ballot. I think the current low threshold for amendments and the habit of proposing or seconding ones one doesn't agree with is counter to that; once something is seconded and on the ballot, I think it takes a lot of steam out of the discussion and reduces the chances of a general consensus compromise. Which is one of the reasons why I think Jeorg's proposal is a good one (to bring this back to the original thread topic). I agree that the threshold feels too low currently. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Don Armstrong d...@debian.org writes: On Tue, 30 Dec 2008, Ben Finney wrote: Another purpose, that I've seen recently a few times, is people proposing *several* discrete options for a ballot, carefully phrasing them to be distinct in order to clarify the meaning of the vote's result. If no one is going to rank those options highly, there's no purpose in proposing them. Agreed on that. I could see someone drafting them as an option for someone else who planned on ranking them highly to actually propose and second. Fine. Your original statement denied this possibility, which was all I wanted to address. According to Don's statement above, this is not a good reason to propose options. I disagree; I think it's commendable and in the spirit of his earlier statement (in the same message) to strive for clarity and precision in the ballot options. Options that (almost) no one actually supports don't increase clarity. It's this implicit binding of “the proposer doesn't support the option” with “(almost) no-one actually supports the option” that I find unneccessary and overly restrictive. It seems you agree, but your terminology suggests otherwise. -- \ “This world in arms is not spending money alone. It is spending | `\ the sweat of its laborers, the genius of its scientists, the | _o__) hopes of its children.” —Dwight Eisenhower, 1953-04-16 | Ben Finney -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
Russ Allbery r...@debian.org writes: Sure, I'm all for clarity and precision. I just don't see a reason to put the ones that no one wants to champion on the final ballot. Nor do I. You still seem to be making an unnecessary connection between “the option isn't well supported enough to be on the ballot” and “there's no good reason to propose the option in the first place”. That, or you seem to think I'm proposing to lower the barrier of entry for options, once proposed, to appear on the ballot; that's not what I'm saying either. I think it can be a good idea to propose an option that one wants to see voted on, especially if one honestly thinks that option could represent the opinion of other people in the vote. I do tend to agree that *seconding* an already-proposed option that one doesn't intend to rank high is less justifiable than proposing such an option. -- \ “Faith, n. Belief without evidence in what is told by one who | `\ speaks without knowledge, of things without parallel.” —Ambrose | _o__) Bierce, _The Devil's Dictionary_, 1906 | Ben Finney -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Tue, 30 Dec 2008, Joerg Jaspert wrote: Hi, I have felt for some time that the low requirement for seconds on General Resolutions is something that should be fixed. We are over 1000 Developers, if you can't find more than 5 people supporting your idea, its most probably not worth it taking time of everyone. Various IRC Why are you saying 5 ? Your proposal requires 30. Recent votes have shown that some options tended to have more seconds than the others but we never reached 30. We had 17 for Exclude source requirements for firmware and 21 for Invite the DAM to further discuss until vote or consensus, leading to a new proposal.. Note that with those new requirements some interesting amendments/alternate choices would not have made it in several of the votes (although different rules would have probably lead more people to second). Anyway 2Q is too much in my opinion. Q would be much more reasonable. It would be also be good to add a sentence inviting the seconders to explain why they second the proposal. At least it would make the many formal mails to second proposals somewhat interesting to read (they could even be linked from the vote web page so that voters who have not taken part in the discussion can refer to the reasoning of those who have brought the option to the vote). only. I'm *not* calling for seconders with this mail. Thats also the reason for the reply-to/mail-followup-to header going to -project, please respect them. List-reply ended on both lists, I had to hand-edit the result. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
