Re: Further draft Social Committee text
On Wed, Jun 27, 2007 at 11:27:09PM +0100, Ian Jackson wrote: CHARTER OF THE SOCIAL COMMITTEE Going back to this old thing... :) The bulk of the charter can be promulgated by the developers through a GR, rather than just the leader, so I'm looking at it from that aspect (and from the general aspect of reviving the process...). 1. The Social Committee's purpose is to promote constructive and agreeable relations between Debian Developers and others involved with Debian. This should also mention - documenting the social norms and procedures that are used by developers and others to achieve the same purpose. Documenting seems like a good way to avoid saying deciding there, placing emphasis on existing practice rather than novel ideas. 2. To this end the Social Committee may: (1) Make a decision when asked to do so. Any person or body may delegate a decision of their own, or a class of decisions, to the Social Committee, or seek advice from it. This is a bit vague. The section Jurisdiction below doesn't explain the default area of decisions put in front of soc-ctte, only the first paragraph does. I'm assuming you mean that the first paragraph takes precedence over everything...? Anyway, if the former change to the first paragraph is accepted, then the only part that's missing from my proposal was to say that it decides on general matters of organization within the Project. I'm not exactly sure how that came about, but it can be left out, I guess. (2) Offer advice. The Social Committee may make formal announcements about its views on any matter. This includes but is not limited to both statements about particular cases and documents giving general guidance. (Individual members may of course make informal statements about their views and about the likely views of the committee.) This should be split into two parts - one regarding views on particular matters, and one regarding views on general matters, because that's something that people might wish to amend. (3) Request Cease and Desist That's a harsh way to call it :) Intervene in communication processes in matters of common interest (4) Make Access Control Decisions Provided at least two thirds of the SC positively agree, This limitation should be left for the Procedures section. instruct Debian's mailing list administrators, IRC operators, and other persons in similar positions the administrators of Debian's official communication forums - to avoid being overly specific. to make or remove access control arrangements which allow or prevent a person or persons from sending messages via communications facilities. to make or remove access control arrangements which allow or prevent a person from pursuing a particular action that was previously a matter of an aforementioned request to refrain This limits the soc-ctte actions to something for which there is precedent. That should eliminate any fears that overly generic anti-abuse policies would be imposed. Where the access-controlled resource is not one maintained for and by the project as a whole, but is instead a private resource (including private resources hosted on project systems), the Social Committee may only make requests rather than giving instructions. I think this paragraph might be needless (it's fairly obvious). (5) Recommend suspension or expulsion from the Project Provided at least two thirds of the SC positively agree, Again something for the Procedures section. (2) Send formal warnings A Committee member may send a formal warning to a person or group, giving that member's opinion, and such advice as the member sees fit. I can't parse this sentence. :) How about: A Committee member may send a formal warning to a person or group, giving their opinion or advice. Also add pursuant to SC's goals (like in the former section which I didn't quote). Also consider expanding the acronym in all cases. Such a formal warning from an individual SC member may be sent privately or publicly, but should be copied to the SC private mailing list. Omit the latter part (both because all SC-related mail should be Cc:ed to one of SC lists, and because it's a matter of procedure). PROCEDURE 6. The Social Committee will have a private mailing list for its use; this will be used for all formal business. Messages sent to this list will be available to the SC (including to future committees) but will not be published. In the previous discussion I said, referring to the informal mails: 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
(Further draft Social Committee text.) So what?
ef: news.gmane.org gmane.linux.debian.devel.project:12727 Archived-At: http://permalink.gmane.org/gmane.linux.debian.devel.project/12727 See below. This is not yet ready for promulgation by Sam but I think it more or less reflects what was discussed in Edinburgh. Sadly it has come out _far too long_. If anyone can produce a much shorter way of saying these same things I'll be very pleased. Failing that I might have a go with a scythe myself. And when _something_ good will be done WRT problems[0] and not bureaucracy? [0] BR #431145 (with some perfect [EMAIL PROTECTED]) In case somebody wonder: just it from reading BTS ML. ohshit(really); -- -o--=O`C #oo'L O ___=E M -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Further draft Social Committee text
On Thu, 28 Jun 2007, Raphael Hertzog wrote: The rest of the soc ctte should be in CC for such informal comments as well. Didn't we agreed to a private list? A lot of CCs tend to become broken at a certain time. 4. The DPL will aim for the SC to consist of 5 Developers. The SC may not use its powers according to s2 above unless it has at least 3 members. Why give a precise size? According to my English knowledge aim for consist of 5 is not really a precise size but rather a rule of thumb and according to this interpretation I think this makes perfectly sense. 5. Each year, the SC membership will be reconfirmed as follows: (1) The Project Secretary will conduct a series of separate but concurrent votes, one for each member of the SC. In each ballot, the options will be `Keep' and `Dismiss'. I'd rather have a single vote. Keep is above NOTA, Dismiss is below NOTA. The criticism of the method for multiple winner doesn't seem to warrant the overhead of habing that many votes. IMHO Ian's suggestion enables that members will be sorted out effectively. 16. If sufficient suitable candidates come forward, the DPL will then publish a proposed list of 5 members for the committee. Any volunteer not put forward by the DPL but who achieves K sponsors within the next 2 weeks, will also be added to the list of candidates. I don't see why he should propose only 5 members. He can propose more and the top-5 will be elected? ACK. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Further draft Social Committee text
On Fri, 29 Jun 2007, Andreas Tille wrote: On Thu, 28 Jun 2007, Raphael Hertzog wrote: The rest of the soc ctte should be in CC for such informal comments as well. Didn't we agreed to a private list? A lot of CCs tend to become broken at a certain time. Sure. I never meant personal CC. It was just a way to express the intent without making an assumption on how it's really done (looks like it failed:)). 4. The DPL will aim for the SC to consist of 5 Developers. The SC may not use its powers according to s2 above unless it has at least 3 members. Why give a precise size? According to my English knowledge aim for consist of 5 is not really a precise size but rather a rule of thumb and according to this interpretation I think this makes perfectly sense. Ok. 5. Each year, the SC membership will be reconfirmed as follows: (1) The Project Secretary will conduct a series of separate but concurrent votes, one for each member of the SC. In each ballot, the options will be `Keep' and `Dismiss'. I'd rather have a single vote. Keep is above NOTA, Dismiss is below NOTA. The criticism of the method for multiple winner doesn't seem to warrant the overhead of habing that many votes. IMHO Ian's suggestion enables that members will be sorted out effectively. You really don't want to have 10 votes in parallel... replying 10 times to 10 mails, possibly typing the GPG passphrase several times. You might tell it's only a technical problem in devotee, but until you fix devotee to handle several ballots in the same mail, I won't endorse this choice. For me concorcet is perfectly able to sort out those have been ranked above NOTA from those who have been ranked below NOTA. I really don't see the problem. 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: Further draft Social Committee text
On Fri, 29 Jun 2007, Raphael Hertzog wrote: You really don't want to have 10 votes in parallel... replying 10 times to 10 mails, possibly typing the GPG passphrase several times. Yes, this is a real drawback of this procedure. I think my very personal way to go with this to vote only against those people I would think that should leave their seat in the SC and just do not vote pro at all. I'm aware that this would not work if everybody would behave equally because very view votes against a member could remove it from the SC. I have no idea whether we should adapt the rules to the lazyness I expressed above: If there are a number of No against one member of the SC that exceedes a certain quorum this seat has to be replaced. You might tell it's only a technical problem in devotee, but until you fix devotee to handle several ballots in the same mail, I won't endorse this choice. For me concorcet is perfectly able to sort out those have been ranked above NOTA from those who have been ranked below NOTA. I really don't see the problem. I personally could also live with that, but as I said I have the feeling (note feeling is not based on experience or facts I have) that it is not as effective to replace a member. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Further draft Social Committee text
On Wed, 27 Jun 2007, Ian Jackson wrote: 3. To the same ends, the individual members of the Social Committee should when they consider it appropriate: (1) Send informal comments about behaviour An SC member may send a private message to a person or group, pursuant to the SC's goals, giving that SC member's opinion about anyone's behaviour, and giving such informal advice as the member sees fit. Any private communication by a Social Committee member, on a matter which a recipient reasonably believes is made in the member's SC capacity (whether that capacity is explicitly stated or not) may be published by that recipient, without asking permission from SC member who sent it. The rest of the soc ctte should be in CC for such informal comments as well. Because you want to avoid sending to many informal comments to the same person, and if several messages are sent, it's best if they are complementary. Maybe they don't need to be archived and accessible to the DD however. Not sure about it. COMPOSITION 4. The DPL will aim for the SC to consist of 5 Developers. The SC may not use its powers according to s2 above unless it has at least 3 members. Why give a precise size? I agree that 5 is a reasonable number (much more than the size expected by Josip) but I don't see why we should forbid the DPL to make this 8 or more if he really wishes so... as long as the internal decision mechanism is adapted to that bigger size (inactive people must not block the active members provided a minimum quorum of 3 is achieved). 5. Each year, the SC membership will be reconfirmed as follows: (1) The Project Secretary will conduct a series of separate but concurrent votes, one for each member of the SC. In each ballot, the options will be `Keep' and `Dismiss'. I'd rather have a single vote. Keep is above NOTA, Dismiss is below NOTA. The criticism of the method for multiple winner doesn't seem to warrant the overhead of habing that many votes. I also think we more or less agreed on a 2 year period? (I don't mind having a yearly election, but I also don't see the point of it) 7. When the SC takes a formal action according to s2 above, the notice it gives of this action will include: (1) a statement of the decision; (2) the reasons for that decision; (3) which SC members concurred with the decision; and (4) which (if any SC) members disagreed with the decision or the reasons, and those dissenting members views and reasons. This notice shall be sent at least to all of the parties to a dispute and to anyone expected to implement it. Anyone who receives it may make it public. Shouldn't those decisions be archived in a DD-readable mbox? 16. If sufficient suitable candidates come forward, the DPL will then publish a proposed list of 5 members for the committee. Any volunteer not put forward by the DPL but who achieves K sponsors within the next 2 weeks, will also be added to the list of candidates. I don't see why he should propose only 5 members. He can propose more and the top-5 will be elected? 17. Simultaneous but separate ballots will be held by the Project Secretary, as follows: * Yes/No/FD on this Social Committee proposal * Appoint/Reject for each candidate Same concern as above, I'd go for a single vote on the members. 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: Further draft Social Committee text
Frank Lichtenheld writes (Re: Further draft Social Committee text): On Wed, Jun 27, 2007 at 11:27:09PM +0100, Ian Jackson wrote: 10. Appeal of any decision made by the SC is via General Resolution, only. Decisions ^^ Is there something missing here? No, I think that's an abortive attempt at one of the subsequent paragraphs. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Further draft Social Committee text
See below. This is not yet ready for promulgation by Sam but I think it more or less reflects what was discussed in Edinburgh. Sadly it has come out _far too long_. If anyone can produce a much shorter way of saying these same things I'll be very pleased. Failing that I might have a go with a scythe myself. Ian. SUGGESTED NOTICE BY THE PROJECT LEADER ESTABLISHING A SOCIAL COMMITTEE RUBRIC A. I consider it necessary that it would be beneficial to formally establish a Social Committee for resolving nontechnical disputes. B. I give notice that I intend to establish such a Social Committee as Delegates of the Project Leader, using the Leader's powers in Constitution 5.1(1). C. Please volunteer to work on this new committee - see sections 15-17 below. Send your application to [EMAIL PROTECTED]; you have two weeks to make up your mind and apply, and a simple message saying that you're volunteering will do. CHARTER OF THE SOCIAL COMMITTEE 1. The Social Committee's purpose is to promote constructive and agreeable relations between Debian Developers and others involved with Debian. 2. To this end the Social Committee may: (1) Make a decision when asked to do so. Any person or body may delegate a decision of their own, or a class of decisions, to the Social Committee, or seek advice from it. (2) Offer advice. The Social Committee may make formal announcements about its views on any matter. This includes but is not limited to both statements about particular cases and documents giving general guidance. (Individual members may of course make informal statements about their views and about the likely views of the committee.) (3) Request Cease and Desist Where the SC thinks it necessary to avoid serious hindrance to constructive and agreeable relations, the SC may request that a person to refrain from certain acts and communications. The nature of the acts to be avoided should be clearly stated in the SC's request. For example, the SC might ask a Developer not to NMU a particular package, not to contact a particular other Developer, or not to post to a particular mailing list or not to post discussing particular topics. Note that this power extends to any context where a person is using facilities intended primarily for Debian, and also to any context where a person would generally be taken by outsiders as representing Debian. (4) Make Access Control Decisions Provided at least two thirds of the SC positively agree, instruct Debian's mailing list administrators, IRC operators, and other persons in similar positions to make or remove access control arrangements which allow or prevent a person or persons from sending messages via communications facilities. For example, the committee may ban (temporarily or permanently) a person or people from posting to certain mailing lists or in certain threads. Where the access-controlled resource is not one maintained for and by the project as a whole, but is instead a private resource (including private resources hosted on project systems), the Social Committee may only make requests rather than giving instructions. For the avoidance of doubt no-one (the Social Committee not excepted) is permitted to prevent a Developer from posting to the formal decisionmaking mailing list mentioned in Constitution 4.2(5). (5) Recommend suspension or expulsion from the Project Provided at least two thirds of the SC positively agree, the SC may make recommendations to the relevant Project Leader's Delegates that they exercise their powers to expel a Developer either temporarily or permanently. 3. To the same ends, the individual members of the Social Committee should when they consider it appropriate: (1) Send informal comments about behaviour An SC member may send a private message to a person or group, pursuant to the SC's goals, giving that SC member's opinion about anyone's behaviour, and giving such informal advice as the member sees fit. Any private communication by a Social Committee member, on a matter which a recipient reasonably believes is made in the member's SC capacity (whether that capacity is explicitly stated or not) may be published by that recipient, without asking permission from SC member who sent it. (2) Send formal warnings A Committee member may send a formal warning to a person or group, giving that member's opinion, and such advice as the member sees fit. Such a formal warning from an individual SC member may be sent privately or publicly, but should be copied to the SC private mailing list. COMPOSITION 4. The DPL
Re: Further draft Social Committee text
On Wed, Jun 27, 2007 at 11:27:09PM +0100, Ian Jackson wrote: 10. Appeal of any decision made by the SC is via General Resolution, only. Decisions ^^ Is there something missing here? Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
