web page for 2008-002 broken?
Hi, Is it just me or is that web page completely broken? It lists Proposer, and then Amendment Proposer, and then Seconds. Which seconds are those, to the first or the second part? Then finally we get Text. Wow, it took only three PgDns to get to the actual subject matter :P :( And then after that there's Amendment Proposer. Didn't we see this already? Then Amendment Seconds, then Amendment Text A, then Amendment Text B. Where are the amendment seconds for A or B, whichever one is missing? Then there's a broken Quorum section (no data). This was very confusing :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Proposal - Project infrastructure team procedures
On Sat, May 03, 2008 at 10:29:03AM +0200, Andreas Barth wrote: So, this seems to indicate that the way to add new people to the release team isn't an issue. It however indicates also that there must be a way how the DPL can change a team in case it isn't working anymore, and e.g. add new people. Which is the way it currently is. Which is the way we currently *hope* that it is, but ten to fifteen years of experience demonstrates that the model is known to fail miserably. The last weeks have demonstrated reasonable well that it works in case the DPL uses the powers he has. That's another rosy view, and one I've already discussed in the thread... What guarantee do we have to think that it won't take another ten to fifteen years of intermittant failure for the next demonstration of power? :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - Project infrastructure team procedures
On Fri, May 02, 2008 at 11:51:53AM +0200, Andreas Barth wrote: Why not making it the other way, allowing the DPL to remove people if he wants? So teams can expand themselfs (like the release team regularly does), but the DPL can still make sure that no unwanted people are delegated there. And, reading the current constitution, we already have it that way. Good. I don't see it, other than the workaround I mentioned earlier in the thread... is that what you mean? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - Project infrastructure team procedures
On Wed, Apr 30, 2008 at 11:45:19PM -0500, Manoj Srivastava wrote: On Thu, 1 May 2008 03:28:48 +0200, Frans Pop [EMAIL PROTECTED] said: And you think a little GR telling DPL's go ahead -- you can do it! [...] However, feel free to go ahead with make-work; we do need to fill up the vote page with more than just DPL votes, and I'll happily run GR's. [...] What's next, a GR determining the favourite color of the Debian collective? Thanks for being your usual obnoxious self in this discussion Manoj. Can't you for once discuss something without making these snide belittling remarks? This is absolutely precious. It is wrong of me to belittle a proposal, but it is all right for you to attack the man, and not the argument. Am I correct in assuming that the logical fallacy escaped you? You don't seem to realize that what you consider to be merely belittling a specific idea without any reference to anything else, actually looks *generally* belittling. Over the years, I've learned to tolerate and understand this behaviour, but not everyone will necessarily see it the same way, or be willing to tolerate it. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - Project infrastructure team procedures
On Fri, May 02, 2008 at 09:45:08AM -0500, Manoj Srivastava wrote: I think you are lending credence to Clint's argument about cronyism and wholescale flouting of the constitution here. At first blush, this does seem like a failure of the DPL's in question to act. Now, I must admit that cronyism or not, the release management seems to be working, but at one point so were some of the other teams, which have come under criticism of late for being obstructive. It boils down to this: Do we want a project governed by a constitution, or do we want brilliant, hard workers, with friends in the DSA (or other infrastructure teams), gain powers be mere proclamation, and then present the DPL with a fait accompli that they would be loth to disrupt (since it would be an improvement over status quo)? At the same time, notice that the desire of teams to be less susceptible to random changes by the DPL stems from the need to avoid cronyism by the DPL, which is also possible, though that one is eventually repairable. That is also valid concern IMO, although it is not as important as fixing the potential for cronyism and other failures in the teams themselves which doesn't have nearly the same amount of repairability. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - Project infrastructure team procedures
On Fri, May 02, 2008 at 11:31:52PM +0200, Andreas Barth wrote: So, this seems to indicate that the way to add new people to the release team isn't an issue. It however indicates also that there must be a way how the DPL can change a team in case it isn't working anymore, and e.g. add new people. Which is the way it currently is. Which is the way we currently *hope* that it is, but ten to fifteen years of experience demonstrates that the model is known to fail miserably. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - Project infrastructure team procedures
On Wed, Apr 30, 2008 at 11:54:13PM -0500, Manoj Srivastava wrote: What bothers me about all this is that we had a nicely detaled document that spells out who has what rights, and it seems fairly clear to me that all powers in Debian stem from the powers laid down there; but that nicely detailed document is not enough. What makes one thing that any non-supermajority GR which says essentially the same thing as the constitution will have any weight? The Constitution is nicely detailed, but it doesn't recognize infrastructure teams. It doesn't have a generic handler (so to speak) for groups of developers - it does handle delegations which can expand into N developers, but this is done in a completely impractical way, judging by history. Are teams of delegates not just multiple delegated developers, who are individually covered by the constitution? Well, if a team decides to expand on its own, which they do normally, this is simply not covered by the constitution, at least not AFAICT - section 8 doesn't mention any such thing. So, even if we assume here that the constitution made all team members implicit delegates at one point, all further decisions by those original delegates to share their work with others effectively make those other people delegates, but they can't be replaced by the leader because a) the leader never appointed them and b) it would be overriding a decision made by a delegate. And the leader can't get those other people's permissions revoked via proxy, because the proxy is the implicitly delegated sysadmin team, whom they can't command. D'oh! Yet, there is a workaround - the leader can post res delegate and then immediately undelegate the same thing to/from those people. The first part can contradict the second sentence of the general rule 2.1.1., but the second part is allowed by the third sentence of the same rule. But in any case, this whole idea is plain ugly. The other part of my impracticality complaint is the simple fact that it doesn't actually properly describe the situation as it is, because, to my knowledge, not only haven't the delegations been done as described, but the leader never actually replaced people in any of them (8.2), and the developers never made or overrode their decision (4.1.3), or delayed their decision (4.2.2). About the only thing in the constitution that is relevant for the infrastructure teams in general is 8.3 - that they make decisions as they see fit. That's not a good coverage. Are people who were grandfathered by the constitution (or some such equally silly argument) not also grandfathered by this forthcoming GR? What changes? That's a good question, and the reason why I initially proposed that we don't try to force the delegation/undelegation system as it is - it doesn't seem entirely appropriate for the teams because some things simply predate the notion of a project leader, it will easily seem anachronistic and pretentious for the leaders to be able to undelegate someone's access to something they've created and maintained for a decade, without requiring any sort of a criterion to base that decision on. But others don't seem to mind that... Err, no one has an absolute right to project resources, even if they have maintained the resource for the project for a decade. And no, I don't think a lot of people have a problem with that. I certainly do not. These are not individual resources, they are _project_ resources. Access to project resources is governed by the constitution, and is delegated to individuals for a certain period. The resource ownership remains with the project, and it can, by mechanisms detailed in the constitution, take the delegated pwoers away. No matter how long the delegation has lasted. The lack of major upheaval in reaction to the recent delegations certainly point to the fact that all the fear, uncertainty and and doubt people had about what would happen if you added people to core teams were somewhat overblown. Notice that that recent action was adding, but we have never seen any removing, which is what I described above. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - Project infrastructure team procedures
On Thu, May 01, 2008 at 02:05:08PM +0900, Charles Plessy wrote: Le Wed, Apr 30, 2008 at 08:15:42PM +0200, Josip Rodin a écrit : * Infrastructure teams are encouraged to adapt their sizes to their workloads, to ensure that they don't block or slow down the work of other Debian contributors. Hi Josip and everybody, I understand that ad-hoc GRs can be suspected to be too much investment of time for a punctual result. This makes me conclude that if we want this GR to be the most useful, then indeed it is important that it defines what an infrastructure team is, and who decide which team matches the definition. So you agree with what I said in the message you responded to, good :) Similar to the way constitution and simple laws are hierarchised in some countries, this GR may be most useful if written in a way that it can be a reference that is not a foundation document, but still can be modified by further GRs in the future if needed. Yes, that is my intention, just a normal policy/position statement, as described by Constitution 4.1.5, and the same as we have done in the past. (The same section defines foundation documents, but this would not be one. To make a new foundation document, we would actually have to modify the list in Constitution 4.1.5.2.) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - Project infrastructure team procedures
On Thu, May 01, 2008 at 07:45:10AM +0200, Frans Pop wrote: Josip Rodin wrote: Anyway, I'd agree to stripping down the detailed procedure, but you still Sorry for not replying to this thread before. IMO it is definitely worthwhile to clarify the role of core teams within the project and to establish some kind of framework to ensure that continuity in the work of those teams can be better guaranteed, especially by ensuring that the existing team cannot hold the rest of the project hostage by structurally blocking any change in its membership or blocking access to resources [1]. My first objection to the proposal for which you asked for seconds was that it did not read like a GR. It was also not clear how the GR should be implemented after being passed: it proposed a detailed procedure without introducing some kind of permanent document to hold that procedure. Well, it was a permanent document in itself. Together, the developers may issue nontechnical policy documents and statements. That's all there is to it... I also felt that the original proposal was probably over-engineered and like the general idea behind the changes proposed by Lucas. Okay. I may have gotten sidetracked with the idea of regulating the entire procedure, because people were responding to parts of it, which made me think that they weren't opposed to the idea as a whole. If people don't want that, and just want something more lax, that's fine by me - just as long as we fix the limbo. I also to some extend agree with people who may feel that this proposal may be too late now as the problems are finally being addressed. However, IMO that should not prevent us from clarifying things for the future. It is definitely too late by any standard, because we've had serious issues with this for at least a decade. Remember when the NM process was completely closed for a while - that was probably like nine years ago? Gosh, time flies... [1] The case I have in mind here is debian-announce and related resources. Which is that? I forget... -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - Project infrastructure team procedures
On Thu, May 01, 2008 at 11:49:35PM +0100, Stephen Gran wrote: This one time, at band camp, Josip Rodin said: the developers never made or overrode their decision (4.1.3) http://www.debian.org/vote/2007/vote_002 Oh, okay, true. That's one. Did I miss any others? :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - Project infrastructure team procedures
On Wed, Apr 30, 2008 at 12:55:29PM +0200, Lucas Nussbaum wrote: The main goal of my proposal is to allow people to choose between (A) and (B) explicitely. OK, I was actually hoping for that myself, I think I actually voiced that at one point last year :) Hmm. In the last few weeks, we've seen a few DPL decisions go completely uncontested. Three people replied positively to Sam's decision on -devel, and nothing else. Is that indicative enough? I'm not sure. OK, everybody seem to agree that the DPL is already empowered to add people to infrastructure teams. And the new members are clearly delegates. Well, not everybody seemed to agree that DPL was empowered to add people to infrastructure teams in the past, because nobody was doing these things for *years*. Right now it has happened, so we *may* have overcome that problem, but we don't actually know that. A straightforward general resolution would settle this issue clearly. But it is still unclear whether the previous members are also delegates, and could be undelegated. And that should be resolved, too, yes. On one hand, the recent delegations made this matter less urgent, so we don't need to vote on that now. On the other hand, the fact that there's no urgent situation might mean that it's the best time to discuss (and vote) on this. Oh, yes, if we completely ignore it now just because of the recent fluke, it would just mean we haven't learned from history. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - Project infrastructure team procedures
On Wed, Apr 30, 2008 at 10:02:24AM -0500, Manoj Srivastava wrote: I am of the camp that believe that the only power people have in any capacity in Debian flows from the constitution; which means either the powers listed for developers, or as delegates of the DPL. Recent delegation activity seems to bear this out. That's the problem - it's supported by recent activity, but not by the previous ten or so years. We have had full members added to the FTP team, to the DAM, and I don't think we had issues with any other tesm refusing to accept people. Well, that's not really true, I distinctly recall problems with buildds as well. And there's probably more, I've written about it before... As it stands, with the delegations already in place, and with the detailed team reviews underway, which indicates that the current DPL is going to be actively addressing the problems we have, that a GR is just a waste of time. You state the problem yourself - the *current* DPL(s) are doing *something*, but we don't actually know much about it, or if any of it will happen again, or if the next different DPL and his inaction will mark the start of another fifteen years of problems... One could argue that this pair of DPLs will lead by example, and set a standard for all future ones. But has that historically happened, and if so will it repeat itself? I don't know. I don't like not knowing, when there's a reasonably simple option that can fix that. I tend to agree with joeyh that GR's lead to controversy, are overly bureaucratic, and should be a matter of last recourse; we are hardly at last recourse here. The problems are already being addressed. I don't think that they all have to lead to controversy, or be overly bureaucratic. I remember that GR that was about IRC as a communication channel, which seemed to me to have appeared out of nowhere (i.e. it had no major controversy attached to it that I could remember), it sounded very frank and lax to me, and it passed. This view that GR's are a problem in itself and that we shouldn't do them is indicative of the whole situation - nobody thinks that calcified teams are a problem so major that they need fixing with a big ol' GR, so the status quo can freely persist, for years at a time. In essence, this is analogous to the real-world issue of people not thinking that some general problem is their problem, and nothing much gets done before someone takes the plunge and does a more revolutionary thing. Whereas, in the more organized societies, people use the mutually agreed upon (constitutional) processes to create procedures which avoid major problems before they escalate. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - Project infrastructure team procedures
On Sat, Apr 19, 2008 at 08:24:25PM +0200, Lucas Nussbaum wrote: Debian developers acknowledge the following: * The Debian Project infrastructure is run by people who volunteer their time and knowledge in a good-faith effort to help the Debian Project. * The practice of existing members of a team having people join in and help, and new people volunteering without a particularly formal procedure, is the original and natural way of changing team membership. * Training of and otherwise working with new team members requires additional effort from existing team members, so care should be taken to avoid having too much team effort spent on unnecessary new members or new members who would not reciprocate the effort. * Infrastructure teams have to be stable, but they don't have to calcify. everything stays the same so far. * Ad hoc intervention by Debian Project Leaders is not a practical solution to resolve issues with infrastructure teams. The process of delegation and undelegation has not historically proven itself as an effective mechanism for improving infrastructure teams. There has also been ambiguity on the constitutional position of infrastructure teams as such, particularly those that predate it. * To avoid issues with teams which are not proactive with regard to adding or removing members, and to address aforementioned inadequacies and ambiguities, it is necessary to define a modicum of procedure for how developers can join the infrastructure teams. It is also necessary to properly engage the Debian Project Leader with the functioning of the infrastructure teams. those two points are removed. Debian developers resolve the following: * Infrastructure teams are encouraged to adapt their sizes to their workloads, to ensure that they don't block or slow down the work of other Debian contributors. * Existing team members who don't sufficiently contribute to the team effort should be removed from the team. * When an infrastructure team slows down or blocks the work of other Debian contributors without taking the necessary actions, the Debian Project Leader is empowered to add or remove members to/from the team using delegations. When possible, this should be done by consulting the team first. - (suggestions of improvements are welcomed for the draft) I'm not sure if you phrased that last sentence correctly... what does the 'without taking the necessary actions' part mean? Did you mean to say s/without/by not/? Anyway, I'd agree to stripping down the detailed procedure, but you still shouldn't strip these two ideas: * the definition of infrastructure teams - add one clause saying that the DPL decides which they are, so that we preclude any discussion of the lack of applicability * the mention of communication - add one clause saying that relevant membership decisions have to be promptly and properly communicated between the DPL and the teams, so that we don't have a lack of transparency. I'd also charge the DPL to eventually inform the developer body about the gist of all such matters. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - Project infrastructure team procedures
On Wed, Apr 30, 2008 at 02:14:39PM -0500, Manoj Srivastava wrote: You state the problem yourself - the *current* DPL(s) are doing *something*, but we don't actually know much about it, or if any of it will happen again, or if the next different DPL and his inaction will mark the start of another fifteen years of problems... One could argue that this pair of DPLs will lead by example, and set a standard for all future ones. But has that historically happened, and if so will it repeat itself? I don't know. I don't like not knowing, when there's a reasonably simple option that can fix that. And you think a little GR telling DPL's go ahead -- you can do it! is going to make a whit of difference. given the precedent the current DPL is setting? You have far more faith in a GR that reaffirms stuff that DPLs have already done to make a difference about the conduct of future DPL's. I think that it's going to make a difference, because it will eliminate the notion that there are grey areas, which has historically obstructed progress - no leader wanted to order people to do things differently when it was not clear whether they had both the legal and the moral authority to intervene in matters where they haven't intervened before. The next DPL, in say three or four years from now, could easily think something like - yes, those guys did some interventions back in 2007/2008, but that was only after a prolongued period of problems, so I don't really have the right to intervene in our current problems, regardless of how acute they are, because I need to let a few more years pass. In essence, this is analogous to the real-world issue of people not thinking that some general problem is their problem, and nothing much gets done before someone takes the plunge and does a more revolutionary thing. Whereas, in the more organized societies, people use the mutually agreed upon (constitutional) processes to create procedures which avoid major problems before they escalate. Had nothing been done, you might have had a point. As such, this is just make work. You're ignoring the simple fact that it has taken so many years to get this much done. Does that kind of a lag not indicate that we have a systematic problem that needs a bit more more systematic action? Such as defining a tangible consensus on what should and should not be done. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - Project infrastructure team procedures
On Wed, Apr 30, 2008 at 08:42:59PM +0100, Clint Adams wrote: On Wed, Apr 30, 2008 at 09:40:31PM +0200, Josip Rodin wrote: I think that it's going to make a difference, because it will eliminate the notion that there are grey areas, which has historically obstructed progress - no leader wanted to order people to do things differently when it was not clear whether they had both the legal and the moral authority to intervene in matters where they haven't intervened before. The next DPL, in say three or four years from now, could easily think something like - yes, those guys did some interventions back in 2007/2008, but that was only after a prolongued period of problems, so I don't really have the right to intervene in our current problems, regardless of how acute they are, because I need to let a few more years pass. Why are we electing people like that?! Because by default we elect nice people, who avoid stepping on people's toes. Which is generally a good thing, but sometimes not. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - Project infrastructure team procedures
On Wed, Apr 30, 2008 at 05:21:41PM -0500, Manoj Srivastava wrote: On Wed, 30 Apr 2008 23:10:38 +0200, Josip Rodin [EMAIL PROTECTED] said: On Wed, Apr 30, 2008 at 08:42:59PM +0100, Clint Adams wrote: Why are we electing people like that?! Because by default we elect nice people, who avoid stepping on people's toes. Which is generally a good thing, but sometimes not. So, to compensate for electing bad leaders (people who are too nice to lead are bad leaders, generally), we put all kinds of nasty in a GR for them to beat the developers with? Er, that kind of reasoning actually goes against the whole Constitution, because it has all kinds of nasty in it for people to beat each other with. You shouldn't think of it that way :) People who can't see that all powers in Debian flow from the constitution, are too nice or tremulous o delegate people to core teams, who can only delegate when they feel blessed by the holy pee of this GR, are going to be a disaster anyway, and perhaps we should not make such people even marginally effective by having this GR. If they can't lead, perhaps they _should_ be wrapped in cotton wool and prevented from taking any action at all. I'd take that approach if there was even a hint of hope that an election could give us a leader without a goodness bias, but because this general trait is pretty much in the very core of the entire electorate, it's hopeless. We have to come to terms with how nice we are, and deal with it :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - Project infrastructure team procedures
On Wed, Apr 30, 2008 at 05:27:56PM -0500, Manoj Srivastava wrote: What bothers me about all this is that we had a nicely detaled document that spells out who has what rights, and it seems fairly clear to me that all powers in Debian stem from the powers laid down there; but that nicely detailed document is not enough. What makes one thing that any non-supermajority GR which says essentially the same thing as the constitution will have any weight? The Constitution is nicely detailed, but it doesn't recognize infrastructure teams. It doesn't have a generic handler (so to speak) for groups of developers - it does handle delegations which can expand into N developers, but this is done in a completely impractical way, judging by history. Are people who were grandfathered by the constitution (or some such equally silly argument) not also grandfathered by this forthcoming GR? What changes? That's a good question, and the reason why I initially proposed that we don't try to force the delegation/undelegation system as it is - it doesn't seem entirely appropriate for the teams because some things simply predate the notion of a project leader, it will easily seem anachronistic and pretentious for the leaders to be able to undelegate someone's access to something they've created and maintained for a decade, without requiring any sort of a criterion to base that decision on. But others don't seem to mind that... -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - Project infrastructure team procedures
On Sat, Apr 19, 2008 at 08:24:25PM +0200, Lucas Nussbaum wrote: I'm still not convinced that we need all that bureaucracy. Here is a draft amemdment. If we vote on both your proposal and this admendment, could you tell me why I should rank your proposal higher than the amendment? Apparently nobody's been enticed by the proposal in the last two weeks enough to second it, so there doesn't appear to be a reason, really ;) Debian developers acknowledge the following: * The Debian Project infrastructure is run by people who volunteer their time and knowledge in a good-faith effort to help the Debian Project. * The practice of existing members of a team having people join in and help, and new people volunteering without a particularly formal procedure, is the original and natural way of changing team membership. * Training of and otherwise working with new team members requires additional effort from existing team members, so care should be taken to avoid having too much team effort spent on unnecessary new members or new members who would not reciprocate the effort. * Infrastructure teams have to be stable, but they don't have to calcify. everything stays the same so far. Debian developers resolve the following: * Infrastructure teams are encouraged to adapt their sizes to their workloads, to ensure that they don't block or slow down the work of other Debian contributors. * Existing team members who don't sufficiently contribute to the team effort should be removed from the team. * When an infrastructure team slows down or blocks the work of other Debian contributors without taking the necessary actions, the Debian Project Leader is empowered to add or remove members to/from the team using delegations. When possible, this should be done by consulting the team first. - (suggestions of improvements are welcomed for the draft) Do you think that this will get a modicum of seconds? If so, do you think that that will happen primarily because the text is shorter, or primarily because it it's simple (it straightforwardly legitimizes delegations), or something else? Maybe my timing was bad, but no seconds, no objections, and one reply - that sounds like we have a showstopper problem with motivating people to do *anything* about this, and I'm thinking that we need to understand that before we think about more wording :) Hmm. In the last few weeks, we've seen a few DPL decisions go completely uncontested. Three people replied positively to Sam's decision on -devel, and nothing else. Is that indicative enough? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Proposal - Project infrastructure team procedures
Hi, This originates from the debian-project mailing list discussions at http://lists.debian.org/debian-project/2007/06/msg00020.html http://lists.debian.org/debian-project/2007/10/msg00064.html http://lists.debian.org/debian-project/2007/10/msg00142.html http://lists.debian.org/debian-project/2008/04/msg00042.html I've cleared up the remaining few issues reported against the fifth edit, and I am now looking for seconds at debian-vote to the following proposal: - Proposed general resolution - Project infrastructure team procedures Debian developers acknowledge the following: * The Debian Project infrastructure is run by people who volunteer their time and knowledge in a good-faith effort to help the Debian Project. * The practice of existing members of a team having people join in and help, and new people volunteering without a particularly formal procedure, is the original and natural way of changing team membership. * Training of and otherwise working with new team members requires additional effort from existing team members, so care should be taken to avoid having too much team effort spent on unnecessary new members or new members who would not reciprocate the effort. * Infrastructure teams have to be stable, but they don't have to calcify. * Ad hoc intervention by Debian Project Leaders is not a practical solution to resolve issues with infrastructure teams. The process of delegation and undelegation has not historically proven itself as an effective mechanism for improving infrastructure teams. There has also been ambiguity on the constitutional position of infrastructure teams as such, particularly those that predate it. * To avoid issues with teams which are not proactive with regard to adding or removing members, and to address aforementioned inadequacies and ambiguities, it is necessary to define a modicum of procedure for how developers can join the infrastructure teams. It is also necessary to properly engage the Debian Project Leader with the functioning of the infrastructure teams. Debian developers resolve the following: * The primary goals of this additional set of procedures are: * to improve the infrastructure teams * to maintain fairness towards both the teams and the developer body * to improve the relationship between the Debian Project Leader and the infrastructure teams * Should there be any ambiguity with a procedure, the people interpreting them are tasked with making sure that the general spirit of this resolution takes precedence over the exact letter of the rules, in the absence of a new resolution clarifying the ambiguity. * The set of procedures laid out below is not meant to be completely inclusive, both because we want to fix what is broken and keep everything else as it is, and because this is the first resolution on the matter. * Infrastructure teams are groups of developers who deal with project infrastructure and have access to resources in ways other than the standard practice of uploading Debian packages. * Whether a team in Debian constitutes an infrastructure team is decided by the Debian Project Leader. * Infrastructure teams have an ongoing responsibility to maintain a level of service that is generally acceptable to the developer body. * It is necessary for infrastructure teams to add new members when old members depart from the team or when circumstances prevent existing members from contributing to the team effort. * Infrastructure teams are encouraged to continue adding or removing members on their own accord. * Existing team members who don't sufficiently contribute to the team effort have to be marked by the rest of the team as latent. * Latent team members can be unmarked as such four months after marking, provided they become active again. * Team decisions regarding latent team members have to be communicated to the Debian Project Leader or to the developer body. * Developers can nominate themselves for membership in infrastructure teams. These nominations are communicated to the whole team and they can be made every four months. * Infrastructure teams have to decide to accept or reject candidates who nominated themselves. The basic requirements are: * Candidates for team membership have to demonstrate some minimal existing competence in the area. It is recommended for candidates to have helped the team in some way in the past. * Candidates for team membership have to pledge availability to the team. It is recommended that candidates pledge no less than twelve months of availability. * Candidates for team membership have to promise to make every reasonable effort to work with the existing team. * Teams can require any number of other qualities from the candidates, as determined by their specific circumstances. These qualities have to be determined by team consensus. * Team decisions regarding validity of candidates have to be
Re: Ballot for leader2008
On Sun, Apr 13, 2008 at 10:20:52PM -0500, Gunnar Wolf wrote: Do you really think we should change an old and overall good format? It's not a format, it's an introductory text. There is no negative aspect in making it a bit more logical and user-friendly, why are you making change sound like a big deal? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Final call for votes for the debian project leader election 2008
On Sun, Apr 13, 2008 at 10:58:34PM +0200, Luk Claes wrote: You can express your opinions on this list without any problem, though your opinion should not be expressed in an official reminder to vote as that can be interpreted as influencing the vote. I wouldn't go so far, it's not really influencing the vote. Which isn't to say that we still couldn't have easily done without those comments. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ballot for leader2008
On Sat, Apr 12, 2008 at 10:46:46PM -0500, Manoj Srivastava wrote: On Sun, 13 Apr 2008 03:44:12 +0200, Josip Rodin [EMAIL PROTECTED] said: But I see how it would help if the CFV was more verbose about that, and less verbose about other things. It goes on and on about the technicalities of the vote, and says to read the platforms twice (because the readers are idiots who need to have things repeated to them ;), The more I see of the mistakes that are still made, the less preposterous the last sentence becomes. I know... but it fails to simply say the ballot is the chunk of formatted text located five paragraphs down, nothing else. The draft ballot was posted to this list earlier; all this simple additions were not caught and proposed by anyone. Yes... and for the last 5-10 years too, it's been like this all the time, I'm not exculpating myself for failing to comment before :) Huh. Looking at the ballot: , | ... | Do not erase anything between the lines below and do not change the | choice names. Yes, you see, that's the point - the text just starts talking about not erasing something. Which lines below? - is not an illogical question. It's just automatically answered for anyone who actually spends the next 35 seconds reading the rest of the text... I propose that you make the beginning look like this: HOW TO VOTE First, read the full text of [...variable data...] The ballot is a small text form that is included below. It is cast by sending a filled out and signed form to a dedicated e-mail address, also included below. The form is marked with two lines containing the characters '-=-=-=-=-=-'. Do not erase anything between those lines, and do not change the choice names. [...] Also, it would probably help to make the sentence with the address stand out by adding a paragraph break after it: Mail the ballot to: [EMAIL PROTECTED] Don't worry about spacing [...] Another paragraph break before the last sentence might be good, too, because there it stops talking about formatting, and instead talks about how to get a fresh ballot. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ballot for leader2008
On Sat, Apr 12, 2008 at 10:40:01PM -0500, Manoj Srivastava wrote: If you think the vote period is too short, then I suppose there is the option to see if other people consider it so too, and see if you can redo some of the constitutional amendment that was passed by acclaim last year. On that topic - it doesn't look like the result was so bad after all. The drop in turnout could also be attributed to other things - we've seen the same thing in 2006, with the longer voting period. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ballot for leader2008
On Sun, Apr 13, 2008 at 02:51:59PM -0500, Manoj Srivastava wrote: I propose that you make the beginning look like this: HOW TO VOTE First, read the full text of [...variable data...] The ballot is a small text form that is included below. It is cast by sending a filled out and signed form to a dedicated e-mail address, also included below. That is not accurate. The ballot is the whole text after the line CALL FOR VOTE FOR YYY There is a portion of the ballot that you may not mangle; it is the only part of the ballot that devotee cares about -- but you may, and people do, send in the whole ballot. Other edit the ballot to only contain the parts devotee cares about. Well, I don't think that's really important to the typical user - people just want to know about the part they have to send back in. Whether you call this the ballot or the part of the ballot you have edit in order to vote, that doesn't really matter as long as it's immediately obvious where that part is. Can you present a sample ballot for, say, DPL election 2009? It might help to see a full ballot and compare the points of difference. Will do (in another mail). -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ballot for leader2008
On Sun, Apr 13, 2008 at 10:12:20PM +0200, Josip Rodin wrote: Can you present a sample ballot for, say, DPL election 2009? It might help to see a full ballot and compare the points of difference. Will do (in another mail). Here it is - with some other changes while I was at it. (I also couldn't find the references to [EMAIL PROTECTED] in the CFVs. Should there be some?) FIRST CALL FOR VOTES FOR THE DEBIAN PROJECT LEADER ELECTION 2009 = === = === === == === == Voting period starts 00:00:01 UTC on Sunday, March 30th, 2009 Votes must be received by 23:59:59 UTC on Saturday, April 12th, 2009 This vote is being conducted as required by the Debian Constitution. You may see the constitution at http://www.debian.org/devel/constitution. For voting questions contact [EMAIL PROTECTED] The details of the candidate platforms can be found at: http://www.debian.org/vote/2009/platforms/ HOW TO VOTE First, read the full text of the platforms and rebuttals. To cast a vote, it is necessary to send this ballot, with the text form filled out, to a dedicated e-mail address, in a signed message, as described below. The form is contained at the bottom of this message, marked with two lines containing the characters '-=-=-=-=-=-'. Do not erase anything between those lines, and do not change the choice names. There are 4 choices in the form, which you may rank with numbers between 1 and 4. In the brackets next to your preferred choice, place a 1. Place a 2 in the brackets next to your next choice. Continue until you reach your last choice. You may skip numbers, leave some choices unranked, and rank options equally. Unranked choices are considered equally the least desired choices, and ranked below all ranked choices. To vote no, no matter what, rank None Of The Above as more desirable than the unacceptable choices, or you may rank the None Of The Above choice and leave choices you consider unacceptable blank. (Note: if the None Of The Above choice is unranked, then it is equal to all other unranked choices, if any -- no special consideration is given to the None Of The Above choice by the voting software). Finally, mail the filled out ballot to: [EMAIL PROTECTED] Don't worry about spacing of the columns or any quote characters () that your reply inserts. The vote must be GPG signed (or PGP signed) with your key that is in the Debian keyring. The voting software (Devotee) accepts mail that either contains only an unmangled OpenPGP message (RFC 2440 compliant), or a PGP/MIME mail (RFC 3156 compliant). You may, if you wish, choose to send a signed, encrypted ballot. - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- e81e16a2-03b6-4340-84f2-51de89b8185f [ ] Choice 1: John Doe 1 [ ] Choice 2: John Doe 2 [ ] Choice 3: John Doe 3 [ ] Choice 4: None Of The Above - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- -- The responses to a valid vote shall be signed by the vote key created for this vote. The public key for the vote, signed by the Project secretary, is appended below. -BEGIN PGP PUBLIC KEY BLOCK- [...] -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ballot for leader2008
On Sun, Apr 13, 2008 at 05:25:40PM -0500, Manoj Srivastava wrote: b) move the address to send the ballot to up front, where we mention it. Good idea, and it can't hurt to repeat it. Maybe also warn against group-replies? I personally think that we should discourage such public voting, but I'm not sure what the policy is. c) Added back a second reminder of the upper and lower bounds for choices; every year, someone places an [ X ] next to their candidate. Reminding people that they need to enter a numeric value within fixed bounds seems to be important. Okay, good. I just wanted to skip the overly mathematical definition :) d) Added back the reminder to read the platforms. Again, experience has taught that lacking these reminders leads to people complaining that no one told them to read the actual proposal, and that they thought voting based on the subject of the GR or CFV was the right thing to do, and were shocked that their interpretation of the subject did not match the actual working of the change. They even went so far to accuse the secretary of fraud and deceit, which is unacceptable. I have to be the one bearing the brunt of the criticisms about the ballot; so if the reminders reduce some of these complaints, they stay. That's fair. Just one more seemingly trivial suggestion: add another line-break in this place: To cast a vote, it is necessary to send this ballot, with the text form (which is embedded later in this ballot) filled out, to a dedicated e-mail address, in a signed message, as described below. The dedicated email address this ballot should be sent to is: [-here-] [EMAIL PROTECTED] The form you need to fill out is contained at the bottom of this [...] That way the address stands out better, so nobody can't miss it. (Famous last words :) People tend to start skipping text at the end of a paragraph. And, not everbody is using a mail reader which emphasizes mail addresses in plain text. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Ballot for leader2008
On Sun, Apr 13, 2008 at 02:15:55AM +0100, Anand Kumria wrote: Especially when the instructions for requesting a ballot are frustrating incomplete and this was processed after the the cut-off. Who knew that attempting to engage an automated system from 21:54 GMT onwards in order to receive a ballot and then vote could be so arduous. I guess it's too late now, but the voting system is actually pretty trivial - each call for votes, such as the last one at: http://lists.debian.org/debian-devel-announce/2008/04/msg1.html ...contains the ballot - it's the text marked with Don't Delete Anything Between These Lines. But I see how it would help if the CFV was more verbose about that, and less verbose about other things. It goes on and on about the technicalities of the vote, and says to read the platforms twice (because the readers are idiots who need to have things repeated to them ;), but it fails to simply say the ballot is the chunk of formatted text located five paragraphs down, nothing else. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Technical committee resolution
On Thu, Apr 03, 2008 at 11:51:06PM +0200, Moritz Muehlenhoff wrote: And if so, what is the plan for wordpress in etch and lenny? I recommend to drop it from Lenny, but if people choose to repeat mistakes I won't waste my time on argueing. I don't quite see the point of this... http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=wordpress;dist=stable shows zero RC bugs, and I found two DSA-s for it, 1258 and 1502. The remaining filed bugs which relate to security are explicitly marked by the maintainers as too minor to warrant updates, so it doesn't look like the security team is particularly burdened. I don't see the wordpress inclusion as a mistake. Comparing it to the situation where we currently don't have mantis in etch, because of a similar bug report - there the decision wasn't elevated to tech-ctte as the package was unmaintained, so it went by unnoticed. The package was taken three months after the report, but by that time it was too late, I guess. As an application to which access is customarily restricted from the start (private bug tracking systems), mantis is even less of a real-world security problem, yet we've completely deprived etch users of a package, and this actually hurt the sarge users who can't upgrade to the improved version. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Technical committee resolution
On Fri, Apr 04, 2008 at 06:26:06PM +0800, Paul Wise wrote: On Fri, Apr 4, 2008 at 6:01 PM, Josip Rodin [EMAIL PROTECTED] wrote: http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=wordpress;dist=stable shows zero RC bugs, and I found two DSA-s for it, 1258 and 1502. The remaining filed bugs which relate to security are explicitly marked by the maintainers as too minor to warrant updates, so it doesn't look like the security team is particularly burdened. There are a number of open CVEs, some of them are not fixed in etch security updates: http://security-tracker.debian.net/tracker/binary-package/wordpress Yes, and...? Can you re-read my second sentence above? :) I've read through that list as well (thanks for the link) and it seems that most of them do seem to fit in the category of too minor to warrant updates - the program is vulnerable if you already have an existing attack vector, such as SQL injections, which are fixed, or admin privileges. Only the latest one seems to be available to all, with the precondition that the site allows random people to register (which should be sufficiently more common than sites which have random admins). In any case, I don't see any major burdens caused by the decision that would make it a mistake. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Technical committee resolution
On Thu, Apr 03, 2008 at 05:10:27PM -0700, Russ Allbery wrote: I do agree with Ian, however, that the tech-ctte is one of the worst examples for limiting hats for a slightly different reason: the tech-ctte needs to make decisions for the project that the project can then implement. Yes, this has been a weakness already, but one way in which that could be addressed is by having *more* tech-ctte members who are on core teams so that they can go make the resolution happen. I have to say that the word that ultimately sprung to my mind after reading this paragraph for the second time was - oligarchy. I know, I know, it's a far stretch from reality, but still, the idea doesn't quite sound so appealing if you look at it with that potential result in mind. But, let's disregard that for a moment, and recall the earlier topic of a perplexing issue that tech-ctte decided, the wordpress stable security situation. If the tech-ctte which was deciding that had included someone who was on the security team, and someone who was a maintainer of such PHP applications, do you think that such a tech-ctte would have come to a better decision? I'm not sure. I can't say that I would expect the existence of either expert on the committee improve the odds that wordpress security bugs would get handled differently a year later - we don't have any way of expecting that these people would be active in that situation long after the decision. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Technical committee resolution
On Thu, Apr 03, 2008 at 06:18:37PM +0100, Ian Jackson wrote: What that means is that it is very important that the TC has the very best people on it. But it is a fact of life - particularly in a volunteer project like Debian - that the best people are often the very same people who are doing the most other stuff. That is a fallacy - even if we assume that tech-ctte contains the very best people of Debian as a whole, and that's an unsufficiently supported assumption at that, we don't actually know with anywhere near the sufficient amount of certainty that they are the best people for committee membership. And that is orthogonal to the issue of the lack of time, which stands on its own. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Technical committee resolution
On Mon, Mar 31, 2008 at 11:34:37PM -0500, Manoj Srivastava wrote: Indeed, it does seem a bit strange to use those terms in this context, where me and the person whose idea you attacked are developers with no particular elevated position over you, and you are a member of the technical committee. What does my membership in the tech ctte have anything to do with the price of beans in Idaho? Are you implying that I would abuse the powers vested in the office in a petty manner? It did not even occcur to me, and the fact it occurred to you says something. Don't you see that your blunt rebuke for the idea can easily be understood as condescension, and that, in that light, it would be more prudent to avoid the flaming style as well as coarse language? I called the Idea silly. Still do. I refuse to be censored by your beliefs, whatever they might be. You certainly are not limiting your contribution to this discussion; I do not see my tech ctte membership as a handicap. This is what I referred to as the flaming style... You read one sentence, interpret it, reply to it; read next sentence, interpret it, reply to it. There is no caching. Without it, you get to think that I meant something in the first sentence, but I explicitly said what I meant in the second sentence. We agree to disagree, and that's fine, but please respect my paragraphs :) But in a reasonably serious discussion on the composition of the same committee, IMHO a bit more tact would be in order. Ultimately, for your own sake, certainly not mine... Err, is that some kind of a threat? Why would increasing my blood pressure by self censorship be good for my sake? This is puzzling (and somewhat amusing, I must confess) If I really have to spell it out... if people think you don't show tact and prudence where appropriate, they may not have a good opinion of you. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Technical committee resolution
On Sat, Mar 29, 2008 at 04:55:49PM -0500, Manoj Srivastava wrote: than to keep arguing subtle points about judgement. Again, your description of your previous posts seems somewhat more flattering than the posts themselves. Subtle points of judgement while continuing to hector away on other people's lack thereof does not seem to fit. I'd be less irritated were your posts less condescending. I suppose you could consider my opinions an act of patronizing because I was telling you how I think that you should behave (or rather, how I think you shouldn't behave). I'm sorry if I offended you, but I thought that I didn't cross the line of decency in my posts. Indeed, it does seem a bit strange to use those terms in this context, where me and the person whose idea you attacked are developers with no particular elevated position over you, and you are a member of the technical committee. Don't you see that your blunt rebuke for the idea can easily be understood as condescension, and that, in that light, it would be more prudent to avoid the flaming style as well as coarse language? I'm not saying that tech-ctte members shouldn't have the freedom to discuss matters on random project mailing lists as they see fit; it would be unreasonable to expect them to restrain their right to free speech in random discussions just because they happen to be in that position. But in a reasonably serious discussion on the composition of the same committee, IMHO a bit more tact would be in order. Ultimately, for your own sake, certainly not mine... -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Technical committee resolution
On Fri, Mar 28, 2008 at 09:45:59PM -0500, Manoj Srivastava wrote: [...] I was hoping for the best, but expecting the worst - I expected a point-by-point reply sigh but I was hoping that I wouldn't see one because I thought that you would see that I was just trying to explain the two opposing takes of the bigger picture, which both have some merit. And speaking of judgement - his proposition was to reconsider some rules based on a few data points, and it was reasonably mild and open-ended. Yet you dismissed it as silly, arbitrary and pointless - Bullshit. I did not dismiss his original proposition that people might be overburdened as silly -- I dismissed his one hat proposal as silly. Yes, and that would be okay, except that you went down on it in much force, without really referencing the real reason why it came about. Or, well, there was one reference to the original proposition - you had immediately called it a rant. My take on that is quoted below: IMO, people on whose judgement we depend on to make important decisions for the Project as a whole should put more emphasis on trying to understand other people's perspective than on engaging in an antagonistic debate. And again, whether that opinion of mine is relevant is a matter of judgement for the observers... I think I do understand Clint's maverick stance better than you credit me for. I suspect I understand his position better than you do -- we have spent quality time together driving out for groceries ranting about powers that be in Debian. So take your own advice, and undersant that I might have a different stance than the one you are jumping to conclusions about. I'm sorry, but that information isn't really logical to me and the other observers. We haven't seen anything much to support those claims, but we have seen a fair share of flaming. Now I once again hope that you don't reply in such an irritated manner, but history says to expect it again. :/ Anyway, I'll go away now and try to do something more productive than to keep arguing subtle points about judgement. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Technical committee resolution
On Fri, Mar 28, 2008 at 06:28:26PM -0500, Manoj Srivastava wrote: Any tech ctte member worth their salt would be involved in Debian beyond maintaining packages (if for nothing else to demonstrate they are qualified to be tech ctte members). I would think that in a project with 1000 alleged active members, we could easily limit privileged access to one instance per person without any serious problems. We could. We could also choose quite another set of silly criteria to limit various and sundry things by. The question is, why? Why one? A better criteria is not to limit oneself by arbitrary number games, but see where the maximal benefit to the project lies. If one person has the time or energy to manage one hundred hats, and do a better job of them than other candidates, why deprive the project due Clint's law of pointless limitations? How do you know where the *maximal* benefit to the project lies, if so many paths to benefit are never explored? How do you know that one person has the time or energy to manage N hats? Or, how do you know that we wouldn't actually improve their performance in N-M tasks if we take away M unnecessary tasks? How would you really know that they are doing a better job than other candidates when there is an inherent general limit imposed on the number of seats, and when there are circumstantial advantages of some candidates, all of which gives some people more chance to prove their worth over others and/or limits other people from showing what they can do? Yet, if you deprive those who want N hats of the possibility, they might get lost completely. Or taking away M tasks won't have a positive effect, but a negative one. Even worse, it might not have a straightforward effect, so we might not be able to clearly decide if it was right or wrong. And if we don't utilize the circumstantial advantages such as specific experience in a task, we risk wasting too much time rehashing issues that had already been dealt with in the past. All these unwieldy circumstances make the decision on the criteria a matter of judgement. And speaking of judgement - his proposition was to reconsider some rules based on a few data points, and it was reasonably mild and open-ended. Yet you dismissed it as silly, arbitrary and pointless - all much stronger words than his. IMO, people on whose judgement we depend on to make important decisions for the Project as a whole should put more emphasis on trying to understand other people's perspective than on engaging in an antagonistic debate. And again, whether that opinion of mine is relevant is a matter of judgement for the observers... -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Technical committee resolution
On Thu, Mar 27, 2008 at 07:04:09PM +, Ian Jackson wrote: Josip Rodin writes (Re: Technical committee resolution): Instead, I would suggest to do two things - first, institute a better process, one that doesn't so much focus on intricate stalemates (like the present 6.2 does), but one that focuses on how to generally get things done - such as a mandatory timetable for *everything*, even a very lax one. And secondly, make the DPL the oversight and backup option, but for *everything*, so that nothing can fall through the cracks. Since the DPL represents the developer body, it's simply a just logical fallback. I can see where you're coming from with this, but I'm afraid it won't work. DPLs have typically been reluctant to get involved in deciding disputes - particularly messy ones that others have failed to tackle. Well, that's a natural reaction, really, when the leader's mandate is so broadly defined, yet the first defined power of the DPL is to shed responsibility. If you want someone to do something, telling them that they could theoretically do it, and then showing them ways how not to do it sure sounds like an effective way to get them to avoid doing it. Having said that, that's probably a good default in general - don't mess with stuff randomly. But in the few specific places, it would help if they were encouraged to do stuff. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Q: All: Account creation latency
On Wed, Mar 19, 2008 at 10:24:17AM +0100, Raphael Hertzog wrote: I know that account creation would be quick so long as you're active in the team That sentence could have ended right there, the fact that there is a SPoF there is problematic enough. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Technical committee resolution
On Mon, Mar 10, 2008 at 01:48:28PM +1100, Anthony Towns wrote: there's not much that can be done internally to improve things, and since it's almost entirely self-appointed and has no oversight whatsoever [...] The idea is to encourage DPLs to appoint two new members during their term, I'm thinking this is too radical for its own good. You need to fix the problem of practically exclusive self-appointing which creates a really unnecessary aura of immutability. But you don't have to do it by going to the other extreme allowing the DPL to appoint basically arbitrarily and in a way that they can theoretically affect decisions right off the bat. Don't get me wrong - it may not actually be a bad idea, but it won't pass because it has too many possible subtle twists, and people will rightfully protest that. Witness this thread, for example :) Instead, I would suggest to do two things - first, institute a better process, one that doesn't so much focus on intricate stalemates (like the present 6.2 does), but one that focuses on how to generally get things done - such as a mandatory timetable for *everything*, even a very lax one. And secondly, make the DPL the oversight and backup option, but for *everything*, so that nothing can fall through the cracks. Since the DPL represents the developer body, it's simply a just logical fallback. That kind of a change will not by itself appear to fix any outstanding problems any time soon. However, in practice it should put pressure on the committee members so that they make more effort to fix problems themselves, because they'll want to avoid things going to the DPL, even if it's a distant possibility. Which reminds me, I need to go reboot the infrastructure team composition proposal... -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: soc-ctte default position, was: electing multiple people
On Fri, Oct 19, 2007 at 01:48:44PM +0100, MJ Ray wrote: I assumed that soc-ctte would intervene somehow on any issue referred to them, even if it is just to say let the existing processes stand. If it ends up at soc-ctte, there is a problem to resolve. [...] What should be soc-ctte's default position? To do nothing, or to announce their (maybe-weak) support for the existing situation? [...] This is getting needlessly intricate - most people won't care for the difference between doing nothing and formally deciding to do nothing :) Please don't be daft. That's not my suggestion: it's the difference between doing nothing and doing something to support the existing situation. Also, I think soc-ctte should do, not formally decide. There are lots of project practices, both formal and informal, and written and customary, which will pre-date soc-ctte and I expect some of them will be challenged by referring to soc-ctte. Some of those will split soc-ctte, if it represents the project at all well, so I think we need to try to be clear about what we want from soc-ctte in those cases. Personally, I expect soc-ctte to do something to support the existing situation when they think it's fair overall. We've seen situations where doing nothing has allowed complaints to fester. Well, that's like saying they should act on common sense. Why would we ever want to say that it should support an existing situation even if it is not fair? Please see Message-ID: [EMAIL PROTECTED] on -project for my last take on this general stance. But, we've strayed from the topic of debian-vote, let's move this back to debian-project... I prefer to keep this topic on a development list, rather than hidden on a miscellaneous one. It's developers who may vote on it. Uhh, debian-project is not a miscellaneous list for hiding things, at least it's not any less miscellaneous than debian-vote. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: electing multiple people
On Wed, Oct 10, 2007 at 10:55:28AM +0100, MJ Ray wrote: There is the oft-mentioned optimal team size of about seven active members. http://www.qsm.com/process_01.html http://knowledge.wharton.upenn.edu/article.cfm?articleid=1501 How many more than seven would we need, to expect seven to be active? In one of my university classes I was told that the axiomatic overhead for telecommunications is 40%... and that's just for hardware and software, no mention of humanware :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: soc-ctte default position, was: electing multiple people
On Wed, Oct 10, 2007 at 11:02:09AM +0100, MJ Ray wrote: Russ Allbery [EMAIL PROTECTED] wrote: It depends. Being able to reach consensus may make it easier for the soc-ctte to look at the situation and go there's strong disagreement here and even if we're mostly on one side, we realize that and we should decide that we can't really intervene. [...] This raises a question. I assumed that soc-ctte would intervene somehow on any issue referred to them, even if it is just to say let the existing processes stand. If it ends up at soc-ctte, there is a problem to resolve. However, the above suggests that if soc-ctte is weakly divided (mostly on one side), it shouldn't intervene. What should be soc-ctte's default position? To do nothing, or to announce their (maybe-weak) support for the existing situation? As you may know, I believe that ignoring problems is a bug, so I'd expect soc-ctte to make decisions, even if mostly null, rather than do nothing. If it will mostly do nothing, is it worth creating it? This is getting needlessly intricate - most people won't care for the difference between doing nothing and formally deciding to do nothing :) But, we've strayed from the topic of debian-vote, let's move this back to debian-project... -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: electing multiple people
On Mon, Oct 08, 2007 at 04:48:20PM -0700, Russ Allbery wrote: I think this runs the same risk as the original US Vice Presidential election system. If you elect the runner-up as part of the same slate as the winner, you end up with pathological results in a divisive election with two or more opposing slates. Basically, you end up electing the leaders of each slate and calling them the winning group, resulting in a team of people who have sharp disagreements and who may not be able to work together. I've had enough bad experiences with committees and groups in the past that I've developed a deep dislike of voting or nomination systems that don't take into account the ability of the chosen slate to work with each other. I'd rather end up with a weaker candidate who can cooperate with the leading candidate than the two strongest candidates who will then be at loggerheads. That argument makes sense for technical groups, where accomplishing a clearly defined task is the primary mission, but this is supposed to be the basis for electing the first ever social committee, which doesn't have a straightforward mission (or at least, we're inventing the mission ad hoc :). If the underlying social group is indeed divided into two proportionate major factions who are in conflict with each other, then that is who should be in the social committee in order to fairly represent the voting body. And at the same time, if the voters think that there are two minor factions with a conflict that doesn't interest the voters, and they are minor, they will (hopefully) not vote for them so they won't get elected. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: electing multiple people
On Tue, Oct 09, 2007 at 02:47:20PM +1000, Anthony Towns wrote: Or, we could elect a list directly (ie each option is a list of people willing to work together as SC), which would allow to elect a SC which is actually representative for Debian. This means parties, and I don't see any proof that this would help with being representative? It doesn't necessarily mean parties in the normal sense. You could, eg, have two rounds of nominations; first letting people nominate themselves to be on the committee, then letting the nominees pick their dream team, so if your nominees for a three person committee are Alice, Bob, Carol, Dave, Eve, and Fred, they might pick their teams as: Alice, Carol, Eve Bob, Carol, Fred Carol, Bob, Alice Dave, Bob, Carol Eve, Alice, Bob Fred, Carol, Dave ie, you can get a genuine mix, rather than just a party-line split (Alice, Carol, Eve versus Bob, Dave and Fred, eg). Another problem is how to determine the number and choice of permutations to use if there are e.g. 10 candidates who suggest 40 options? A huge ballot is quite unwieldy, and its sorting sounds like an easily contested issue :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: electing multiple people
On Mon, Oct 08, 2007 at 05:33:54PM +0200, Josip Rodin wrote: +If the election requires multiple winners, the list of winners is +created by sorting the list of options by ascending strength. +If there are multiple winners with the same ranking which exceed +the desired length of the list, the length of the list is extended +to include the entire last set of multiple winners. Is this technically sound? I don't know voting method syntax. So, scrapping that - how does the election of multiple candidates in the SPI board election work? (weasel?) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: electing multiple people
On Tue, Oct 09, 2007 at 01:38:26AM -0700, Russ Allbery wrote: I've had enough bad experiences with committees and groups in the past that I've developed a deep dislike of voting or nomination systems that don't take into account the ability of the chosen slate to work with each other. That argument makes sense for technical groups, where accomplishing a clearly defined task is the primary mission, but this is supposed to be the basis for electing the first ever social committee, which doesn't have a straightforward mission (or at least, we're inventing the mission ad hoc :). Hm, my experience is that this is *way* more important for social groups than it is for technical groups. Now, if one is electing essentially a legislature, where each member is expected to vote and work independently, it's not as big of a problem. But if the group is ever expected to work by consensus or common ground, this sort of voting system is, IMO, a huge problem. I don't get it. Isn't the point of consensus to get agreement from an entire group, or at least the entire relevant part of the group? If we use a voting system that aims to eliminate conflicting options, and instead have a small set of compatible options win, then that's not really aiming for a consensus, it's just aiming for a majority. If the social committee represents only the majority, it instantly loses credibility, and in Debian, that would pretty much be its ruin. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: electing multiple people
On Tue, Oct 09, 2007 at 02:22:41AM -0700, Russ Allbery wrote: The problem most often materializes when there are heated opinions, but the fundamental problem is when people can't work together with mutual respect. If you end up with people who intensely dislike each other, the group will have an exceedingly hard time reaching consensus on anything. MJ and Bernhard made good points already, I'll just concentrate on a few bits that troubled me: I don't agree with these two premises - that any two elected Debianites would so intensely dislike each other to cause a deadlock in the rest of the group, or that this deadlock would spread onto all other issues (other than the one they over which they originally came in conflict). I do not see any historical precedent in Debian history to reach that harsh a conclusion. One of the things that I find troubling about the idea of the social committee is that I think it takes the idea of a democratic body and some vague notions that smart people can work anything out and applies them to problems that are considerably thornier than the technical problems our existing example deals with. Constructing organizations that can effectively deal with social problems is way harder than constructing a technical committee and I'm worried that insufficient attention is being paid to some of the fuzzier aspects of how such a group can work together. It's not just a matter of us Debianites really being smart people who can work anything out :) it's that we actually currently try to do the soc-ctte job in conflict situations *without* having a soc-ctte, and we generally succeed. And the whole project is practically a social experiment, we deal with social problems every day, whenever there's a misunderstanding on a bug report or a squabble on the mailing lists. Having soc-ctte couldn't undo this history of good faith effort to get along with each other; should it ever go so perverted to actually harm the... social fabric of the project(?) we can always repeal it. I am perhaps excessively wary, having served on the governance boards of things like Usenet hierarchy administration in the past and having seen some of the spectacular ways in which this can go wrong. Boards of directors do do this sort of thing all the time. But they usually don't have to address quite the same kind of problems. Yes, and the circumstances in these two types of organization are different - in both cases the membership comes together to work on a common interest, but there is an inherent desire to maintain control of the organization. In Debian, however, we really have no tangible control over the organization, because the main asset of the organization is - the people. (Hm, that sounded awfully like the network is the computer :) If the social committee represents only the majority, it instantly loses credibility, and in Debian, that would pretty much be its ruin. I think it depends a lot on what role you expect the committee to take. If the role of the committee is to serve as peacemaker and facilitator, it doesn't matter as much whether or not it's representative; it would matter a great deal more whether the members were people capable of acting in that role. In either case it would not be nearly as useful if it wasn't credible. History has shown, in real life and in Debian, that ad hoc peacemakers can't get much work done, whenever the parties in conflict don't put trust in them. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: electing multiple people
On Tue, Oct 09, 2007 at 02:29:23AM +1000, Anthony Towns wrote: To select events coordinators, for example, we might want to have five people each on a different continent, even though three of the best events coordinators happen to be in Europe, on the basis that one European, one North American and one South/Latin American would be more useful than three Europeans. BTW, that's the question of whether a single election with multiple winners is the right election to use. In that case, it's better to simply have five elections, one for each continent, but allowing the same candidate to run for more than one seat. :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: electing multiple people
On Tue, Oct 09, 2007 at 09:24:41AM -0500, Manoj Srivastava wrote: The problem most often materializes when there are heated opinions, but the fundamental problem is when people can't work together with mutual respect. If you end up with people who intensely dislike each other, the group will have an exceedingly hard time reaching consensus on anything. MJ and Bernhard made good points already, I'll just concentrate on a few bits that troubled me: I don't agree with these two premises - that any two elected Debianites would so intensely dislike each other to cause a deadlock in the rest of the group, or that this deadlock would spread onto all other issues (other than the one they over which they originally came in conflict). I do not see any historical precedent in Debian history to reach that harsh a conclusion. Err. I see an immediate historical precedent, which in fact lead to a recent expulsion. Several mailing lists became poisoned to the level that people left off volunteering. If it happened once, it can happen again ... Oh, but that's just not the same, the expulsed person was not an elected member of a general committee. The best historical precedents for a lot of disagreement on general positions was when everyone was pissed off at Bruce, or even better when aj and you disagreed about policy, but those situations were settled in a much calm manner than the Sven affair. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: electing multiple people
On Tue, Oct 09, 2007 at 09:26:53AM -0500, Manoj Srivastava wrote: To select events coordinators, for example, we might want to have five people each on a different continent, even though three of the best events coordinators happen to be in Europe, on the basis that one European, one North American and one South/Latin American would be more useful than three Europeans. BTW, that's the question of whether a single election with multiple winners is the right election to use. In that case, it's better to simply have five elections, one for each continent, but allowing the same candidate to run for more than one seat. :) If the same candidate wins all elections, or if people from one city win all elections, would that be an acceptable outcome? I wasn't trying to provide an end-all solution to the said problem :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: electing multiple people
On Tue, Oct 09, 2007 at 07:45:53PM +0100, Ian Jackson wrote: That is: the DPL should propose candidates, which the electorate will separately vote on. Well, what can I say other than - the scheme where we depend on the DPL to propose candidates doesn't work if the DPL never does anything even approaching the actual proposal of candidates :) Maybe it would be best to put this whole part off until there's a general GR affirming the charter. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: electing multiple people
On Mon, Oct 08, 2007 at 06:08:41PM +0200, Lucas Nussbaum wrote: couldn't we get cycles using that? Alternatively, we could iteratively elect: - winner1: the winner with all candidates - winner2: the winner with all candidates minus winner1 - winner3: the winner with all candidates minus [winner1, winner2] - etc using the same tally sheet You can't do that and keep all the 'goodness' of our voting system, because doing that loses the interdependencies of votes. I don't know how to explain it properly :), please see: http://lists.debian.org/debian-project/2007/06/msg00318.html Or, we could elect a list directly (ie each option is a list of people willing to work together as SC), which would allow to elect a SC which is actually representative for Debian. This means parties, and I don't see any proof that this would help with being representative? It's probably better than the first solution, as the first solution isn't clone-proof: we could have elected n Sams!! ;) There should be some sentence in the constitution that can be interpreted as a rule against cloning... :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: electing multiple people
On Mon, Oct 08, 2007 at 07:26:42PM +0300, Antti-Juhani Kaijanaho wrote: So, I proposed the following addition to the section A.6. Vote Counting (part of appendix A Standard Resolution Procedure): The method you suggest suffers from not delivering proportional results. See discussion in http://lists.debian.org/debian-project/2007/06/msg00318.html and http://lists.debian.org/debian-project/2007/06/msg00261.html Let's not invent our own bad voting systems. Er, but I didn't suggest that. Or at least I don't think I did - or is the picture provided at the vote.d.o generated by applying the iterative method? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: electing multiple people
On Mon, Oct 08, 2007 at 12:02:26PM -0500, Manoj Srivastava wrote: Er, but I didn't suggest that. Or at least I don't think I did - or is the picture provided at the vote.d.o generated by applying the iterative method? The pictures are my very own, minimal computation, not-to-be- taken-seriously-but-present-some-pretty-pictures-that-in-most-cases- do-not-depart-too-far-from-the-truth. In no way are these pretty graphics to be taken as a basis of actually making decisions; they present instead a rough graphical view of the pair wise defeats in a method only suited to finding a single winner. You should then reorganize the pages to put the actual data used to make the outcome first, and the purely informative picture later. Right now the picture is shown as the first thing under the Outcome heading, which is not right. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: electing multiple people
On Mon, Oct 08, 2007 at 02:54:18PM -0500, Manoj Srivastava wrote: I think you misunderstand. The graph is a perfectly clear representation of the pairwise defeats as it corresponds to the single winner outcome; and it shows the relative strengths of the defeats. There is nothing wrong with it -- as long as you do not try to project and use that data for multi-winner predictions. All the candidates are rpesented, and the relative pairwise defeats are presented -- quite correctly. Assuming that the pairwise defeats have something to do with global ordering is a leap, however, and not one which is promoted by the web page. Uh, yes, it is. The picture clearly orders candidates from top to bottom, so it's a fair assumption. But never mind. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GR idea related to ongoing licensing discussions
On Wed, Jun 06, 2007 at 10:40:57AM -0700, Russ Allbery wrote: - it seems to be pandering to literalists in a similar way to the Editorial Changes GR and that hasn't really ended those arguments; I disagree strongly with the latter part of that statement. Various people are still *upset* about the Editorial Changes GR, but at least from where I'm sitting, it did a lot to resolve the *argument*. In other words, there are far fewer people now arguing that the project really does intend to allow non-free documentation in main. There are more people upset about the fact that the project doesn't want to do this, but that's inevitable and more honest than the previous state. Umm... the way I read this paragraph was - we didn't actually make any real progress, but the back-and-forth movement was made in a direction that you find honest (and therefore preferable[1]), so it's okay? :) -- 2. That which causes joy or happiness. [1] as 'increased honesty' is a matter of opinion, not necessarily fact -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for GR: clarifying the license text licensing / freeness issue
On Mon, Apr 23, 2007 at 12:37:16PM +1000, Ben Finney wrote: Yes, the social contract says that the Debian system and all of its components will be fully free; but for all practical intents and purposes (heh), the accompanying license texts are as much a component of the system as is the media the system is distributed on. I don't see the relevance of this. If you're referring to the GPL-specific exception for source code No, I'm not, I'm referring to the second sentence in the document, 'We promise that the Debian system and all its components will be free according to these guidelines.'. Yes, you can't do without it, but you also can't start obsessing on it because the matter can soon get absurd after that. (There is no free hardware to run it on, oh my!) When hardware is something distributable by the Debian project as part of Debian, then this might be relevant; it isn't an issue with current technology. License texts *are* distributed by Debian, now, under terms that are non-free. This behaviour doesn't match the Social Contract. Sure, they are technically being distributed, but not as something the social contract cares about. (Pardon the personification.) Lawyers would likely ask us - what would be the legal purpose of addressing this concern? Why would lawyers ask us that, and why are their questions about the Social Contract germane here? It's not a legally-binding document. My point exactly. There is no reason to apply the we must clarify everything and anything in order to not get sued legal logic. Trying to clarify the social contract by elaborating on peripheral things that aren't immediately obvious, is basically nitpicking, and it shouldn't be done. I would think thazt *only* things which are immediately obvious are exempt from the need for clarification. Anything else needs to at least be considered on its merits, and not dismissed because it's not immediately obvious. It is being considered on its merits, it's not dismissed because it's not immediately obvious, but because it's nitpicking. Also, nobody cares for statements that can be normalized to 'you can do all this, except that, that, that, and that', and those should also be avoided if we want readers to take the spirit of the document seriously. I don't see how that's at all true. Contrariwise, I would hope you agree that a document that says we will always do this, and never do that, but which is routinely violated in practice, is one that readers will not take seriously. Except that we seem to disagree on whether the obligatory distribution of licenses, regardless of their own license, falls under the that which we promised never to do. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for GR: clarifying the license text licensing / freeness issue
On Mon, Apr 23, 2007 at 07:42:02PM +0900, Charles Plessy wrote: 'We promise that the Debian system and all its components will be free according to these guidelines.'. Dear Josip, are you really sure that the licences are components of the Debian system? If one removes them, the system, on a functionnal point of view, still works as before... Nothing Depends: on the licences. Er, you should be arguing that with the other person, because that's what I said previously :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for GR: clarifying the license text licensing / freeness issue
On Mon, Apr 23, 2007 at 09:48:51AM -0400, Clint Adams wrote: Egad, it sounds like you actually live in an evil parallel universe where idealism is inherently dishonest and false. That universe must really suck. :) There's a difference between idealism and lying about adhering to one's ideals. Yeah, and we're not lying about adhering to our ideals simply by distributing the obligatory license data. If we weren't doing that, we'd have no product of our ideals because we couldn't distribute it. (Oh my god we betrayed our idealism by adhering to the copyright law!!!1!) Please, try to remember the spirit of those promises, rather than trying to find gremlins in them. Utter crap. I'm automatically impressed by your argument there. :P -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for GR: clarifying the license text licensing / freeness issue
On Tue, Apr 24, 2007 at 08:24:39AM +1000, Ben Finney wrote: There's a difference between idealism and lying about adhering to one's ideals. Yeah, and we're not lying about adhering to our ideals simply by distributing the obligatory license data. If we weren't doing that, we'd have no product of our ideals because we couldn't distribute it. That's a false dichotomy. It ignores the option to tell the truth: i.e., to make our promise match our behaviour, if we feel that behaviour is right. Again the truth. We're not getting anywhere with this. ... imagining notes saying you need to be able to read and write in order to use our mailing lists, because otherwise we're being dishonest to all those poor users who expect us to tell the truth about it ... -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for GR: clarifying the license text licensing / freeness issue
On Tue, Apr 24, 2007 at 08:07:03AM +1000, Ben Finney wrote: The Social Contract makes a promise we are not keeping. You say it's not ... something the social contract cares about. That's not at all clear from reading it -- the social contract makes a straightforward promise, which has no exception for this, yet we're acting as though such an exception were there. The social contract is not making any exceptions; the law of the land is. It goes without saying that we will be applying the copyright law to our stuff; should we explicate the fact that we do that, just in case someone thinks that by implicitly abiding by the copyright law we're doing something Wrong(TM)? What else do we have to account for? Maybe talk about how developer time is not free and it's possible for it to shrink to zero one day, invalidating the whole deal. Maybe talk about how we can easily be derelict in communicating with upstream. Maybe talk about hiding some of the stuff we get at the BTS because it's marked by anti-spam filters. Talk about the delay in publishing data from the BTS because the computers are not infinitely fast. Hey, the fourth clause is very general, let's dissect that one, too - let's explicate how all volunteers have a mind of their own and each has the option of prioritizing differently, even if slightly. Sometimes there will be computing environments which we think we can't adjust to - let's say so clearly. What if we fail to provide an integrated system of high-quality materials? Let's put the fact that we may be carrying lower quality materials up front. We could go on and on, stating all those promises we are not keeping. (We should really be having an existential crisis by now...) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for GR: clarifying the license text licensing / freeness issue
On Sun, Apr 22, 2007 at 09:30:51AM +1000, Ben Finney wrote: [The status quo] doesn't address the concern that motivated this discussion: that the license texts which have restrictions on modification are non-free works by the DFSG, yet are being distributed in Debian against the Social Contract. This concern DOES NOT NEED TO BE ADDRESSED. It needs to be IGNORED. You seem to be saying that a violation of the social contract should be ignored. There's a difference between an ignorable concern and a violation. Yes, the social contract says that the Debian system and all of its components will be fully free; but for all practical intents and purposes (heh), the accompanying license texts are as much a component of the system as is the media the system is distributed on. Yes, you can't do without it, but you also can't start obsessing on it because the matter can soon get absurd after that. (There is no free hardware to run it on, oh my!) Lawyers would likely ask us - what would be the legal purpose of addressing this concern? Will anyone ever be able to bring on a legitimate complaint against us for violating the social contract by distributing license texts? (So would we be eliminating that risk by addressing the concern?) I don't think so. (Somebody ranting on a random Internet forum about how evil Debian includes evil licenses is not automatically a legitimate complaint :) Trying to clarify the social contract by elaborating on peripheral things that aren't immediately obvious, is basically nitpicking, and it shouldn't be done. Also, nobody cares for statements that can be normalized to 'you can do all this, except that, that, that, and that', and those should also be avoided if we want readers to take the spirit of the document seriously. Lastly, being dissected by people who like to think that official documents need to resemble mathematical proofs is not really the purpose of the social contract. Yes, I sometimes do those things too, so I'm not trying to blithely disrespect the said group. It's just that sometimes we who do that need to curb our enthusiasm. :) -- 2. That which causes joy or happiness. (Reading on -vote, not on -legal.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Request for GR: clarifying the license text licensing / freeness issue
On Tue, Apr 17, 2007 at 03:59:08PM -0400, Nathanael Nerode wrote: Frankly I'd be happy with any honest solution. Currently the promise made in the Social Contract is very stark, very bold, and also untrue. The DFSG are very stark and bold about this as well. Lots of must, never and 100%, which simply isn't what's going on. Egad, it sounds like you actually live in an evil parallel universe where idealism is inherently dishonest and false. That universe must really suck. :) If the promise were, say, Debian will remain 99 44/100% free, I wouldn't worry about this stuff! I was really hoping that the above hyperbole would be the last bit of near-absurdity in your message, but you just outdid yourself there :( Please, try to remember the spirit of those promises, rather than trying to find gremlins in them. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Project Leader Elections 2007: Draft ballot
On Wed, Mar 28, 2007 at 02:46:23PM -0500, Manoj Srivastava wrote: It eases the parsing of occasional corner cases with some voters, yes, but if forces *all* voters to read something that is inherently confusing. Well, let me provide a more accurate analogy - if you pay several bills with that money, the bills don't have numbers assigned to them that you have to know about, they simply have the names of the recipients. Thanks for proving my point. Every single one of those bills have a serial number, which, like the Choice N string, is of little interest to me. I, there fore, ignore it Because you can do so easily - the designer of the note made sure to print the value in a much larger font and made it stand out, while he put the serial number somewhere peripheral and smaller where barely anyone notices. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Project Leader Elections 2007: Draft ballot
On Tue, Mar 27, 2007 at 04:11:53PM -0500, Manoj Srivastava wrote: redundant information eases parsing of potentially MTA mangled ballots It eases the parsing of occasional corner cases with some voters, yes, but if forces *all* voters to read something that is inherently confusing. Given that ballots can be word wrapped, can have common leading text, might have words that are damaged by MUA's not encoding a non-ascii word identically; it makes sense to increase the robustness of the parser by giving it a well known, unique prefix. I don't see how any of that is more important than having a straightforward text for the voters to read. This is a user interface, it is not a machine interface; robustness towards the human eyes and minds is more important than robustness towards code parsers IMO. Word wrapping and leading text is fairly inconsequent so they can be eliminated (disallowed) without much problem. Non-ASCII options are possible with e.g. people's names, but if we know for a fact that they aren't supported by the entire voting environment, they should be avoided. I should hope that people wouldn't be fussy about it given that we have already standardized on the English language anyway. (Raphael? :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Project Leader Elections 2007: Draft ballot
On Wed, Mar 28, 2007 at 08:13:03AM -0500, Manoj Srivastava wrote: redundant information eases parsing of potentially MTA mangled ballots It eases the parsing of occasional corner cases with some voters, yes, but if forces *all* voters to read something that is inherently confusing. [ ] Choice 1: F [ ] Choice 2: Baar Is inherently confusing? To whom? Are you personally confused? or are you speculating? That is inherently confusing because you also have to use the numbers 1 and 2 for the rankings. Using the same set of options for two different things, where you could use two distinct sets of options for each different thing, is what is inherently confusing. Do we really want opinions from someone who is confused by Choice N:? :) I knew this was going to come up :) Obviously all of us can understand the distinction between using numbers as rankings, and using numbers as designations, once it is explained. Point is, we shouldn't have to be explaining it when it can be done another, more straightforward way. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Project Leader Elections 2007: Draft ballot
On Wed, Mar 28, 2007 at 12:31:00PM -0500, Manoj Srivastava wrote: redundant information eases parsing of potentially MTA mangled ballots It eases the parsing of occasional corner cases with some voters, yes, but if forces *all* voters to read something that is inherently confusing. [ ] Choice 1: F [ ] Choice 2: Baar Is inherently confusing? To whom? Are you personally confused? or are you speculating? That is inherently confusing because you also have to use the numbers 1 and 2 for the rankings. Using the same set of options for two different things, where you could use two distinct sets of options for each different thing, is what is inherently confusing. Actually, I used numbers for lots more things. I used numbers to count money to pay for my coffee this morning. One dollar, Two dollars. I, however, failed to get confused with the rankings for my vote with the money I counted out. Well, let me provide a more accurate analogy - if you pay several bills with that money, the bills don't have numbers assigned to them that you have to know about, they simply have the names of the recipients. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Project Leader Elections 2007: Draft ballot
On Wed, Mar 21, 2007 at 10:45:40PM -0500, Manoj Srivastava wrote: [ ] Choice 1: Wouter Verhelst ... [ ] Choice A: None Of The Above Would it be possible to use just letters, rather than both letters and numbers ? That will make everything a little less confusing - in particular it makes it impossible to mistake rankings for choices and vice versa. Just don't think of 0xA as a latter, since it is not. Anyway, internally devotee uses numbers starting at 1 for the ranking as well as the options on the ballot. We strayed from the real point here... the point is that these internal variables are completely irrelevant to the voters and should be avoided. The program can detect the line [ ... ] Option name just as easily as it can detect [ ... ] specialstring: Option name. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Project Leader Elections 2007: Draft ballot
On Sat, Mar 10, 2007 at 02:01:38PM -0800, John H. Robinson, IV wrote: In the brackets next to your preferred choice, place a 1. Place a 2 in the brackets next to your next choice. Continue till you reach your last choice. In the brackets next to your preferred choice, place an A. Place a B in the brackets next to your next choice. Continue till you reach your last choice. [...] This change seems way too obvious to not be seen before. It removes all conceivable confusion. Actually, I think that combining numbers/letters designating choices with numbers/letters designating rankings is inherently confusing. Choices shouldn't need to have a name or a letter designating them; that's an internal variable that the voter doesn't care about. As far as rankings are concerned, using 1, 2, 3, ... is a good default. With over 26 candidates, the English alphabet runs out, so while it is applicable here, it may not be suitable in larger votes. OTOH, one could argue that 'lower is better' with those rank numbers is not as intuitive as 'higher is better'. While I'm at it, it would probably be fun to implement a 'higher is better' ranking parser in a way to allow someone to vote for example 13-53-32-5-1-_-3-2-2-_-1. Yet, that would probably confuse voters if they were comparing that vote with a vote like 12-24-23-7-2-1-5-3-3-1-2 - because those two different votes would be considered equal in the eyes of the parser script. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Questions to the candidates
On Fri, Mar 02, 2007 at 05:47:45AM +0100, Simon Richter wrote: The idea itself is not a bad one, however during the entire course of the experiment it was never questioned by the proponents that we should go through with it. Declaring it an experiment did not have the desired effect of magically creating a lab environment without connection to the outside world, so a bit of risk assessment would have been in order. I agree with the assessment about declaring it an experiment. However, I don't think it's fair to say that not even a *bit* of risk assessment was done, because Anthony and others posted a lot to elaborate the 'pro' position in the successive discussions, where he argued about the various risks, too. Maybe those explanations were broken, or insufficient, or off-topic, or evil, or whatever, but please explain that, don't just dismiss them without a modicum of explanation. I'm also not exactly comfortable with the idea that proponents not questioning the execution of what they are proposing is a negative thing. (Let's set aside the fact that the idea morphed along the way as it came upon obstacles, implying that the proponents questioned at least some aspects of the idea enough to change them.) My main point is - for people to contemplate an idea, decide they want to do it, and then stick with the gist of it until they succeed in implementing it - is such a thing really a negative one? That would be too harsh IMO. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
questions to candidates about communication
Hi, How much time do you generally have to read Debian-related e-mail? How much for the Debian mailing lists? How many lists do you follow, and which ones do you pay real attention to? Have you stopped following a Debian mailing list in the past, and if so, what was the most important/common reason for that? Could you describe an indicative example or two where you formed a distinctly positive or a distinctly negative opinion about a person based on what they wrote in a non-trivial flamewar^Wdiscussion? (There is no need to name anyone, just describe the situation as you feel is appropriate.) What's your opinion on what it's like for others to be reading our mailing lists? Feel free to be vague here :) In general, what's your opinion about the quality of communication in the project? Freely elaborate this last part :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What your ballot should look like if you're in favor of releasing sarge
On Sat, Jun 26, 2004 at 09:03:48AM +0200, Andreas Barth wrote: So, what do we all learn from this for the future? _That's_ the major question for me. I learned that we[1] tend to screw up and concentrate on the wrong things in mailing list discussions: by the time an important point is reached, it's too late for it to make a dent on the collective consciousness... -- 2. That which causes joy or happiness. [1] including myself, no exceptions :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What your ballot should look like if you're in favor of releasing sarge
On Thu, Jun 24, 2004 at 05:11:47PM -0700, Thomas Bushnell, BSG wrote: The current vote will determine what the majority of voters think. Hopefully that will be the end of it. Not likely. The last vote determined what 3/4 of the voters thought, and people weren't willing to let that be the end of it. Uh, no, how many times and how many people will have to say that the title and description were suboptimal (to put it mildly) before you are convinced that the ballot didn't actually match what many voters thought? I don't recall you complaining at the time about the title or description. Perhaps because nobody ever hinted that the resolution would cause the release manager to change things? Heck, I didn't see any hints that the resolution _could_ cause any such thing. (I'm not subscribed to -vote so if it was mentioned there I missed it, but then, at least half the voting body isn't subscribed to it, either, nor should it have to be.) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What your ballot should look like if you're in favor of releasing sarge
On Fri, Jun 25, 2004 at 01:30:03PM +0200, Andreas Barth wrote: I don't recall you complaining at the time about the title or description. Perhaps because nobody ever hinted that the resolution would cause the release manager to change things? Heck, I didn't see any hints that the resolution _could_ cause any such thing. (I'm not subscribed to -vote so if it was mentioned there I missed it, but then, at least half the voting body isn't subscribed to it, either, nor should it have to be.) Anthony himself told that very plain on -vote, but in a mail in the non-free-removal thread that was killfiled at that time by most people reading -vote. Great... I went and checked the archive, and there is indeed nothing of the sort in neither the thread that started at [1] nor the one that started at [2]. There are literally thousands of messages in the mailing list archive for -vote during the period listed in the vote records, and I could only find this[3] under a slightly differently named thread, and only after I have now explicitely searched for aj's posts. Overall I just can't come to the conclusion that voters who failed to catch this information[4] before it came into effect brought it all onto themselves. -- 2. That which causes joy or happiness. [1] http://lists.debian.org/debian-vote/2004/01/msg01526.html [2] http://lists.debian.org/debian-vote/2004/01/msg01192.html [3] http://lists.debian.org/debian-vote/2004/04/msg00048.html [4] http://lists.debian.org/debian-vote/2004/04/msg00074.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Discussions in Debian
On Fri, Jun 25, 2004 at 01:25:46PM -0400, Raul Miller wrote: He was right that time. On Fri, Jun 25, 2004 at 02:07:04PM +0200, Josip Rodin wrote: No, he wasn't. An ad hominem argument appeals to non-rational things, whereas Hamish pointed out two facts: that Andrew started two general resolutions and that both of them were rather divisive. I believe you're thinking of http://www.nizkor.org/features/fallacies/personal-attack.html I was thinking of http://www.nizkor.org/features/fallacies/ad-hominem-tu-quoque.html Interesting. However, here the third part of the argument didn't involve the implication that statement X is false; rather, the implication was that the aforementioned statement is true and that person A is the topic of it. :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What your ballot should look like if you're in favor of releasing sarge
On Wed, Jun 23, 2004 at 11:27:07PM -0700, Thomas Bushnell, BSG wrote: The current vote will determine what the majority of voters think. Hopefully that will be the end of it. Not likely. The last vote determined what 3/4 of the voters thought, and people weren't willing to let that be the end of it. Uh, no, how many times and how many people will have to say that the title and description were suboptimal (to put it mildly) before you are convinced that the ballot didn't actually match what many voters thought? I just counted 45 unique proposers/seconders in this GR (and that doesn't include those who said nothing should change). That alone is over a fifth of the total voters of the previous GR. That's a non-negligible percentage if you ask me. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Analysis of the ballot options
On Sat, Jun 19, 2004 at 07:47:07PM +0100, Andrew Suffield wrote: I would point out that historically, Debian does not release before it is ready, and that's why our releases usually work so well. Option 3 is the release before it is ready, because releasing is more important than being ready option. Option 6 is the better rather than sooner option. Non sequitur - the premise is vaguely correct, but I disagree that the two conclusions follow from it. It doesn't make sense to me that readiness and usability of Debian releases are to be achieved by removing stuff that was not supposed to be removed just a while ago. Only if you take it as a given that the old release policy was correct. Otherwise it's just that heads have been forcibly removed from the sand now. Well, the old release policy can't have been all that wrong given that nobody actually proposed changing it -- the proposal was clearly aimed at clarifying the language of the social contract, not at changing its intent and/or purpose. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Analysis of the ballot options
On Sat, Jun 19, 2004 at 10:56:49PM +0200, Andreas Barth wrote: [ ] Choice 6: Reaffirm the current SC[needs 1:1] Choice 6 is titled wrong. It's not a reaffirmation of the social contract, it's an affirmation of a certain interpretation of the social contract. An affirmation of another interpretation of the social contract was not allowed to be put on the ballot. Not allowed? Really? And all this time I thought that my opinion was simply in a minority so small that nobody bothered making a proposal out of it! :) sigh -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Analysis of the ballot options
On Sun, Jun 20, 2004 at 10:07:35PM +0200, Andreas Barth wrote: [ ] Choice 6: Reaffirm the current SC[needs 1:1] Choice 6 is titled wrong. It's not a reaffirmation of the social contract, it's an affirmation of a certain interpretation of the social contract. An affirmation of another interpretation of the social contract was not allowed to be put on the ballot. Not allowed? Really? And all this time I thought that my opinion was simply in a minority so small that nobody bothered making a proposal out of it! :) See http://lists.debian.org/debian-vote/2004/06/msg0.html (for the proposal, seconded by Eduard Bloch, Michael Schiansky, Marco d'Itri, Marc Haber, John H. Robinson (IV), giving the required quorum of the constitution), and rejected by the secretary in that form because it also spoke about the release interval, see http://lists.debian.org/debian-vote/2004/06/msg00035.html | I am just saying that portions of this proposal, as it reads | now, do not address the issue that the current GR addresses, and | must needs go on another ballot, and another vote. Hmm, yeah, the short point appeared to have gotten sidetracked by all that verbiage, and the promise of yearly release sounds optimistic at best. I'd second a resolution that simply said that we acknowledge that the meaning of the first clause of the social contract, regardless of whether we say free according to the DFSG or free software or free monkeys, is not set in stone and its interpretation is variable. Another option on the same resolution would be that the interpretation is exactly this-and-that, but with the difference that the people would actually be voting for or against something concrete and their votes couldn't be interpreted to mean something else than what was advertized and what they intended. ``Eliminate or expand inaccurate references to software.'' *snicker* *sigh* -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Analysis of the ballot options
On Sat, Jun 19, 2004 at 03:35:58PM +0200, Eike zyro Sauer wrote: PS: I'm still sure that 1, 2, 3, 5 and 6 include dropping the GPL text from Debian (AKA suicide) sooner or later. I don't want to discuss this again, as it has been discussed in depth already, I just want to mention. Yeah, but most people on the lists seem not to be overly worried about that interpretation. I guess the votes on options 4 and 6 respectively will determine what the average Debianites really think, but should 6 prevail over 4, it's better to have voted for something like 3 or 5 and that way at least prevent 6 from winning. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment of Proposal - Deferment of Changes from GR 2004-003
On Wed, Apr 28, 2004 at 06:10:24PM +0100, Colin Watson wrote: I propose this amendment replacing my previous one: Points 1. and 2. above are removed and replaced with: 1. that the following text be appended to the first clause of the Social Contract: We apologize that the current state of some of our documentation and kernel drivers with binary-only firmware does not live up to this part of our Social Contract. While Debian 3.1 (codenamed sarge) will not meet this standard in those areas, we promise to rectify this in the following release. The first clause of the Social Contract as amended will read as follows: Debian will remain 100% free We provide the guidelines that we use to determine if a work is free in the document entitled The Debian Free Software Guidelines. We promise that the Debian system and all its components will be free according to these guidelines. We will support people who create or use both free and non-free works on Debian. We will never make the system require the use of a non-free component. We apologize that the current state of some of our documentation and kernel drivers with binary-only firmware does not live up to this part of our Social Contract. While Debian 3.1 (codenamed sarge) will not meet this standard in those areas, we promise to rectify this in the next full release. 2. that the paragraph added to the Social Contract by this Resolution shall be removed from the Social Contract upon the next full release of Debian after Debian 3.1 (codenamed sarge), without further cause for deliberation. Potential seconders, please note that this supersedes my previous proposed amendment. Yeah, this makes a wee bit more sense than vorlon's proposal because it doesn't impose a fixed time limit and instead deals with it in relative terms. I don't see any seconds yet, so here's one. -- Josip Rodin (signed) signature.asc Description: Digital signature
Re: Amendment of Proposal - Deferment of Changes from GR 2004-003
On Wed, Apr 28, 2004 at 06:10:24PM +0100, Colin Watson wrote: I propose this amendment replacing my previous one: Points 1. and 2. above are removed and replaced with: 1. that the following text be appended to the first clause of the Social Contract: We apologize that the current state of some of our documentation and kernel drivers with binary-only firmware does not live up to this part of our Social Contract. While Debian 3.1 (codenamed sarge) will not meet this standard in those areas, we promise to rectify this in the following release. The first clause of the Social Contract as amended will read as follows: Debian will remain 100% free We provide the guidelines that we use to determine if a work is free in the document entitled The Debian Free Software Guidelines. We promise that the Debian system and all its components will be free according to these guidelines. We will support people who create or use both free and non-free works on Debian. We will never make the system require the use of a non-free component. We apologize that the current state of some of our documentation and kernel drivers with binary-only firmware does not live up to this part of our Social Contract. While Debian 3.1 (codenamed sarge) will not meet this standard in those areas, we promise to rectify this in the next full release. 2. that the paragraph added to the Social Contract by this Resolution shall be removed from the Social Contract upon the next full release of Debian after Debian 3.1 (codenamed sarge), without further cause for deliberation. Potential seconders, please note that this supersedes my previous proposed amendment. Yeah, this makes a wee bit more sense than vorlon's proposal because it doesn't impose a fixed time limit and instead deals with it in relative terms. I don't see any seconds yet, so here's one. -- Josip Rodin (signed) signature.asc Description: Digital signature
debian-ctte@d.o should be aliased to @lists
On Mon, Apr 26, 2004 at 12:40:24PM -0400, Raul Miller wrote: I'm just following up to note that [EMAIL PROTECTED] does not forward to the technical committee (and apparently you won't get a bounce ...). Hmm... this feature might be a contributing factor on some of the complaints that the committee is not very responsive. Someone should have told -admin to add an explicit alias debian-ctte: [EMAIL PROTECTED] because otherwise it gets expanded into the ~debian user and archived semi-randomly... -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Social Contract GR's Affect on sarge
On Mon, Apr 26, 2004 at 02:56:09PM +1000, Anthony Towns wrote: The Social Contract now states: ] 1. Debian will remain 100% free ] ] We provide the guidelines that we use to determine if a work is free ] in the document entitled The Debian Free Software Guidelines. We ] promise that the Debian system and all its components will be free ] according to these guidelines. We will support people who create or ] use both free and non-free works on Debian. We will never make the ] system require the use of a non-free component. As this is no longer limited to software, and as this decision was made by developers after and during discussion of how we should consider non-software content such as documentation and firmware, I don't believe I can justify the policy decisions to exempt documentation, firmware, or content any longer, as the Social Contract has been amended to cover all these areas. Um, even before while it was limited to software, those who were of the opinion that documentation and such things are part of software still had a fairly valid point. The new phrasing, IMO, changes nothing. On the other hand, it's reasonable to expect that the release manager has a say (if not the final and overriding say) in determining the interpretation of ambiguous documents and how they apply to the release process. Hence, if you wish to make what I feel are non sequitur conclusions with regards to what the SC says, it's your prerogative, but don't try to blame it on the developer body (which includes myself). -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Social Contract GR's Affect on sarge
On Tue, Apr 27, 2004 at 01:10:47PM -0400, Stephen Frost wrote: That is bot, BTW, how quorum works. You would need at least 46 people to change the foundation documents, as long as they were of one mind. I find it amusing that we have people who were horrified how hard it would be to change a foundation document when that GR was proposed, and now we have another set horrified at how easy it is change one. I don't see why you should be. I expect most were concerned with the 3:1 super-majority requirment and didn't even consider or think about the quorum. Certainly, I didn't at the time. I do think the quorum requirement for foundation documents needs to be increased. I'd be tempted to suggest 40%-50% of developers but the fact that we didn't get much above that for the DPL election makes me concerned that there's too many MIA developers on our roles for that to work. A third sounds doable, though, and at least remotely representative. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[EMAIL PROTECTED] should be aliased to @lists
On Mon, Apr 26, 2004 at 12:40:24PM -0400, Raul Miller wrote: I'm just following up to note that [EMAIL PROTECTED] does not forward to the technical committee (and apparently you won't get a bounce ...). Hmm... this feature might be a contributing factor on some of the complaints that the committee is not very responsive. Someone should have told -admin to add an explicit alias debian-ctte: [EMAIL PROTECTED] because otherwise it gets expanded into the ~debian user and archived semi-randomly... -- 2. That which causes joy or happiness.
Re: Social Contract GR's Affect on sarge
On Mon, Apr 26, 2004 at 02:56:09PM +1000, Anthony Towns wrote: The Social Contract now states: ] 1. Debian will remain 100% free ] ] We provide the guidelines that we use to determine if a work is free ] in the document entitled The Debian Free Software Guidelines. We ] promise that the Debian system and all its components will be free ] according to these guidelines. We will support people who create or ] use both free and non-free works on Debian. We will never make the ] system require the use of a non-free component. As this is no longer limited to software, and as this decision was made by developers after and during discussion of how we should consider non-software content such as documentation and firmware, I don't believe I can justify the policy decisions to exempt documentation, firmware, or content any longer, as the Social Contract has been amended to cover all these areas. Um, even before while it was limited to software, those who were of the opinion that documentation and such things are part of software still had a fairly valid point. The new phrasing, IMO, changes nothing. On the other hand, it's reasonable to expect that the release manager has a say (if not the final and overriding say) in determining the interpretation of ambiguous documents and how they apply to the release process. Hence, if you wish to make what I feel are non sequitur conclusions with regards to what the SC says, it's your prerogative, but don't try to blame it on the developer body (which includes myself). -- 2. That which causes joy or happiness.
Re: Social Contract GR's Affect on sarge
On Tue, Apr 27, 2004 at 01:10:47PM -0400, Stephen Frost wrote: That is bot, BTW, how quorum works. You would need at least 46 people to change the foundation documents, as long as they were of one mind. I find it amusing that we have people who were horrified how hard it would be to change a foundation document when that GR was proposed, and now we have another set horrified at how easy it is change one. I don't see why you should be. I expect most were concerned with the 3:1 super-majority requirment and didn't even consider or think about the quorum. Certainly, I didn't at the time. I do think the quorum requirement for foundation documents needs to be increased. I'd be tempted to suggest 40%-50% of developers but the fact that we didn't get much above that for the DPL election makes me concerned that there's too many MIA developers on our roles for that to work. A third sounds doable, though, and at least remotely representative. -- 2. That which causes joy or happiness.
Re: First Call for votes: General resolution for the handling of the non-free section
On Fri, Mar 12, 2004 at 09:19:40AM +0200, Mikko Moilanen wrote: Declare it as nonfree and I will quit immediatly using Debian, and I will remove Debian from my relatives and friends too. OH MY GOD!! NOO!!!1! Ahem. We grew out of the ..., or I quite! argumentation a few years ago in Debian. dist-upgrade your mental pathways, or get no support. (Funny how our release logic applies to other things :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First Call for votes: General resolution for the handling of the non-free section
On Fri, Mar 12, 2004 at 09:19:40AM +0200, Mikko Moilanen wrote: Declare it as nonfree and I will quit immediatly using Debian, and I will remove Debian from my relatives and friends too. OH MY GOD!! NOO!!!1! Ahem. We grew out of the ..., or I quite! argumentation a few years ago in Debian. dist-upgrade your mental pathways, or get no support. (Funny how our release logic applies to other things :) -- 2. That which causes joy or happiness.
Re: First Call for votes: General resolution for the handling of the non-free section
On Wed, Mar 10, 2004 at 08:37:20PM -0800, Thomas Bushnell, BSG wrote: I don't know if that's sufficient, but I know that it can do a lot to make the meek feel more welcome, to know that people will stand up. Except that proposing foundational document ammendments is not for the meek. If someone steps up and publically proposes something that has, among other things[1], consequences that are negative towards someone else, they should expect to hear objections, and that includes the hostile ones as well. It would be downright ludicrous to expect that everyone will be treading lightly in such a setting.[2] Whether cas actually crossed the line in the amount of profanity, that's debatable, but the let's make everything better for the meek program[3] just isn't relevant to it. -- 2. That which causes joy or happiness. [1] or not, regardless [2] heck, if we went around passing such changes without stirring any trouble, what kind of lame herd of cats would we be? ;) [3] regardless of whether such a program is worthwhile (I think it is) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: First Call for votes: General resolution for the handling of the non-free section
On Wed, Mar 10, 2004 at 08:37:20PM -0800, Thomas Bushnell, BSG wrote: I don't know if that's sufficient, but I know that it can do a lot to make the meek feel more welcome, to know that people will stand up. Except that proposing foundational document ammendments is not for the meek. If someone steps up and publically proposes something that has, among other things[1], consequences that are negative towards someone else, they should expect to hear objections, and that includes the hostile ones as well. It would be downright ludicrous to expect that everyone will be treading lightly in such a setting.[2] Whether cas actually crossed the line in the amount of profanity, that's debatable, but the let's make everything better for the meek program[3] just isn't relevant to it. -- 2. That which causes joy or happiness. [1] or not, regardless [2] heck, if we went around passing such changes without stirring any trouble, what kind of lame herd of cats would we be? ;) [3] regardless of whether such a program is worthwhile (I think it is)
Re: First Call for votes: General resolution for the handling of the non-free section
On Thu, Mar 11, 2004 at 11:22:37AM -0800, Thomas Bushnell, BSG wrote: alas, that doesn't happen on mailing lists. instead, it goes on for weeks or months until it pisses somebody off enough to finally say something about it - unfortunately triggering another round of pedantic frothing-at-the-mouth by wowser-imitations scoring cheap points whining about the swearing. Then don't swear. It's rude, it's unacceptible, and it needs to stop. I say it's not unacceptable, and it doesn't necessarily need to stop. It's enough that you guys want to kick out non-free, don't kick out swearing, too :) I see. The mailing list policy prohibits swearing, does it not? Don't make me laugh... the extent of the acceptance and enforcement of the mailing list code of conduct is common knowledge. BTW, you broke it right there yourself by Cc:ing me personally. -- 2. That which causes joy or happiness.
Re: Just a single Question for the Candidates
On Sat, Mar 06, 2004 at 09:05:27AM +, Peter Samuelson wrote: Is this just a game to you? I wondered how many messages it would take for someone to notice. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Just a single Question for the Candidates
On Sat, Mar 06, 2004 at 09:05:27AM +, Peter Samuelson wrote: Is this just a game to you? I wondered how many messages it would take for someone to notice. -- 2. That which causes joy or happiness.
Re: Just a single Question for the Candidates
On Thu, Mar 04, 2004 at 10:04:09AM +1100, Ben Burton wrote: Vague fears of persecution are a sign of mental instability which can't be fixed by an operating system free or otherwise. Vague fears?? I don't think it would take either of us very long to find examples of rude, dismissal and condescending behaviour in the BTS or mailing lists. Claiming someone who hesitates to jump into a social environment that is sometimes friendly but sometimes hostile to be mentally unstable is not really the most eloquent way to make your point. At the very least, it certainly helps make these vague fears more realistic. I agree, though it should be noted that Debian at least tries to be an equal opportunity hostile place -- _everyone_ gets abused :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Just a single Question for the Candidates
On Thu, Mar 04, 2004 at 03:07:47PM -0500, Raul Miller wrote: I agree, though it should be noted that Debian at least tries to be an equal opportunity hostile place -- _everyone_ gets abused :) Not really equally, however -- more visible people tend to get more abuse than less visible people. [Consider James Troup as a rather recent example of this.] Yeah, but we don't put newbies in such a position. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Just a single Question for the Candidates
On Thu, Mar 04, 2004 at 10:04:09AM +1100, Ben Burton wrote: Vague fears of persecution are a sign of mental instability which can't be fixed by an operating system free or otherwise. Vague fears?? I don't think it would take either of us very long to find examples of rude, dismissal and condescending behaviour in the BTS or mailing lists. Claiming someone who hesitates to jump into a social environment that is sometimes friendly but sometimes hostile to be mentally unstable is not really the most eloquent way to make your point. At the very least, it certainly helps make these vague fears more realistic. I agree, though it should be noted that Debian at least tries to be an equal opportunity hostile place -- _everyone_ gets abused :) -- 2. That which causes joy or happiness.
Re: Just a single Question for the Candidates
On Thu, Mar 04, 2004 at 03:07:47PM -0500, Raul Miller wrote: I agree, though it should be noted that Debian at least tries to be an equal opportunity hostile place -- _everyone_ gets abused :) Not really equally, however -- more visible people tend to get more abuse than less visible people. [Consider James Troup as a rather recent example of this.] Yeah, but we don't put newbies in such a position. -- 2. That which causes joy or happiness.
Re: Call for votes for the Condorcet/Clone proof SSD voting methods GR
On Wed, Jun 11, 2003 at 01:03:39AM +1000, Hamish Moffatt wrote: why doesn't the search engine find any references to [the constitution] at all? Please file a bug... (Note that the first match on the site map for constitution works.) -- 2. That which causes joy or happiness.
Re: Proposal - non-free software removal
On Fri, Nov 15, 2002 at 02:13:00PM +, Andrew Suffield wrote: In the event that this counter-amendment should become active, I propose the following amendment to it, replacing its complete text: Craig Sanders is a louse, and shall be crushed by a falling cow. I'd first have to see the license of that cow... we don't want to use non-free cows to squash people, now do we ;) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
