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 o
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 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 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
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]
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
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]
