Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]
On Mon, 8 Oct 2007, Josip Rodin wrote: Well, that was so in June, but apparently everybody including the leader forgot about this in the last three months. Wrong. You did not forgot. I also did not forgot, but wanted to revisit the video of the BOF which to my knowledge was not yet published (perhaps we should ask the video team for the location of the recording stream?) to make up my mind a little bit more. So, it looks now that that was one of those things that seemed like a good idea at the time but in practice it doesn't work. Well, I think as long as there is no practice at all we could not not draw this conclusion. I bet that this topic would immediately would be back on the table if we would have another problem showing up here - on the other hand I'm very happy that we had such a quiet time since Edinburgh. Very productive ... ;-) Thanks for bringing this up again Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]
Andreas Tille [EMAIL PROTECTED] (09/10/2007): I also did not forgot, but wanted to revisit the video of the BOF which to my knowledge was not yet published (perhaps we should ask the video team for the location of the recording stream?) Are you referring to [1]? If so [2] looks like it to me (and also with s/low/high/ in the URL). 1. https://penta.debconf.org/~joerg/events/93.en.html 2. http://meetings-archive.debian.net/pub/debian-meetings/2007/debconf7/low/349_Solving_social_problems_via_soc-ctte.ogg Cheers, -- Cyril Brulebois pgpkmGmzQweJH.pgp Description: PGP signature
Re: soc-ctte discussion at DebConf7
On Sun, 1 Jul 2007 22:54:53 +0200 (CEST), Andreas Tille [EMAIL PROTECTED] said: On Sun, 1 Jul 2007, Manoj Srivastava wrote: I am not talking about _not_ having a soc-ctte. I am talking about whether or not the selection criteria for ctte members needs to be looked at with due consideration to the cultural diversity. I'm afraid that we will have not enough volunteers from different cultures. This might well be the case. But I can see where an informed electorate can make a different decision for party selection if they keep cultural diversity in mind. So the practical solution might be as simple as adding a note to the charter of the soc ctte admonisng them to be aware of these issues; and for the entity selecting members to also be aware as well. Moreover it is hard to separate between different cultures. There is no sharp borderline between cultures and there are people who belong to more than one culture. While boundaries might be blurred, let me assure you that the cultural background in Tennessee is distinctly different from that in the Scottish highlands, and palpably so; and both are a world apart from the culture of nothern India. So this is a quite weak criterium to choose members for a soc-ctte from. I dunno. I think there is a wide diversity in cultural norms and expectations (the news headlines scream with the effects); and just because there are crossovers and individuals and families who straddle the divide is no reason to pretend that the differences do not exist, or can not be catered to. I think I understood perfectly your concerns - but I see no practical solution. I just hope that a soc-ctte that is elected according to the rules we mentioned will be able to understand social aspects that are brought up by a person who has the kind of trouble you have in mind. Well, the re are practical solutions, and there are practical solutions. Let not the perfect be the enemy of an adequate solution. While we might never be able to get a perfectly unbiased, culture neutral and yet culture sensitive soc ctte, as you rightly fear; we can still add language to the charter of the soc ctte to remind the members of this aspect of their duty long after this conversation has been forgotten. Based on recent conversation in the list, I would suggest that the proportionality criteria for party list selection be given emhpasis for electing the members, so the minority cultures do not fail to have representation on the ctte, drowned our by the dominant cultural subgroups. Just for the sake of interest: What would you say to which cultural group you would belong? Me? I belong to the modern diaspora of migrants stuck between diverse cultures, belonging perfectly to neither. I think modern migrants like me are often better at recognizing two vastly different, and often opposed, but equally valid takes on issues that our social and cultural sets take. And no, you do not want me on your soc ctte. manoj -- He whose path devas, spirits and men cannot know, whose inflowing thoughts are ended, a saint - that is what I call a brahmin. 420 Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: soc-ctte discussion at DebConf7
On Mon, 2 Jul 2007, Manoj Srivastava wrote: This might well be the case. But I can see where an informed electorate can make a different decision for party selection if they keep cultural diversity in mind. So the practical solution might be as simple as adding a note to the charter of the soc ctte admonisng them to be aware of these issues; and for the entity selecting members to also be aware as well. Would you be able and willing to provide such a note you have in mind? Me? I belong to the modern diaspora of migrants stuck between diverse cultures, belonging perfectly to neither. I think modern migrants like me are often better at recognizing two vastly different, and often opposed, but equally valid takes on issues that our social and cultural sets take. This sounds very reasonable. And no, you do not want me on your soc ctte. Well, it's not me who wants anybody. At first we need volunteers. Than we will run a procedure to pick the final set from. It was just me who had a lightening (well - at least I thought it was) chat with you. ;-) Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]
On Wed, Jun 27, 2007 at 01:27:00PM +0200, Jacobo Tarrio wrote: Just nitpicking, but is our Condorcet method for running election suitable for voting when an (ordered) set of result is expected? Isn't it targeted at finding only one winner (if it exists)? Not a big It's targeted to finding the one winner, but it's easy to adapt to finding a list: get the winner, then remove it from the list of options and get the new winner, then remove it from the list of options and get the new winner, etc. I never proposed that, for reasons made obvious by other people in the thread. My ammendment to the standard resolution procedure was this: + li If the election requires multiple winners, the list of winners is +created by sorting the list of options by ascending strength. Instant disclaimer - I don't know if this is clear enough, I don't know voting method syntax. The point is that the list of options is *sorted*, and then N are taken as winners. It's not run in a loop of N iterations. And by sorted I mean the thing we get from the beat matrix, such as in: http://www.debian.org/vote/2007/vote_001#outcome If for example in that outcome we wanted to pick four candidates, it seems to me that they would be Hocever, McIntyre, Herzog, Verhelst. If for example we wanted to pick seven, we couldn't go past the first six. In that graph, no two options happened to be at the same horizontal level. If by any chance we got that situation, my ammendment further stated: +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. I thought that that made sense. Others? -- 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 discussion at DebConf7
Josip Rodin [EMAIL PROTECTED] writes: + li If the election requires multiple winners, the list of winners is +created by sorting the list of options by ascending strength. Why couldn't we just use some STV method for such elections? STV is a tried and proved method, no need for us to start inventing new methods. -- * Sufficiently advanced magic is indistinguishable from technology (T.P) * * PGP public key available @ http://www.iki.fi/killer * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: soc-ctte discussion at DebConf7
On Sun, Jul 01, 2007 at 01:28:00PM +0300, Kalle Kivimaa wrote: Why couldn't we just use some STV method for such elections? STV is a tried and proved method, no need for us to start inventing new methods. Many of the tried and proved STV methods are faulty. (Perhaps not as faulty as iterating Condorcet, but still:) -- Antti-Juhani Kaijanaho, Jyväskylä http://antti-juhani.kaijanaho.fi/newblog/ signature.asc Description: Digital signature
Re: soc-ctte discussion at DebConf7
On Sun, 01 Jul 2007 13:28:00 +0300, Kalle Kivimaa [EMAIL PROTECTED] said: Josip Rodin [EMAIL PROTECTED] writes: + li If the election requires multiple winners, the list of winners is + created by sorting the list of options by ascending strength. Why couldn't we just use some STV method for such elections? STV is a tried and proved method, no need for us to start inventing new methods. Most traditional STV methods suffer from free riding (in which strategic voting as in not voting for people who you want to vote for, but who will, in your opinion, win anyway) and vote management. There is a modified STV method, that also satisfies the condorcet method, and falls back to our current mechanism for a single winner. Our current method has been demonstrated to satisfy Pareto, monotonicity, resolvability, independence of clones, reversal symmetry, Smith-IIA, Schwartz, Woodall's plurality criterion, and Woodall's CDTT criterion, etc. I think we should consider the paper pointed out by Antti-Juhani Kaijanaho, found at http://m-schulze.webhop.net/schulze2.pdf manoj -- There are no saints, only unrecognized villains. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: soc-ctte discussion at DebConf7
On Sat, 30 Jun 2007 22:17:27 +0200 (CEST), Andreas Tille [EMAIL PROTECTED] said: On Fri, 29 Jun 2007, Manoj Srivastava wrote: In other words, we share a common technical culture. This is not the case for social culture of the community; and this distinction would tend to make a difference, in my opinion. Well, we discussed it in private at DebConf (when I lost my live in an assassin attack ;-)). I wonder in how far you think different cultural aspects are regarded if there is no social committee at all. Not very much, if at all, I would imagine. So we have the choice to do either nothing against social problems in Debian or just give a soc-ctte a chance to try - your comments about the cultural diversion might be a helpful guideline here - but in my opinion no argument against a soc-ctte. Why does everyone see any discussion at all in the mailing list a binary, either-or, confrontational debate? I am not talking about _not_ having a soc-ctte. I am talking about whether or not the selection criteria for ctte members needs to be looked at with due consideration to the cultural diversity. Based on recent conversation in the list, I would suggest that the proportionality criteria for party list selection be given emhpasis for electing the members, so the minority cultures do not fail to have representation on the ctte, drowned our by the dominant cultural subgroups. manoj ps: is it so hard to believe that people who actually want to improve a proposal are not all rah-rah cheer leaders for the idea? Or that all skeptics are not locked in a life-or-death struggle to scuttle the proposal? -- Experiments must be reproducible; they should all fail in the same way. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: soc-ctte discussion at DebConf7
On Sun, 1 Jul 2007, MJ Ray wrote: Andreas Tille [EMAIL PROTECTED] wrote: [...] So we have the choice to do either nothing against social problems in Debian or just give a soc-ctte a chance to try [...] That's a false dilemma. For example, I suggested letting email lists (suffering most badly ATM) promote their own admins in http://lists.debian.org/debian-project/2007/06/msg00258.html It's not soc-ctte or nothing! We could take smaller steps first! Sounds like out of context quoting. My post was about regarding cultural aspects of soc-ctte. I wonder if you think that list master intervention might serve cultural aspects better than a soc-ctte. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: soc-ctte discussion at DebConf7
On Sun, 1 Jul 2007, Manoj Srivastava wrote: So we have the choice to do either nothing against social problems in Debian or just give a soc-ctte a chance to try - your comments about the cultural diversion might be a helpful guideline here - but in my opinion no argument against a soc-ctte. Why does everyone see any discussion at all in the mailing list a binary, either-or, confrontational debate? I admit my posting sounded a little bit binary - but it was not intended to be that way. Even if I would consider myself as one of the first ones who brought up this idea I'm not really convinced that it is an appropriate mean to solve our problems. But for the moment I do not see a suggestion that sounds more promissing. I am not talking about _not_ having a soc-ctte. I am talking about whether or not the selection criteria for ctte members needs to be looked at with due consideration to the cultural diversity. I'm afraid that we will have not enough volunteers from different cultures. Moreover it is hard to separate between different cultures. There is no sharp borderline between cultures and there are people who belong to more than one culture. So this is a quite weak criterium to choose members for a soc-ctte from. I think I understood perfectly your concerns - but I see no practical solution. I just hope that a soc-ctte that is elected according to the rules we mentioned will be able to understand social aspects that are brought up by a person who has the kind of trouble you have in mind. Based on recent conversation in the list, I would suggest that the proportionality criteria for party list selection be given emhpasis for electing the members, so the minority cultures do not fail to have representation on the ctte, drowned our by the dominant cultural subgroups. Just for the sake of interest: What would you say to which cultural group you would belong? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Multi-winner elections, soc-ctte (Was: Re: soc-ctte discussion at DebConf7)
On Fri, Jun 29, 2007 at 02:43:24PM -0500, Manoj Srivastava wrote: It should be relatively straight forward for Devotee to find the winner, take the winner out of contention the next round, find the next winner (ignoring any pairwise contests dealing with any candidate no longer in the contest), and continue until the number of candidates desired has been reached. This is no doubt true. As I mentioned in another mail, this procedure does have the problem of not delivering proprtional results. A scenario. Suppose that, in the future, Debian comes to be divided fairly cleanly into three factions in terms of who should be elected in a particular multi-winner election. One of the factions has a 55 % support, the second has 30 % support and the third has the remaining 15 % support. All three field at least as many candidates as there are seats. Supporters of a faction place the candidates fielded by their faction above the candidates fielded by the other factions. Now, under the iterate single-winner-Schulze method, it seems to me the winners will all be candidates fielded by the majority faction, no candidates of the minority factions ending up elected. Now, for the present discussion, this is relevant for the initial election of the committee, and it may actually be relevant for reconfirmation as well (if we decide that the soc ctte should be proportional, then the suggested reconfirmation method is wrong). It may even be desirable, in some situations, to create a body that has no factions in itself (justifying winner takes all), but I doubt the proposed soc committee is one of them. -- Antti-Juhani Kaijanaho, Jyväskylä http://antti-juhani.kaijanaho.fi/newblog/ signature.asc Description: Digital signature
Re: soc-ctte discussion at DebConf7
Manoj Srivastava wrote: ...snip... I have seen no discussion on how the soc ctte is going to go about ensuring that such cultural differences are noticed, or taken into account in the resolution process; or that any thought has been taken to address cultural diversity in the dispute resolution process. I see no way to legislate that cultural differences are taken into account. About the only way I see of ensuring that these are considered is by selecting a committee that has a group with diverse backgrounds. Are we planning on taking into account things like cultural differences? Or is the decision going to be that the majority rule (or the dominant culture) be the governing one? I hope the committee will consider these differences before a decision is made. I would propose that open, frank, and honest communication between all the parties will bring such differences to light. An independent objective third party like the committee should be in a good position to recognize such cultural differences. Whether any of the warring parties will accept what the committee recognizes is an entirely different matter ;-) Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: soc-ctte discussion at DebConf7
Manoj Srivastava [EMAIL PROTECTED] wrote: I am not sure I agree that Debian as the melting pot is a viable idea. And I find the concept of cultural hegemony (in other words, Debian culture is dictated by the predominant subgroups, everyone else better fall in line) mildly distasteful. But if this is the will of the masses, I suppose I must give in. I don't know about the masses, but I feel similar to you; and someone (Andreas Tille or someone in reply to him?) has also expressed concern about minority viewpoints, which I think is approximately what you have expressed much better as cultural differences. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: soc-ctte discussion at DebConf7
Richard Hecker [EMAIL PROTECTED] wrote: Manoj Srivastava wrote: ...snip... I have seen no discussion on how the soc ctte is going to go about ensuring that such cultural differences are noticed, or taken into account in the resolution process; or that any thought has been taken to address cultural diversity in the dispute resolution process. I see no way to legislate that cultural differences are taken into account. About the only way I see of ensuring that these are considered is by selecting a committee that has a group with diverse backgrounds. Which should be taken into account when designing the election and vote evaluation method. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: soc-ctte discussion at DebConf7
Richard Hecker [EMAIL PROTECTED] wrote: Manoj Srivastava wrote: Are we planning on taking into account things like cultural differences? Or is the decision going to be that the majority rule (or the dominant culture) be the governing one? I hope the committee will consider these differences before a decision is made. [...] Hope for the best. Prepare for the worst. In light of Multi-winner elections, soc-ctte from Antti-Juhani Kaijanaho, I think it's clear that iterating the DPL election method does badly against the worst case. So I looked at recent thinking on multi-minority elections... governments. About ten years ago, the UK Government had a review commission under Roy Jenkins that surveyed several systems and made recommendations. You can download a 4Mb PDF of its report from http://www.makemyvotecount.org.uk/opus16/vol1.pdf Its recommendation was for alternative vote with a 20% open list corrective additional member system. Would soc-ctte candidate factions group themselves to enable an AMS to work? Looking more widely, some very divided communities seem to use Single Transferable Vote when trying to include all views. If candidates won't group (which I think they won't), then I think I'd prefer STV. Finally on this, a short note: I know soc-ctte isn't a bloody government, but I think it will sometimes have to choose between exclusive events, which is one thing which makes government so divisive, so it's a fair place to look for ideas. Manoj Srivastava [EMAIL PROTECTED] wrote: [...] I am not sure I agree that Debian as the melting pot is a viable idea. And I find the concept of cultural hegemony (in other words, Debian culture is dictated by the predominant subgroups, everyone else better fall in line) mildly distasteful. But if this is the will of the masses, I suppose I must give in. Please don't. Regards, -- MJ Ray - see/vidu http://mjr.towers.org.uk/email.html Experienced webmaster-developers for hire http://www.ttllp.co.uk/ Also: statistician, sysadmin, online shop builder, workers co-op. Writing on koha, debian, sat TV, Kewstoke http://mjr.towers.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multi-winner elections, soc-ctte (Was: Re: soc-ctte discussion at DebConf7)
On Sat, Jun 30, 2007 at 10:00:47AM +0300, Antti-Juhani Kaijanaho wrote: On Fri, Jun 29, 2007 at 02:43:24PM -0500, Manoj Srivastava wrote: It should be relatively straight forward for Devotee to find the winner, take the winner out of contention the next round, find the next winner (ignoring any pairwise contests dealing with any candidate no longer in the contest), and continue until the number of candidates desired has been reached. This is no doubt true. As I mentioned in another mail, this procedure does have the problem of not delivering proprtional results. A scenario. A simpler scenario. A bunch of candidates divide themselves into essentially two parties, people focussed on free software, and people focussed on our users. As it turns out, one group has 60% support within the project, the other group has 40% support within the project. There are six candidates, and three places to fill. Votes go along the lines of: 60% [ 1 ] A-1 [ 2 ] A-2 [ 3 ] A-3 [ 4 ] B-1 [ 5 ] B-2 [ 6 ] B-3 40% [ 4 ] A-1 [ 5 ] A-2 [ 6 ] A-3 [ 1 ] B-1 [ 2 ] B-2 [ 3 ] B-3 Condorcet gives the winner as A-1. Excluding A-1 gives you a Condorcet winner of A-2. Excluding A-1 and A-2 gives you a Condorcet winner of A-3. A more desirable outcome, IMO, would have given B-1 a seat in the above circumstances. Which is what proportionality is all about... Whether A is free software and B is our users or vice-versa is left as an exercise for the reader. ;) Other plausible scenarios might involve soc-ctte candidates promoting freedom of speech versus improving signal:noise. Cheers, aj signature.asc Description: Digital signature
Re: soc-ctte discussion at DebConf7
On Fri, 29 Jun 2007, Manoj Srivastava wrote: In other words, we share a common technical culture. This is not the case for social culture of the community; and this distinction would tend to make a difference, in my opinion. Well, we discussed it in private at DebConf (when I lost my live in an assassin attack ;-)). I wonder in how far you think different cultural aspects are regarded if there is no social committee at all. So we have the choice to do either nothing against social problems in Debian or just give a soc-ctte a chance to try - your comments about the cultural diversion might be a helpful guideline here - but in my opinion no argument against a soc-ctte. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: soc-ctte discussion at DebConf7
Andreas Tille [EMAIL PROTECTED] wrote: [...] So we have the choice to do either nothing against social problems in Debian or just give a soc-ctte a chance to try [...] That's a false dilemma. For example, I suggested letting email lists (suffering most badly ATM) promote their own admins in http://lists.debian.org/debian-project/2007/06/msg00258.html It's not soc-ctte or nothing! We could take smaller steps first! Amazed, -- MJ Ray - see/vidu http://mjr.towers.org.uk/email.html Experienced webmaster-developers for hire http://www.ttllp.co.uk/ Also: statistician, sysadmin, online shop builder, workers co-op. Writing on koha, debian, sat TV, Kewstoke http://mjr.towers.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: soc-ctte discussion at DebConf7
Hi, Firstly, wearing my secretary hat, I have no objections to running votes for the soc-ctte membership, if we do decide such votes are how things will be done. Now, taking the hat off, and speaking bare headed, I have a couple of comments to make. The first set of comments I have is related to efficacy, and, perhaps, the notion of fairness. There is a fundamental difference between a technical committee and a social committee: a technical issue is likely to be far less subjective, and while there are tradeoff aspects to technical problems, it is far easier to come up with reasons for the trade offs, and a rationale for selecting one option over the other, and do so in a relatively objective fashion. A social committee resolving disputes has no such luxury. In a sense, since a machine interprets the end results of technical problems (well, for the most part), we tend to speak in one language; but as Debian contributers come from varied and diverse backgrounds and cultures, the cultural differences have an impact on the disputes and also the perception of the resolution. Differences in culture make the difference between commonplace conversation and unacceptable insults; there are various anecdotes about ocidental and mist eastern differences in something as simple as inviting a guest to the dinner table (us americans would be seen as horribly rude). An anecdote I tell deals with a young developer on an Indian mailing list somewhat rudely contradicting me about the Etch release; the other members jumped on him not because he was incorrect, nor necessarily because of his rudeness; but because a lack of respect from a younger person to an older person was unacceptable. The age based distinction would make absolutely no sense for my American friends. I have seen no discussion on how the soc ctte is going to go about ensuring that such cultural differences are noticed, or taken into account in the resolution process; or that any thought has been taken to address cultural diversity in the dispute resolution process. Are we planning on taking into account things like cultural differences? Or is the decision going to be that the majority rule (or the dominant culture) be the governing one? The second set of comments I have are about accountability (and, yes, this applies to the tech ctte as well). Who are the tech and soc ctte members accountable to? Is there any recourse to the membership, apart from overturning individual decisions via a GR, to counteract a committee (social or technical) that has turned wayward and out of control? manoj -- The girl who remembers her first kiss now has a daughter who can't even remember her first husband. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: soc-ctte discussion at DebConf7
On Tue, 26 Jun 2007 23:16:50 +0200, Stefano Zacchiroli [EMAIL PROTECTED] said: Just nitpicking, but is our Condorcet method for running election suitable for voting when an (ordered) set of result is expected? Isn't it targeted at finding only one winner (if it exists)? Not a big problem though: I guess if it's not suitable we can find an alternative method, but I definitely don't want a ballot with all possible permutation of resulting soc-ctte :-) Something to be looked for before the election though, or maybe Manoj can enlighten all us out of the box. It should be relatively straight forward for Devotee to find the winner, take the winner out of contention the next round, find the next winner (ignoring any pairwise contests dealing with any candidate no longer in the contest), and continue until the number of candidates desired has been reached. manoj -- Moore's Constant: Everybody sets out to do something, and everybody does something, but no one does what he sets out to do. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: soc-ctte discussion at DebConf7
On Fri, Jun 29, 2007 at 02:37:46PM -0500, Manoj Srivastava wrote: The first set of comments I have is related to efficacy, and, perhaps, the notion of fairness. There is a fundamental difference between a technical committee and a social committee: a technical issue is likely to be far less subjective http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=162;bug=367709 http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=177;bug=367709 Ruling based on the technical details of a question is apparently no defense against accusations of subjectivity anyway. Nor are any of our existing poor methods for dealing with social problems any less subjective, so I don't think this is a reason not to proceed. and while there are tradeoff aspects to technical problems, it is far easier to come up with reasons for the trade offs, and a rationale for selecting one option over the other, and do so in a relatively objective fashion. The weighting of the trade-offs is always subjective. The technical committee works not because it's more *objective*, but because it's configured so that its particular subjectivity is biased in favor of institutional stability (= the status quo), which means developers are more likely to be accepting of such decisions because on some level the TC's bias shares an overall alignment with their own. I have seen no discussion on how the soc ctte is going to go about ensuring that such cultural differences are noticed, or taken into account in the resolution process; or that any thought has been taken to address cultural diversity in the dispute resolution process. I frankly think this is a red herring. The society that the social committee is purposed to serve is not Chinese, or American, or Middle-Eastern, or French, or Indian, or German, or Japanese; it's Debian as a society per se that must be served by this committee. Now each member of the project is going to bring his or her own cultural preconceptions to the table, to be sure[1], and the overall Debian culture is certainly going to reflect to some degree the mother culture of the predominant subgroups (whether that's predominance in terms of numbers, contributions, key positions held within the project, or volume of mailing list posts). But I think it's the responsibility of each individual developer to integrate themselves into the overall community, and that it should not be the role of the social committee to inject an artificial measure of cultural sensitivity beyond what the project as a whole is actually capable of sustaining. And OTOH, I think to some degree recognition of cultural differences falls out *naturally* from any social committee whose charter includes rapprochement instead of just judgement and sentencing. If rapprochement is your goal, all the cultural background that contributes to explaining *why* an individual views a situation the way they do is much less important than understanding *that* they understand the situation in that way. Are we planning on taking into account things like cultural differences? Or is the decision going to be that the majority rule (or the dominant culture) be the governing one? Do you take into account cultural differences every time you send a mail to a mailing list or reply to a bug report, or do you allow your cultural ideas to dominate by virtue of your position of authority (as a package maintainer or as a community elder)? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ [1] There have been a number of mailing list threads over the past year that have opened my own eyes to just how different American culture is from French and Belgian culture in some ways, in spite of these countries supposedly sharing a common overall Western heritage -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: soc-ctte discussion at DebConf7
On Fri, 29 Jun 2007 14:27:40 -0700, Steve Langasek [EMAIL PROTECTED] said: On Fri, Jun 29, 2007 at 02:37:46PM -0500, Manoj Srivastava wrote: The first set of comments I have is related to efficacy, and, perhaps, the notion of fairness. There is a fundamental difference between a technical committee and a social committee: a technical issue is likely to be far less subjective http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=162;bug=367709 http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=177;bug=367709 Ruling based on the technical details of a question is apparently no defense against accusations of subjectivity anyway. Nor are any of our existing poor methods for dealing with social problems any less subjective, so I don't think this is a reason not to proceed. Err, anyone can be accused of anything at anytime, apparently, on Debian lists; so that is not really the point. Also, why would you think anyone is talking about not proceeding? The point is disputes over technical matters are inherently different from disputes of social issues. If you don't see that, I suppose we have little basis for further discussion -- I am finding it hard to explain what seems like a self evident fact to me. and while there are tradeoff aspects to technical problems, it is far easier to come up with reasons for the trade offs, and a rationale for selecting one option over the other, and do so in a relatively objective fashion. The weighting of the trade-offs is always subjective. But the rationale of the tradeoffs can be objective, as can an explanation for why more weight is being placed on one side or the other. The technical committee works not because it's more *objective*, but because it's configured so that its particular subjectivity is biased in favor of institutional stability (= the status quo), which means developers are more likely to be accepting of such decisions because on some level the TC's bias shares an overall alignment with their own. In other words, we share a common technical culture. This is not the case for social culture of the community; and this distinction would tend to make a difference, in my opinion. I have seen no discussion on how the soc ctte is going to go about ensuring that such cultural differences are noticed, or taken into account in the resolution process; or that any thought has been taken to address cultural diversity in the dispute resolution process. I frankly think this is a red herring. The society that the social committee is purposed to serve is not Chinese, or American, or Middle-Eastern, or French, or Indian, or German, or Japanese; it's Debian as a society per se that must be served by this committee. The issue is not whether the soc-ctte server the culture of outer mongolia, or not; the issue is whether the committee recognizes the cause belli; failure to do so would make rapproachment more ... difficult. Now each member of the project is going to bring his or her own cultural preconceptions to the table, to be sure[1], and the overall Debian culture is certainly going to reflect to some degree the mother culture of the predominant subgroups (whether that's predominance in terms of numbers, contributions, key positions held within the project, or volume of mailing list posts). But I think it's the responsibility of each individual developer to integrate themselves into the overall community, and that it should not be the role of the social committee to inject an artificial measure of cultural sensitivity beyond what the project as a whole is actually capable of sustaining. I am not sure I agree that Debian as the melting pot is a viable idea. And I find the concept of cultural hegemony (in other words, Debian culture is dictated by the predominant subgroups, everyone else better fall in line) mildly distasteful. But if this is the will of the masses, I suppose I must give in. And OTOH, I think to some degree recognition of cultural differences falls out *naturally* from any social committee whose charter includes rapprochement instead of just judgement and sentencing. If rapprochement is your goal, all the cultural background that contributes to explaining *why* an individual views a situation the way they do is much less important than understanding *that* they understand the situation in that way. My point was that unless care is taken in ensuring the ctte diversity, the ctte might not even be aware that one of the disputants views a situation differently (and why they might not be open to explaining that); far less than knowing the reasons behind the views. Are we planning on taking into account things like cultural differences? Or is the decision going to be that the majority rule (or the dominant culture) be the governing one? Do you take into account cultural differences every time you send a
Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]
* Ian Jackson ([EMAIL PROTECTED]) [070627 23:31]: Raphael Hertzog writes (Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]): AFAIR, the consensus was that: - by default, every 2 years the project has to reapprove individually each member of the soc-ctte. This gives the project an opportunity to recall members who are judged as no more representative or whatever. Reapproving probably means having more ranking above NOTA than rankings below NOTA. Maybe we should make that ratio 66%. I remember 1 year rather than 2 but it doesn't make much difference. Actually, we had two different voting systems with different time ranges: Either normal voting with 2 years (though voting every year, but only on half of the people), or approval voting every year. Basically, voting every year is ok, but we want to avoid having too large changes happening to the people to keep the knowledgebase intact. (As with approval voting, that goal is reached different, so we can vote every year on everyone, and not only on half of the people.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]
On Thu, 28 Jun 2007, Josip Rodin wrote: While I certainly appreciate Andreas organizing the talk in the first place, because if he hadn't, it wouldn't have even gotten into the schedule early enough for people to generally notice it :) it does seem that we would have been better off having someone formally steer the discussion and take official notes (with obligatory interjections, saying all right, now everybody making casual comments shut up, do we agree on point X or do we not? :). You are perfectly right. I intended in the first place some kind of unmoderated brainstorming but I should have noticed that we just crossed the line to real decisions by far. Sorry, perhaps we should do some fork universe before such events to enable us to see how it would work better when doing different things. So sorry if I did not made something better out of it. I hope that the recording contains the main information - at least this was my hope when I concentrated more on the discussion than onto making much notes. The meeting agreed that a DPL delegation was the appropriate basis for the SC. This would allow the process to be refined as we get more experience and also helpfully provides a useful appointment mechanism. (I agreed only on the former part of that sentence, but not on the latter :) Well, I'd regard it useful because it might be the fastest way to get an appointment. If we do not really know which might be the best method I'd go for the faster and observe closely how it works. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]
On Tue, 26 Jun 2007, Josip Rodin wrote: On the other hand, a single social committee provides for a body which will be by and large neutral towards all lists (it will apply the same reasoning towards all). ... if the committee isn't too big. I don't expect early warnings to be approved by a majority of the ctte members before they are sent out. Otherwise this team will never do anything. On the other hand, since such notices are always cced to the ctte, I expect some internal discussions at the beginning to discuss what warrants a warning and what doesn't (and how to properly draft them). However for more important decisions (list ban, etc.), there must be an internal vote in order to provide some confidence that the decision was the right one. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]
On Tue, Jun 26, 2007 at 09:19:46AM +0200, Raphael Hertzog wrote: We have decided to have 2 GR at the same time. One deciding the creation of the soc-ctte and one deciding its membership. snip - by default, every 2 years the project has to reapprove individually each member of the soc-ctte. This gives the project an opportunity to recall members who are judged as no more representative or whatever. Reapproving probably means having more ranking above NOTA than rankings below NOTA. Maybe we should make that ratio 66%. Just nitpicking, but is our Condorcet method for running election suitable for voting when an (ordered) set of result is expected? Isn't it targeted at finding only one winner (if it exists)? Not a big problem though: I guess if it's not suitable we can find an alternative method, but I definitely don't want a ballot with all possible permutation of resulting soc-ctte :-) Something to be looked for before the election though, or maybe Manoj can enlighten all us out of the box. ( Sorry I can't look for the answer of the above by myself, but I'm writing offline ) -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]
On Tue, Jun 26, 2007 at 04:50:37PM -0700, Mike Bird wrote: On Tuesday 26 June 2007 15:33, Gaudenz Steinlin wrote: After a decision is made I think it's less problematic to make the discussion available to all DDs. But still there is the problem, that offending behaviour would be exposed to all DDs. The committee's deliberations should be solely based on objective facts. If the committee's deliberations cannot withstand the light of day, they are not a sufficiently robust basis for a _Debian_ decision. Cabals and secret deliberations are the antithesis of freedom. Judging form the part of my message you cited above, you probably misunderstood what I wanted to say. My reasoning in that part was not that the comitee should be able to keep the reasoning private because the comitee members fear something (or whatever other reason), but that the offender might wish to keep the fact private that an action was taken by the comitee against him. In case of only minor offences I think it might be reasonable to keep the name of the offender secret and to only publish an annonimized version to all DDs. This way the offender does not loose his face. Gaudenz -- Ever tried. Ever failed. No matter. Try again. Fail again. Fail better. ~ Samuel Beckett ~ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
list-admins and juries, was Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]
Josip Rodin [EMAIL PROTECTED] wrote: On Tue, Jun 26, 2007 at 10:48:51AM +0100, MJ Ray wrote: I feel we're really missing most sorely list-admin teams [...] The problem with that is that nobody is proposing any sort of a model by which these teams would be composed. Naive proposal for composing these teams: Each list will have up to five list-admins. Each list-admin may be admin of no more than three lists. A list-admin may be appointed or removed by filing a bug against lists.debian.org and getting 12 more supporters than objectors for the change from last months posters to that list. As part of their bug closure message, listmasters may decide to discount any irregular supporters or objectors (such as people posting mainly to contribute to such a bug). I hope that list-admins would have some way of updating the list info page and would have their requests prioritised by listmasters, but I leave the technical details to them. Another nice touch is that addition or removal of a list-admin is a bug, which is probably a good way to view it. In an ideal world, they shouldn't be needed to do anything, but I think we do need some now. Comments? I personally can't see such a thing going far, because that would create various rulesets for various lists, and require involvement of far too many people to be authoritative. Those rulesets already exist, whether documented or not. I also think that involving many people will help to make the lists popularly-managed - this is more about grassroots control more than authority. [...] Will its actions also be heavy, as the big stick mentioned in its powers suggests it could. The main point, which apparently eluded you :) was that it needs to be able to have a big stick simply so that it has tangible authority. For some people, the authority provided by being a regularly elected body might not be sufficient to make them respect it. So shall we top the big sticks with an axe, to show that authority in the classical way? (see dict fasces) I remember similar stupid arguments being used by governments throughout history, but I won't go further lest the thread dies. In short: owning the big stick is not a good way to rule. [...] Was the jury selection model discussed at all? I don't think it was. Can you explain a bit? It was in the end of the thread-starter: A third idea: instead of having delegates or a committee or whatever to decide amongst disputes, how about randomly selecting a jury from DDs and having their word (on who's right, on what punishment is plausible) be absolutely final, with no appeal, ever? http://lists.debian.org/debian-project/2007/05/msg00240.html I don't think the no appeal is realistic, but I believe there's a lot to commend that approach for these disputes. At least you get a random chance of having similar viewpoints in the jury. Regards, -- MJ Ray - see/vidu http://mjr.towers.org.uk/email.html Experienced webmaster-developers for hire http://www.ttllp.co.uk/ Also: statistician, sysadmin, online shop builder, workers co-op. Writing on koha, debian, sat TV, Kewstoke http://mjr.towers.org.uk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]
El martes, 26 de junio de 2007 a las 23:16:50 +0200, Stefano Zacchiroli escribía: Just nitpicking, but is our Condorcet method for running election suitable for voting when an (ordered) set of result is expected? Isn't it targeted at finding only one winner (if it exists)? Not a big It's targeted to finding the one winner, but it's easy to adapt to finding a list: get the winner, then remove it from the list of options and get the new winner, then remove it from the list of options and get the new winner, etc. -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Multiple-winner elections and Condorcet (Was: Re: soc-ctte discussion at DebConf7)
On Wed, Jun 27, 2007 at 01:27:00PM +0200, Jacobo Tarrio wrote: [ on the Debian Condorcet method ] It's targeted to finding the one winner, but it's easy to adapt to finding a list: get the winner, then remove it from the list of options and get the new winner, then remove it from the list of options and get the new winner, etc. The reason we use the Condorcet method (particularly, I believe, its Schulze variant) is that it satisfies all kinds of nice properties. The obvious adaptation you mention fails a property which I consider a very important property of multiple-winner election methods (namely, proportionality). However, there is a proposal from Markus Schulze for a multiple-winner election method that is claimed to satisfy proportionality and that contains the single-winner Schulze method as a special case. (See http://m-schulze.webhop.net/schulze2.pdf) -- Antti-Juhani Kaijanaho, Jyväskylä http://antti-juhani.kaijanaho.fi/newblog/ signature.asc Description: Digital signature
Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]
Josip Rodin writes (soc-ctte discussion at DebConf7 [was Re: Social committee proposal]): Ian said he'll send over his notes, but I'm impatient so I'll have a go :) Right, thanks :-). My recollection and notes broadly agree with you. I'll write from my notes a new posting because that's easier, and then follow up to your comments where they seem to have disagreed. That will make this message of mine rather long, I'm afraid. We discussed: - Rationale - Powers and jurisdiction - Appointment - Procedure - How to appeal or overrule the committee's decisions Rationale - There wasn't a huge amount of discussion about this; mostly people seemed to acquiesce to the way I put it, which is that we need some method for dealing with disruptive behaviour that lies between individuals asking for it to stop and expelling people. We discussed what kind of structure should take these decisions and we seemed to all agree that a group of several people was best - ie, a committee. Powers -- I tried to get people to refine (ie, disagree with) my `access control decisions' formulation for the scope of the committee's power. Sadly this was quite difficult. I mentioned that I wasn't sure about it myself and that we should probably limit the power to apply to access to _communications facilities_. That would deal with the cases of CVS repositories and team membership. Jurisdiction and appeal --- As Josip says, we basically agreed that in cases of disputed jurisdiction the DPL would decide whether a dispute was for the TC or the SC. Normally, hopefully, all the parties would agree which committee was right. There was some discussion of how to get a disputant to agree to the jurisdiction up-front, which I felt was essential. There would be no appeal from the SC to the TC or vice versa. Likewise there would be no appeal of a decision, once made, to the DPL. Any appeal from either committee's decision must be via GR. Procedure - We agreed that the committee members ought to be allowed (and indeed encouraged) to make informal private comments to people about their behaviour. Any actual binding decision would definitely be made public. I don't remember a clear consensus on whether discussions and non-binding recommendations should necessarily be public. Appointment and constitutional basis The meeting agreed that a DPL delegation was the appropriate basis for the SC. This would allow the process to be refined as we get more experience and also helpfully provides a useful appointment mechanism. Straight elections were not considered to be a good appointment strategy, at least for any subsequent years, because most of the work done by the committee is in private. IIRC we settled on individual approval voting on each member: each year the DDs would vote seperately for each SC member in a straight `keep or ditch' fashion. SC members voted off in this way would be replaced by appointments made by the DD. We also felt that to give the committee legitimacy it should be initially constituted by a DPL-proposed-GR. So, discussion of Josip's notes: * The communication of soc-ctte members with people about their behaviour which might eventually become a matter of committee deliberation should be kept reasonably private, to prevent unnecessary escalation However, we agreed that if an SC member communicates privately with someone on a matter covered by the SC's remit (eg, to give advice or praise or ask someone to stop doing something), then such messages may be published without the consent of the SC member. This allows an out-of-control SC member to be challenged more effectively. * The phrasing of the access control power should be subtle enough to avoid the pitfall of people complaining to the soc-ctte regarding political decisions such as who has commit access to a VCS repository, because there the distinction between 'political', 'technical' and 'social' can be blurry, which might cause problems, and nobody really had an answer for that I think I have come to the conclusion that limiting its binding decisions to access control to project-owned communication facilities will be sufficient. * The establishment and composition of the actual soc-ctte: * We seemed to agree that a leader's delegation would be a useful tool to bootstrap the soc-ctte and modify it later (even though it's unclear whether the constitutional barrier to leader messing with the delegates would apply), as opposed to the inclusion in the constitution which would delay the process and make it less modifiable later - a proposed compromise solution is that a general resolution vote should be held, one that would make a formal statement establishing soc-ctte, in order to give the idea full-blown credibility We agreed, I think, that the constitutional barrier
Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]
Raphael Hertzog writes (Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]): Basicaly, any communication concerning the proactive part shall be private. The person receiving the warning can publicize it by themselves if they so desire (but it's certainly not expected to be the general rule, it's just to avoid the criticism of lack of transparency). Right. We also agreed that the formulation was a bit broad. For instance, granting adm membership (ie DSA team rights) is also an ACL decision, but it's certainly not the resort of the social ctte. So we sort of decided that it should: - make ACL decisions concerning the Debian lists (the listmasters clearly indicated that they don't want to take those by themselves) This includes the possibility to decide ML bans for DD as well as for non-DD. - make decision concerning DD's behaviour everywhere where they are acting as member/representative of the project (including #debian* IRC channels). - make recommandation to any other party that defers a judgment to the social ctte (example: the OFTC admin defers a dispute on the soc-ctte over ownership of a channel #debian*) Since it's a delegated body, the DPL can grant additionals powers if needed. This is a good alternative to explicitly specifying the powers. We have decided to have 2 GR at the same time. One deciding the creation of the soc-ctte and one deciding its membership. Indeed so. AFAIR, the consensus was that: - by default, every 2 years the project has to reapprove individually each member of the soc-ctte. This gives the project an opportunity to recall members who are judged as no more representative or whatever. Reapproving probably means having more ranking above NOTA than rankings below NOTA. Maybe we should make that ratio 66%. I remember 1 year rather than 2 but it doesn't make much difference. I disagree about the voting system. We should use straight approval voting: each voter votes `yes' or `no' separately for each candidate. Candidates who get more `yes' than `no' get to stay. Others are dismissed. The DPL will then make up the numbers. Obviously the DPL is expected not to reappoint the dismissed members (even though that's technically possible). I don't think it's necessarily a problem that the DPL has in theory powers which the SC setup expects the leader not to use. After all any such outrage could be overruled by GR. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]
Josip Rodin writes (Re: soc-ctte discussion at DebConf7 [was Re: Social
committee proposal]):
One thing that I hadn't had the chance to mention (because other people were
simply being louder than me ;) was that the proactivity still needs to be
documented in an internal archive of soc-ctte, so that there is a clear
record of exactly what was done in the name of the committee and when.
I think that it might be useful for the SC members to send two kinds
of private mails:
* Ones which are fairly formal and which are CC'd to soc-ctte
(and hence visible in the private archive).
* Informal messages which are wholly private and which the other SC
members are not necessarily aware of.
The important point here is to allow people who are temporarily
misbehaving to back down without losing face. The fewer people see
anything that could be thought of as a reprimand, the easier that is.
Because those latter informal messages will probably happen anyway I
think it's important to make the rule that the SC members are taken to
have waived their normal right of confidentiality for such a message
(even if it doesn't explicitly contain any mention of the SC).
We also agreed that the formulation was a bit broad. For instance,
granting adm membership (ie DSA team rights) is also an ACL decision,
but it's certainly not the resort of the social ctte.
Right, but I don't think that someone would actually argue that.
That's simply not a social issue so by default it's not a soc-ctte issue.
These kinds of things have been subject to some argument in the past.
We should make it clear that this isn't covered.
- make decision concerning DD's behaviour everywhere where they are acting
as member/representative of the project (including #debian* IRC channels).
Also non-DDs in such venues, Sam mentioned something like that.
Sponsored maintainers too, I guess.
Yes.
Well, I think that that's inconsistent. The DPL shouldn't be able to
randomly modify ('undelegate') membership in the soc-ctte once they were
confirmed by the developer body using the normal voting procedure.
I think in fact it's probably fine for the DPL to be able to do that.
In practice this isn't going to come up unless the DPL is very sure of
their ground.
I think this is the price we pay for 1. the flexibility of having the
DPL be able to easily change the setup if it turns out not to be
working so well and 2. a clear backstop limit on the SC's powers
(which are necessarily derived from the DPL's).
We have decided to have 2 GR at the same time. One deciding the creation
of the soc-ctte and one deciding its membership.
Yes, but it wasn't clear who would compose the ballot for the membership.
The DPL will 1. invite candidates; 2. filter them; 3. publish the
draft list (inviting rejected candidates if any to get K sponsors).
AFAIR, the consensus was that:
- whenever a soc-ctte member steps down (or is recalled due to the
reapproval vote), the DPL appoints a new member
(unless he decided to vary the size of the team)
I didn't see this as a consensus decision, because there was a lot of murmur
in the room at the time :) and I believe I tried to object, but it was
pretty late anyway.
:-).
In general I don't see the rationale for the leader to be naming people to
the social committee which is already elected separately.
No, the ideal isn't that we elect people to the SC. The voting is not
a way to select the committee from a long list of candidates. It's
there so that the developers can get rid of a loose cannon without
having to find K sponsors for a recall GR.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]
On Wed, Jun 27, 2007 at 10:03:56PM +0100, Ian Jackson wrote: Rationale - There wasn't a huge amount of discussion about this; mostly people seemed to acquiesce to the way I put it, which is that we need some method for dealing with disruptive behaviour that lies between individuals asking for it to stop and expelling people. Yet I wouldn't go so far to say that this was the only rationale why people attended and supported the idea. It should be mentioned that it was early in the morning, that people were still coming in through the initial part of the debate, and that many people have a problem with just taking over the podium in front of a group of people and expressing a general introductory opinion. (Unlike you and me, perhaps ;) While I certainly appreciate Andreas organizing the talk in the first place, because if he hadn't, it wouldn't have even gotten into the schedule early enough for people to generally notice it :) it does seem that we would have been better off having someone formally steer the discussion and take official notes (with obligatory interjections, saying all right, now everybody making casual comments shut up, do we agree on point X or do we not? :). But it's not a big problem, we are a herd of cats after all :) I mentioned that I wasn't sure about it myself and that we should probably limit the power to apply to access to _communications facilities_. That would deal with the cases of CVS repositories and team membership. I think that this was mostly covered by my latest proposal, because I phrased it like this: Intervene in communication processes in matters of common interest. The Social Committee may issue a formal request that a person refrain from certain acts and communications. [...] (Did you read that diff? :) Now it shouldn't be a diff any more, I better go rephrase and repost it as a statement.) The meeting agreed that a DPL delegation was the appropriate basis for the SC. This would allow the process to be refined as we get more experience and also helpfully provides a useful appointment mechanism. (I agreed only on the former part of that sentence, but not on the latter :) Straight elections were not considered to be a good appointment strategy, at least for any subsequent years, because most of the work done by the committee is in private. This is also something that I didn't get a chance to respond to as well as I intended, so please excuse the following rant :) While the analysis of the tenure at the committee is certainly a useful criterion on which the voters would decide whether a member should be kept or removed, I don't think that it is the most important, because of the nature of the committee - we basically want this body to elaborate and establish certain social consensuses (consensa? sp?), and then when necessary enforce it against people who are so out of line that they piss off most everyone else. For that, most of the time, you just need a few level-headed people with a sufficient supply of common sense. They don't need a particular procedural skill - it's sufficient if they are just guided by others. They don't need to demonstrate that they were level-headed and common-sensical (heh) just on the committee - I think that they should continuously demonstrate these qualities in social interactions *in general*. I don't want us to end up with a couple of members appointed and elected because they're otherwise somehow popular (usually because they have l33t technical skills :) which are cool, but mainly irrelevant here), and then at re-election time they feel a need to demonstrate their actions on the soc-ctte, and then the problem of private interactions comes up. That's not necessary. The voters will generally simply observe whether these people continued to act sensibly on the committee, and sensibly in general, and they will appreciate this by continuing to affirm them in the committee. Debian is a pretty cooperative bunch (I did manage to mention that particular point, but wasn't able to explain all what I meant by that :) and for any soc-ctte member it will not take much effort to convince people not to randomly replace them. (Yet, the people should continue to have even that option, to randomly replace people, because eventually they might get tired from seeing all the same faces on the committee all the time :) and that's perfectly all right, actually, because I do hope that we have a long line of other level-headed common-sensical people ready to serve.) * The communication of soc-ctte members with people about their behaviour which might eventually become a matter of committee deliberation should be kept reasonably private, to prevent unnecessary escalation However, we agreed that if an SC member communicates privately with someone on a matter covered by the SC's remit (eg, to give advice or praise or ask someone to stop doing something), then such messages may be
Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]
On Thu, Jun 28, 2007 at 07:32:15AM +0200, Josip Rodin wrote: Straight elections were not considered to be a good appointment strategy, at least for any subsequent years, because most of the work done by the committee is in private. This is also something that I didn't get a chance to respond to as well as I intended, so please excuse the following rant :) While the analysis of the tenure at the committee is certainly a useful criterion on which the voters would decide whether a member should be kept or removed, I don't think that it is the most important, because of the nature of the committee - we basically want this body to elaborate and establish certain social consensuses (consensa? sp?), and then when necessary enforce it against people who are so out of line that they piss off most everyone else. For that, most of the time, you just need a few level-headed people with a sufficient supply of common sense. They don't need a particular procedural skill - it's sufficient if they are just guided by others. They don't need to demonstrate that they were level-headed and common-sensical (heh) just on the committee - I think that they should continuously demonstrate these qualities in social interactions *in general*. I don't want us to end up with a couple of members appointed and elected because they're otherwise somehow popular (usually because they have l33t technical skills :) which are cool, but mainly irrelevant here), and then at re-election time they feel a need to demonstrate their actions on the soc-ctte, and then the problem of private interactions comes up. That's not necessary. The voters will generally simply observe whether these people continued to act sensibly on the committee, and sensibly in general, and they will appreciate this by continuing to affirm them in the committee. Debian is a pretty cooperative bunch (I did manage to mention that particular point, but wasn't able to explain all what I meant by that :) and for any soc-ctte member it will not take much effort to convince people not to randomly replace them. (Yet, the people should continue to have even that option, to randomly replace people, because eventually they might get tired from seeing all the same faces on the committee all the time :) and that's perfectly all right, actually, because I do hope that we have a long line of other level-headed common-sensical people ready to serve.) And, obviously, here I refer primarily to the *committee* function of soc-ctte. These remarks don't all apply to the 'social team' function -- those people need to have more procedural skills and they have to be judged on their ability to do the concrete work of the team. But I think that soc-ctte should primarily perform the committee function, and then the existence of that will facilitate the team-like action, whether by those same people or by other people, because they will have a solid backing - a place to refer to and to appeal to when in doubt, so it will be easier to do the work. This is similar to one of the ideas discussed all some of governance bofs at dc7... when people have a mission statement or a manifesto, or in this case more generically: a documented commonness in ideas and procedures, it becomes easier for all of them act to resolve certain conflicts. -- 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 discussion at DebConf7 [was Re: Social committee proposal]
On Wed, Jun 27, 2007 at 10:22:04PM +0100, Ian Jackson wrote:
One thing that I hadn't had the chance to mention (because other people were
simply being louder than me ;) was that the proactivity still needs to be
documented in an internal archive of soc-ctte, so that there is a clear
record of exactly what was done in the name of the committee and when.
I think that it might be useful for the SC members to send two kinds
of private mails:
* Ones which are fairly formal and which are CC'd to soc-ctte
(and hence visible in the private archive).
* Informal messages which are wholly private and which the other SC
members are not necessarily aware of.
The important point here is to allow people who are temporarily
misbehaving to back down without losing face. The fewer people see
anything that could be thought of as a reprimand, the easier that is.
Because those latter informal messages will probably happen anyway I
think it's important to make the rule that the SC members are taken to
have waived their normal right of confidentiality for such a message
(even if it doesn't explicitly contain any mention of the SC).
In the second case, I think it's best that they still Cc: a second private
alias, one kept in a directory that is readable only to soc-ctte members.
That will keep it out of the general view and the view of thousands of
developers, but there will still be a clear record of it.
Well, I think that that's inconsistent. The DPL shouldn't be able to
randomly modify ('undelegate') membership in the soc-ctte once they were
confirmed by the developer body using the normal voting procedure.
I think in fact it's probably fine for the DPL to be able to do that.
In practice this isn't going to come up unless the DPL is very sure of
their ground.
I think this is the price we pay for 1. the flexibility of having the
DPL be able to easily change the setup if it turns out not to be
working so well
I'm not sure why this flexibility is necessary. Granted, it's a new body
and we don't know if it will implode and take down the universe, but
I really believe that we can set it up sufficiently right from the start
that it doesn't require a 'nuclear button'.
and 2. a clear backstop limit on the SC's powers
(which are necessarily derived from the DPL's).
Once the GR approves the committee, the powers are derived from the
developers in general, not just the leader. I argued this before - just
because the leader is theoretically in charge of this stuff right now
under the constitution, that doesn't make it his powers, because they're
not used (for whatever reason).
In general I don't see the rationale for the leader to be naming people
to the social committee which is already elected separately.
No, the ideal isn't that we elect people to the SC. The voting is not
a way to select the committee from a long list of candidates.
Erm, excuse me, but my original proposals from months ago were exactly that,
and the people who commented then seemed to like it (at least sufficiently
enough for none of them to actually voice a negative opinion on the whole
concept of voting them!).
Please refer to the earlier threads on this mailing list:
http://lists.debian.org/debian-project/2007/01/msg00063.html
http://lists.debian.org/debian-project/2007/02/msg00055.html
--
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 discussion at DebConf7 [was Re: Social committee proposal]
On Tue, 26 Jun 2007, Josip Rodin wrote: Ian said he'll send over his notes, but I'm impatient so I'll have a go :) Thanks for your impatience. :) The issues that were touched included: I found quite similar things in my private log - hoping to review the recording later to sort out missing ideas. I'll try to comment only on these points which might have taken not completely into account because of the time limit. * Someone proposed that the leader makes the initial list of members which would then be voted upon, not sure; I would maintain my position that people should be nominating themselves, rather than the leader naming them - I don't believe we clarified this point I don't know who did this proposal but letting the leader pick the soc-ctte people out of a number of people that explicitely volunteered to work in the soc-ctte (it makes no sense to pick people that do not volunteer to do some work) might be a resonable alternative. BTW, we did not discuss whether certain positions should exclude that a person is a member of the soc-ctte at the same time. For instance I'm unsure whether the leader should be a member at the same time which might perfectly happen under some circumstances if we decide that soc-ctte stays for two years stable and one of its members is successfully running for DPL. The opposition to the idea of not having any vetting of candidates was that there would be no accountability, no way to remove people who are perceived to be bad, or inactive. Proposal to address this was to have yearly approval voting of soc-ctte members, whereby the developers would be able to tick off a particular member and remove them that way. For these case I'd alternatively suggest kind of a soc-ctte internal voting mechanism to sort out those who shouldn't be a member for whatever reason quickly. It wasn't particularly clear what would be done after that (mostly by time constraints during the discussion...); how much non-approval would the members have to get in order to get removed; whether the removed members would have to be replaced, when and how would the replacement be done (appointment by leader? and then voting?). It was also proposed that only one half of the committee members go up for this kind of an approval vote each year. The reason was that we need some kind of stability. IMHO we do not have such a high frequency of soc-ctte business cases (furtunately) that members have a chance to gather some experience in this business. Thanks for your summary Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]
Hi, (you could have started a new thread :-)) On Tue, 26 Jun 2007, Josip Rodin wrote: * The initial social committee will have to combine two aspects - one is the need to have a body that would judge on disputes (this would be the committee as such), and the other is the need to have people who can communicate with some authority in order to resolve social matters (this would be a 'social team' or something) Those 2 aspects were: 1/ taking decisions on request of DD who are experiencing/witnessing a social problem 2/ being proactive on social behaviour (inform early when people misbehave on lists, so that they have a chance to correct in order to avoid resorting to more dramatic decisions later) * The communication of soc-ctte members with people about their behaviour which might eventually become a matter of committee deliberation should be kept reasonably private, to prevent unnecessary escalation Basicaly, any communication concerning the proactive part shall be private. The person receiving the warning can publicize it by themselves if they so desire (but it's certainly not expected to be the general rule, it's just to avoid the criticism of lack of transparency). The biggest decisions need to be publicly documented however. I don't think we've clearly drawn the line here. I'm also unsure if it's important to have a clear line here. We can just let the ctte draw the line where it's appropriate given that any communication concerning the ctte should ideally be archived on master.d.o just like other aliases are archived there ([EMAIL PROTECTED], [EMAIL PROTECTED], etc.) and that DD should be able to consult them. * The extent of soc-ctte powers: * We seemed to agree that soc-ctte should have the ability to make access control decisions in general, as described by Ian, so that while it would be a soft-speaking body, it could also have a big stick to carry while doing so :) We also agreed that the formulation was a bit broad. For instance, granting adm membership (ie DSA team rights) is also an ACL decision, but it's certainly not the resort of the social ctte. So we sort of decided that it should: - make ACL decisions concerning the Debian lists (the listmasters clearly indicated that they don't want to take those by themselves) This includes the possibility to decide ML bans for DD as well as for non-DD. - make decision concerning DD's behaviour everywhere where they are acting as member/representative of the project (including #debian* IRC channels). - make recommandation to any other party that defers a judgment to the social ctte (example: the OFTC admin defers a dispute on the soc-ctte over ownership of a channel #debian*) Since it's a delegated body, the DPL can grant additionals powers if needed. * The phrasing of the access control power should be subtle enough to avoid the pitfall of people complaining to the soc-ctte regarding political decisions such as who has commit access to a VCS repository, because there the distinction between 'political', 'technical' and 'social' can be blurry, which might cause problems, and nobody really had an answer for that The answer was the above IIRC. * The establishment and composition of the actual soc-ctte: * We seemed to agree that a leader's delegation would be a useful tool to bootstrap the soc-ctte and modify it later (even though it's unclear whether the constitutional barrier to leader messing with the delegates would apply), as opposed to the inclusion in the constitution which would delay the process and make it less modifiable later - a proposed compromise solution is that a general resolution vote should be held, one that would make a formal statement establishing soc-ctte, in order to give the idea full-blown credibility Which constitutionnal barrier ? The DPL can modify the team but can't overrule decisions of the team. * Someone proposed that the leader makes the initial list of members which would then be voted upon, not sure; I would maintain my position that people should be nominating themselves, rather than the leader naming them - I don't believe we clarified this point We have decided to have 2 GR at the same time. One deciding the creation of the soc-ctte and one deciding its membership. * The consensus on later changes to the committee was that it should not be done often in general, though we did disagree somewhat regarding the method of accomplishing that goal. I had previously proposed that normal elections be held every two years; Ian had previously proposed that the initial soc-ctte varies its own size and membership. AFAIR, the consensus was that: - whenever a soc-ctte member steps down (or is recalled due to the reapproval vote), the DPL appoints a new member (unless he decided to vary the size of the team) - by default, every 2 years
Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]
On Tue, Jun 26, 2007 at 09:15:25AM +0200, Andreas Tille wrote: * Someone proposed that the leader makes the initial list of members which would then be voted upon, not sure; I would maintain my position that people should be nominating themselves, rather than the leader naming them - I don't believe we clarified this point I don't know who did this proposal but letting the leader pick the soc-ctte people out of a number of people that explicitely volunteered to work in the soc-ctte (it makes no sense to pick people that do not volunteer to do some work) might be a resonable alternative. I have an issue with the leader deciding on the composition of the committee, in general. I think it could easily create the impression that they are his cronies, and we have to avoid that. I don't think that all other methods involving nominations and voting are such an unbearable overhead. BTW, we did not discuss whether certain positions should exclude that a person is a member of the soc-ctte at the same time. For instance I'm unsure whether the leader should be a member at the same time which might perfectly happen under some circumstances if we decide that soc-ctte stays for two years stable and one of its members is successfully running for DPL. I think that there's plenty of people in Debian for us to have different people in different positions at all times :) 7/1000 or 15/1000 is tiny. The opposition to the idea of not having any vetting of candidates was that there would be no accountability, no way to remove people who are perceived to be bad, or inactive. Proposal to address this was to have yearly approval voting of soc-ctte members, whereby the developers would be able to tick off a particular member and remove them that way. For these case I'd alternatively suggest kind of a soc-ctte internal voting mechanism to sort out those who shouldn't be a member for whatever reason quickly. Obviously, yes. But even then, the people outside might not see things the same way as the other members of the committee, and they have to have a method of voicing this opinion other than a rowdy flamewar on the mailing list or a GR explicitly condemning some member. That's just ugly. It wasn't particularly clear what would be done after that (mostly by time constraints during the discussion...); how much non-approval would the members have to get in order to get removed; whether the removed members would have to be replaced, when and how would the replacement be done (appointment by leader? and then voting?). It was also proposed that only one half of the committee members go up for this kind of an approval vote each year. The reason was that we need some kind of stability. IMHO we do not have such a high frequency of soc-ctte business cases (furtunately) that members have a chance to gather some experience in this business. Oh, and I should mention that people seemed to be a bit unaware of the fact that I had two years set for elections, rather than one, which is another method to have more stability. Especially if combined with that half-half rule Andreas mentioned. (In general, I got the distinct impression that many people couldn't be bothered to read long threads followed by diffs to the constitution. Can't blame them, really :) -- 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 discussion at DebConf7 [was Re: Social committee proposal]
On Tue, 26 Jun 2007, Josip Rodin wrote: I have an issue with the leader deciding on the composition of the committee, in general. I think it could easily create the impression that they are his cronies, and we have to avoid that. You are right here - I just wanted to enhance the suggestion about a leader picked soc-ctte where I share your concern up to some point - even if I'm not perfectly decided whether it might be just practical because I doubt that there will be enough cronies in the group of volunteers. I don't think that all other methods involving nominations and voting are such an unbearable overhead. Running several platforms and doing the usual amount of discussion on debian-vote might be some extra burden for those people who are interested. It might finally lead to a soc-ctte that is nearly the same as a leader picked one. The advantage might be the prove of legitimation which is definitely a plus but it draws time from several people. I think before we decide about whether we should elect or not we might beforehand verify whether we have really a large number of volunteers to elect from or if the number of volunteers might fit the (not yet decided number of commity members). I think that there's plenty of people in Debian for us to have different people in different positions at all times :) 7/1000 or 15/1000 is tiny. Sure, there is hopefully no problem to find a replacement. My point was that we should explicitely name those positions who should not be a member of the soc-ctte. On the other hand - sometimes iot is hard to get a certain number of people who are able and willing to do real work. Ask for instance the DebConf orga team whether they are flooded by volunteers to help. :) Obviously, yes. But even then, the people outside might not see things the same way as the other members of the committee, and they have to have a method of voicing this opinion other than a rowdy flamewar on the mailing list or a GR explicitly condemning some member. That's just ugly. Yes. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]
Josip Rodin [EMAIL PROTECTED] wrote: [...] I was happy to note that there wasn't really any discussion as to whether there should be such a thing - the implicit consensus was that we do need something, it's just that we need to figure out exactly what and how. Something is needed, but I'm surprised that there's no dissent with the idea of the high-level soc-ctte being the next body created. I feel we're really missing most sorely list-admin teams who will take care of the social fabric of one list each and are empowered to make limited short-term changes to preserve it, including updating the list info pages and small posting bans. We should prioritise those sorts of bottom-up change over a top-down soc-ctte. Existing high-level posts with a social aspect, such as listmasters and DAM both, seem reluctant to wield their power, which is understandable because they cannot follow every interaction in detail. When they do act, it seems to be somewhat heavy, because things reach that level of severity in the necessary delays. soc-ctte will also have the problem of being unfamiliar with the situation - how is it going to solve many problems faster? Will its actions also be heavy, as the big stick mentioned in its powers suggests it could. [...] * The communication of soc-ctte members with people about their behaviour which might eventually become a matter of committee deliberation should be kept reasonably private, to prevent unnecessary escalation What is reasonably private? Please avoid creating a Star Chamber. Also, how will we know which soc-ctte members are naughty or nice, or whether we should remove members or terminate the ctte? [...] * The establishment and composition of the actual soc-ctte: [...] delegation [...] voted upon [...] Was the jury selection model discussed at all? If it's all voting-derived, how can we assure there will be any debian-minority views represented on soc-ctte at any time? Disappointed, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]
On Tue, 26 Jun 2007, MJ Ray wrote: If it's all voting-derived, how can we assure there will be any debian-minority views represented on soc-ctte at any time? What exact minority do you have in mind? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: soc-ctte discussion at DebConf7
MJ Ray [EMAIL PROTECTED] writes: I feel we're really missing most sorely list-admin teams who will take care of the social fabric of one list each and are empowered to make limited short-term changes to preserve it, including updating the list info pages and small posting bans. We should prioritise those sorts of bottom-up change over a top-down soc-ctte. I agree. Most of the problems with bad social interaction can be solved by quick and non-intrusive private intervention from an authoritative party. Small list-admin teams would have the following powers at their disposal: 1. Contact the poster in private and tell him (or her, hate this English gender specific stuff) why his post was inappropriate and ask him to be more careful in the future. 2. If this doesn't work, warn the poster (again in private) that persisting in inappropriate behaviour will result in further action. 3. If there's still a problem, warn the poster in public. 4. If that didn't help, apply a temporary ban. 5. If there's still a problem, apply a permanent ban with notification to the listmasters and the DAM. In myy experience most problems would be solved in step one, provided the list-admins are socially adept. Of course, this only takes care of the mailing lists. It doesn't address cases like Sven or Ted, where it probably would have helped to have a permanent ombudsman team. -- * Sufficiently advanced magic is indistinguishable from technology (T.P) * * PGP public key available @ http://www.iki.fi/killer * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: soc-ctte discussion at DebConf7
On Tue, Jun 26, 2007 at 01:02:53PM +0300, Kalle Kivimaa wrote: MJ Ray [EMAIL PROTECTED] writes: I feel we're really missing most sorely list-admin teams who will take care of the social fabric of one list each and are empowered to make limited short-term changes to preserve it, including updating the list info pages and small posting bans. We should prioritise those sorts of bottom-up change over a top-down soc-ctte. I agree. Most of the problems with bad social interaction can be solved by quick and non-intrusive private intervention from an authoritative party. Small list-admin teams would have the following What is the difference between 'a list admin' and 'a small list admin team' in this situation? Also, why wouldn't (it be the duty of a DD/it be in the interest of a DD) to make such notification to an offending individual in private and to CC another officlal (list admin, DPL, soc-ctte leader,etc.) so that the official can be alerted and if necessary make the suspension or other appropriate action? -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal |mysite.verizon.net/kevin.mark/| | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keyserver: subkeys.pgp.net | my NPO: cfsg.org | |join the new debian-community.org to help Debian! | |___ Unless I ask to be CCd, assume I am subscribed ___| pgp0YLEGECh5U.pgp Description: PGP signature
Re: soc-ctte discussion at DebConf7
Kevin Mark [EMAIL PROTECTED] writes: What is the difference between 'a list admin' and 'a small list admin team' in this situation? Nothing, really, I just believe in teams in volunteer work, because then it's more likely that somebody in the team has the time and the energy to do what's needed. Also, why wouldn't (it be the duty of a DD/it be in the interest of a DD) to make such notification to an offending individual in private and to CC another officlal (list admin, DPL, soc-ctte leader,etc.) so that the official can be alerted and if necessary make the suspension or other appropriate action? Most people have an innate respect for the authority. If a listmaster mails me saying that my posts to -project are inappropriate because of X, I'm more likely to believe him than a random developer saying the same thing. I'm not a social scientist, though, so I cannot say if my generalization is valid. And, having DD's do the step one would just mean that the burden for making decisions falls again on the listmasters, who have said that they much rather not have that burden (and I agree, they've signed up for the technical administration, not social). Also, in that case I agree with MJ's point that it's better if the decisions are made by somebody who is familiar with the problem, not by somebody who has to first study it. -- * Sufficiently advanced magic is indistinguishable from technology (T.P) * * PGP public key available @ http://www.iki.fi/killer * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]
Andreas Tille [EMAIL PROTECTED] wrote: On Tue, 26 Jun 2007, MJ Ray wrote: If it's all voting-derived, how can we assure there will be any debian-minority views represented on soc-ctte at any time? What exact minority do you have in mind? No particular one, but including: racial or ethnic origin, religion or belief, disability, age, sexual alignment and orientation [list from EC Employment and Social Affairs]. The voting-derived soc-ctte could meet the definition of indirect discrimination by representing only our majorities - where an apparently neutral provision is liable to disadvantage a group of persons. I guess whether that matters depends whether you think it matters if the debian project discriminates on the above grounds. Hope that explains, -- MJR, a White Anglo-Saxon ex-Protestant, so not so worried for himself. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]
On Tue, Jun 26, 2007 at 09:19:46AM +0200, Raphael Hertzog wrote:
* The communication of soc-ctte members with people about their
behaviour which might eventually become a matter of committee
deliberation should be kept reasonably private, to prevent
unnecessary escalation
Basicaly, any communication concerning the proactive part shall be
private. The person receiving the warning can publicize it by themselves
if they so desire (but it's certainly not expected to be the general rule,
it's just to avoid the criticism of lack of transparency).
One thing that I hadn't had the chance to mention (because other people were
simply being louder than me ;) was that the proactivity still needs to be
documented in an internal archive of soc-ctte, so that there is a clear
record of exactly what was done in the name of the committee and when.
That is - whenever someone takes such a private action, they don't Cc: the
public mailing list, but they do Cc: the private archiving alias which
quietly records the event.
This archive would obviously be useful for the simple purpose of
backtracking what went on in case someone complains; but at the same time
it would be a bare-bone teaching tool for new members of soc-ctte.
The biggest decisions need to be publicly documented however. I don't
think we've clearly drawn the line here. I'm also unsure if it's important
to have a clear line here. We can just let the ctte draw the line where
it's appropriate given that any communication concerning the ctte should
ideally be archived on master.d.o just like other aliases are archived
there ([EMAIL PROTECTED], [EMAIL PROTECTED], etc.) and that DD should be able
to
consult them.
I was going to suggest DDs being able to read it, exactly like that,
but I did get a vibe from Bdale and others that even that would be
too much exposure.
I'm not sure, someone should elaborate if they disagree.
* We seemed to agree that soc-ctte should have the ability to make access
control decisions in general, as described by Ian, so that while it
would be a soft-speaking body, it could also have a big stick to carry
while doing so :)
We also agreed that the formulation was a bit broad. For instance,
granting adm membership (ie DSA team rights) is also an ACL decision,
but it's certainly not the resort of the social ctte.
Right, but I don't think that someone would actually argue that.
That's simply not a social issue so by default it's not a soc-ctte issue.
So we sort of decided that it should:
- make ACL decisions concerning the Debian lists (the listmasters clearly
indicated that they don't want to take those by themselves)
This includes the possibility to decide ML bans for DD as well as
for non-DD.
One thing we didn't mention here was any documented limits to these
decisions. I guess everyone implied that this would be left to the
discretion of soc-ctte, hoping that they wouldn't do anything drastic.
- make decision concerning DD's behaviour everywhere where they are acting
as member/representative of the project (including #debian* IRC channels).
Also non-DDs in such venues, Sam mentioned something like that.
Sponsored maintainers too, I guess.
* The establishment and composition of the actual soc-ctte:
* We seemed to agree that a leader's delegation would be a useful tool to
bootstrap the soc-ctte and modify it later (even though it's unclear
whether the constitutional barrier to leader messing with the delegates
would apply), as opposed to the inclusion in the constitution which
would delay the process and make it less modifiable later - a proposed
compromise solution is that a general resolution vote should be held,
one that would make a formal statement establishing soc-ctte, in order
to give the idea full-blown credibility
Which constitutionnal barrier ? The DPL can modify the team but can't
overrule decisions of the team.
Well, I think that that's inconsistent. The DPL shouldn't be able to
randomly modify ('undelegate') membership in the soc-ctte once they were
confirmed by the developer body using the normal voting procedure.
An analogous voting procedure should be used for such a thing. It doesn't
make much sense to me for one electee(sp?) to be able to randomly screw
around with other electees :)
* Someone proposed that the leader makes the initial list of members which
would then be voted upon, not sure; I would maintain my position that
people should be nominating themselves, rather than the leader naming
them - I don't believe we clarified this point
We have decided to have 2 GR at the same time. One deciding the creation
of the soc-ctte and one deciding its membership.
Yes, but it wasn't clear who would compose the ballot for the membership.
AFAIR, the consensus was that:
- whenever a soc-ctte member steps down (or is recalled due to the
reapproval vote), the DPL
Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]
On Tue, Jun 26, 2007 at 05:19:27PM +0200, Josip Rodin wrote: On Tue, Jun 26, 2007 at 09:19:46AM +0200, Raphael Hertzog wrote: * The communication of soc-ctte members with people about their behaviour which might eventually become a matter of committee deliberation should be kept reasonably private, to prevent unnecessary escalation Basicaly, any communication concerning the proactive part shall be private. The person receiving the warning can publicize it by themselves if they so desire (but it's certainly not expected to be the general rule, it's just to avoid the criticism of lack of transparency). One thing that I hadn't had the chance to mention (because other people were simply being louder than me ;) was that the proactivity still needs to be documented in an internal archive of soc-ctte, so that there is a clear record of exactly what was done in the name of the committee and when. That is - whenever someone takes such a private action, they don't Cc: the public mailing list, but they do Cc: the private archiving alias which quietly records the event. Yup. I made a point of mentioning this private archive at the meeting, but we were quite busy and maybe not everybody heard/remembered it. This archive would obviously be useful for the simple purpose of backtracking what went on in case someone complains; but at the same time it would be a bare-bone teaching tool for new members of soc-ctte. Yes, absolutely. snip So we sort of decided that it should: - make ACL decisions concerning the Debian lists (the listmasters clearly indicated that they don't want to take those by themselves) This includes the possibility to decide ML bans for DD as well as for non-DD. One thing we didn't mention here was any documented limits to these decisions. I guess everyone implied that this would be left to the discretion of soc-ctte, hoping that they wouldn't do anything drastic. Yes, that was my understanding. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] We don't need no education. We don't need no thought control. signature.asc Description: Digital signature
Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]
On Tue, Jun 26, 2007 at 10:44:28AM +0200, Andreas Tille wrote: even if I'm not perfectly decided whether it might be just practical because I doubt that there will be enough cronies in the group of volunteers. Like with the cabal - it's not a matter of if they will be there, but a matter of having a general impression formed that they are there. We don't need any more of that and we should steer clear of such a thing. (See also another rationale in my previous message in reply to Raphael.) I don't think that all other methods involving nominations and voting are such an unbearable overhead. Running several platforms and doing the usual amount of discussion on debian-vote might be some extra burden for those people who are interested. I'm not sure I understand the concerns with all that. Even our existing leadership nomination procedure is nowhere near as pointless as real-world campaigning. We just have people summarize their opinions in one document (platform), and have one public discussion between them. In the last three years, the number of nominees for that was 8, 7, 6. The soc-ctte would probably be up to three times as many people (theoretical maximum, IMO), but likely considerably smaller platforms (because the candidates run for a position which has a modicum of specificity, so there's a decent limit on how many matters they will cover in the platform). Sure, there is hopefully no problem to find a replacement. My point was that we should explicitely name those positions who should not be a member of the soc-ctte. Okay. Interestingly enough, we don't have similar provisions in the constitution (§6.2) for the technical committee. Apparently, the secretary is a long-time member :) and at least a couple of leaders were too. -- 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 discussion at DebConf7 [was Re: Social committee proposal]
On Tue, Jun 26, 2007 at 10:48:51AM +0100, MJ Ray wrote: I feel we're really missing most sorely list-admin teams who will take care of the social fabric of one list each and are empowered to make limited short-term changes to preserve it, including updating the list info pages and small posting bans. We should prioritise those sorts of bottom-up change over a top-down soc-ctte. The problem with that is that nobody is proposing any sort of a model by which these teams would be composed. I personally can't see such a thing going far, because that would create various rulesets for various lists, and require involvement of far too many people to be authoritative. On the other hand, a single social committee provides for a body which will be by and large neutral towards all lists (it will apply the same reasoning towards all). Existing high-level posts with a social aspect, such as listmasters and DAM both, seem reluctant to wield their power, which is understandable because they cannot follow every interaction in detail. That's not really the only reason - another important reason is that the people by and large never subscribed to the said teams because they wanted to mediate social issues, but because they wanted to do the technical tasks. Another reason is that these teams are inherently an oligarchy, and handing down social decisions in such a setting can easily be seen as evil, so they steer clear of it. A separate group of people who don't mind handling the non-technical tasks will relieve them of these problems. soc-ctte will also have the problem of being unfamiliar with the situation - how is it going to solve many problems faster? Well, *anything* is faster than a technically-inclined listmaster team whose average time of handling social problems converges to infinity. :) (Which in itself is acceptable, really.) Will its actions also be heavy, as the big stick mentioned in its powers suggests it could. The main point, which apparently eluded you :) was that it needs to be able to have a big stick simply so that it has tangible authority. For some people, the authority provided by being a regularly elected body might not be sufficient to make them respect it. [...] * The communication of soc-ctte members with people about their behaviour which might eventually become a matter of committee deliberation should be kept reasonably private, to prevent unnecessary escalation What is reasonably private? Please avoid creating a Star Chamber. Also, how will we know which soc-ctte members are naughty or nice, or whether we should remove members or terminate the ctte? See in another part of the thread, regarding our archive on master. [...] * The establishment and composition of the actual soc-ctte: [...] delegation [...] voted upon [...] Was the jury selection model discussed at all? I don't think it was. Can you explain a bit? If it's all voting-derived, how can we assure there will be any debian-minority views represented on soc-ctte at any time? I don't believe we can assure that any better than we assure right now that a majority doesn't stomp all over a minority... I think it's an acceptable compromise. -- 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 discussion at DebConf7
Josip Rodin [EMAIL PROTECTED] wrote: Sure, there is hopefully no problem to find a replacement. My point was that we should explicitely name those positions who should not be a member of the soc-ctte. Okay. Interestingly enough, we don't have similar provisions in the constitution (§6.2) for the technical committee. Apparently, the secretary is a long-time member :) and at least a couple of leaders were too. The tech-ctte is supposed to judge on technical grounds and not consider merit or power. The soc-ctte will for sure not exclude merit completely from their considerations, and - by the nature of their task - are probable to consider power, too. And maybe that's not even a bad thing. I think this shows that the separation is more important here. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]
On Tue, Jun 26, 2007 at 05:19:27PM +0200, Josip Rodin wrote: On Tue, Jun 26, 2007 at 09:19:46AM +0200, Raphael Hertzog wrote: The biggest decisions need to be publicly documented however. I don't think we've clearly drawn the line here. I'm also unsure if it's important to have a clear line here. We can just let the ctte draw the line where it's appropriate given that any communication concerning the ctte should ideally be archived on master.d.o just like other aliases are archived there ([EMAIL PROTECTED], [EMAIL PROTECTED], etc.) and that DD should be able to consult them. I was going to suggest DDs being able to read it, exactly like that, but I did get a vibe from Bdale and others that even that would be too much exposure. I'm not sure, someone should elaborate if they disagree. I think that the internal discussions should be kept private to the soc-ctte at least as long as no decision is made. As decisions made by the comitee will probably quite often involve social behaviour of DDs I think it's problematic if all DDs can read the internal discussions of the comitee members. I believe that the comitee members should be able to discussion various options without the fear that something could be publicized (probably resulting in a flamewar) before even a discussion in the comitee is made. After a decision is made I think it's less problematic to make the discussion available to all DDs. But still there is the problem, that offending behaviour would be exposed to all DDs. Gaudenz -- Ever tried. Ever failed. No matter. Try again. Fail again. Fail better. ~ Samuel Beckett ~ pgpdbaHclSjkX.pgp Description: PGP signature
Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]
On Wed, 27 Jun 2007, Gaudenz Steinlin wrote: I think that the internal discussions should be kept private to the soc-ctte at least as long as no decision is made. As decisions made by the comitee will probably quite often involve social behaviour of DDs I think it's problematic if all DDs can read the internal discussions of the comitee members. DDs have to have a level of oversight over the committee. This includes being aware of the rationale behind decisions as well as the decision making process which leads up to them. Cases where decisions are not made are as important as cases where they are. Members of the committee who are concerned about that level of oversight probably shouldn't be on the committee. It's fine to make distribution of the internal discussion list non-automatic, but it needs to be viewable. It's also seems appropriate if the internal discussion list is moderated or restricted to ctte members. Don Armstrong -- Information wants to be free to kill again. -- Red Robot http://www.dieselsweeties.com/archive.php?s=1372 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: soc-ctte discussion at DebConf7 [was Re: Social committee proposal]
On Tuesday 26 June 2007 15:33, Gaudenz Steinlin wrote: After a decision is made I think it's less problematic to make the discussion available to all DDs. But still there is the problem, that offending behaviour would be exposed to all DDs. The committee's deliberations should be solely based on objective facts. If the committee's deliberations cannot withstand the light of day, they are not a sufficiently robust basis for a _Debian_ decision. Cabals and secret deliberations are the antithesis of freedom. --Mike Bird -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
