Re: [Pkg-samba-maint] Bug#532856: Bug#532856: closed by Mathieu Parent (Closing " umask settings overridden by Mac OS X 10.5 (Leopard) clients")
On Mon, Jul 02, 2018 at 09:41:39AM +1200, Andrew Bartlett wrote: > > How does that make sense? If the option is called "do X", and fails to > > do X in some opaque circumstances, how is that not a bug? At the very > > very least, it needs to be explained somewhere. Last I checked, there > > was nothing in the smb.conf manual to indicate that any of this would > > happen. The existence of a chmod extension isn't even mentioned. (As I > > said before.) > > > > On a more general note, I would recommend triaging user bug reports when you > > are available to actually try to understand what users are saying. Ignoring > > information provided and repeating the same question all over again is > > unhelpful at best. > > Honestly, this really isn't the place. > > While this goes against general Debian practice, these bug reports are > really not a good place to discuss general issues with Samba. It's unreasonable to have a Debian package that doesn't respect the universally common practices of the Debian bug tracking system. The Debian social contract doesn't go into that much detail, to explicitly require keeping bugs open because they exist in practice -- but common sense and decades of precedent do. Or is this some new thing that we're now doing, am I that much out of the loop? -- 2. That which causes joy or happiness.
Re: [Pkg-samba-maint] Bug#532856: Bug#532856: Bug#532856: closed by Mathieu Parent (Closing " umask settings overridden by Mac OS X 10.5 (Leopard) clients")
On Mon, Jul 02, 2018 at 01:39:34PM +1200, Andrew Bartlett wrote: > We simply don't have the resources to manage the tasks you suggest I'm saying one shouldn't send a message to n-close@bugs.d.o and instead just keep an existing bug open. That change alone actually conserves resources. Sending a message to the control bot to tag it upstream and perhaps mark it wontfix or a custom tag called triaged or something like that - doesn't sound particularly more taxing compared to closing. > Upstream (non-packaging) bugs filed here at best have to be copied into > Samba's bugzilla before any progress can be made and the lossy nature > of that just makes work for everyone. This is literally what every other maintainer is taught to do - weed through the chaff and forward upstream stuff upstream. > Finally, debates, even meta debates, about unsupported and ancient > Samba and MacOS versions are simply not productive. Yet, this isn't one, as I've long given up on expecting that upgrade path to be fixed - I've reverted to arguing simply that if there's a piece of functionality (Unix extensions) in the software, the documentation for the software should mention its basic characteristics, esp. those that have been known to cause annoying behavior in practice. It would be akin to having the Apache documentation describe its HTTPS support with two sentences in a manual, and have nothing else whatsoever (yet it ships e.g. /etc/apache2/mods-available/ssl.conf with a fair bit of info, and there's other docs too). -- 2. That which causes joy or happiness.
Re: [Pkg-samba-maint] Bug#532856: Bug#532856: closed by Mathieu Parent (Closing " umask settings overridden by Mac OS X 10.5 (Leopard) clients")
On Tue, Jul 17, 2018 at 04:49:57PM +0200, Thomas Goirand wrote: > On 07/02/2018 01:14 AM, Josip Rodin wrote: > > The Debian social contract doesn't go into that much detail, to explicitly > > require keeping bugs open because they exist in practice -- but common sense > > and decades of precedent do. > > I very much don't agree with the above. It is useless to keep bugs open > if they are not actionable. Bugs are reminders for the maintainers of > what they should do. If they can't do anything, then it goes on the way > to do useful things, and it is best if they can be closed. I don't know how you happen to define the word actionable, but English dictionaries say it's "capable of being acted on" or ready to be put into action". In all cases, these kinds of bugs could still get picked up by someone and acted upon (unarchived, reopened, forwarded upstream, possibly with a fix, closed when a package is released containing one). This idea that the bug reports of a package are merely a tool for the maintainer, who is at the same time able to arbitrarily decide that they can't do anything and that it's getting in their way... that seems way too possessive and against the spirit of the relevant part of the social contract. The bug report database should never be a personal fief of the maintainers, instead its primary purpose should be - to provide a useful service to users. https://www.debian.org/Bugs/Developer#closing spells things out nicely right at the start. I can understand tolerating hard cases with difficult packages, but we should not advocate a degradation of the golden standard because of outliers. -- 2. That which causes joy or happiness.
Re: ping the mirrors team
On Mon, Aug 08, 2005 at 09:59:13PM +0100, MJ Ray wrote: > > Debian did not respond. > > Since 1 July, new mirror reports open a wishlist bug against > the mirrors package and someone handles it when we get time. Unfortunately, this is a bad idea as it is now. We still tell mirror maintainers to enter semi-private email addresses into the form. The introduction of http://cvs.d.o violated the privacy of this data, but adding them to bugs.d.o does so much much more. There is certainly a rising need to collect public mirror admin contact addresses. However, there's also a need to collect private ones as well, because we in Debian need to have a way to contact mirrors without our mails possibly getting stuck in some large queue. > I've figured out where the older offers have gone (if any > other DD will sift the spam sooner, mail me) and I will work > on the backlog next week. Andreas Barth jumped in, too. This is also a chance for me to publicly apologize for being negligent in assigning new people to cover for me at mirrors@ while I'm busy IRL. Flames go -><- here. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Social Committee proposal
Hi, This idea arose from a discussion on the -private mailing list. Andreas Tille, Gustavo Franco, Manoj Srivastava and Gunnar Wolf all commented fairly positively on a vague idea of having a social committee (soc-ctte), different from the technical committee (tech-ctte). I'm citing their names simply to avoid an issues with taking credit. I'm re-posting my text to debian-project so that this worthwhile idea is not kept secret and/or lost in the noise at the other list. - I also think that a social committee would be a good idea. Even if unrefined and/or undefined, just the notion of having both a technical and a social committee would indicate major progress in our way of thinking. Let me try to shape this idea by citing the constitution and proposing what the text of the constitution could be with regard to the proposed social committee. The Project Leader may: Appoint Delegates or delegate decisions to the Technical Committee. Lend authority to other Developers. The social committee could have its own delegations. The most obvious example that springs to my mind would be delegating one or more communications coordinators for this-and-that mailing list, or for this and that team in Debian. These delegates would have one little bit more of an authority to talk about those issues; on the other hand, they could be required to earn this privilege by being entrusted the task of monitoring all discussions on a list and making sure that no complaint goes unnoticed or unsolved, be it from a user or between developers. The committee should have in its charter the demand to avoid appointing such people out of the blue. Instead, it should by default act only when other developers request assistance from the committee on a particular matter. It could choose to intervene in some situation ad hoc, but then the leader should be allowed to halt such intervention if he decides that the soc-ctte was being too nosy. (This safeguard could be abused by the leader to obstruct the work of the soc-ctte, but the veto could easily be worked around in case of real problems by having other people bring the discussion up with the soc-ctte.) The delegation of decisions to the technical committee should also be included in the charter; if the soc-ctte can't decide (with a majority of votes) whether an issue is not technical but social, it should defer judgement. Continuing with the constitution citation... Make any decision which requires urgent action. Make any decision for whom noone else has responsibility. Propose draft General Resolutions and amendments. Maybe skip anything like these until we have more experience. Lead discussions amongst Developers. The Project Leader should attempt to participate in discussions amongst the Developers in a helpful way which seeks to bring the discussion to bear on the key issues at hand. The Project Leader should not use the Leadership position to promote their own personal views. This would work for soc-ctte, too. As far as appointment, we could try all the same for soc-ctte. Except two things: * keeping votes secret - maybe they should not be secret. * soc-ctte members should serve two years or more. Section 5.3 Procedure should apply, too. Comparing with section 6., Technical committee, let's see: Decide on any matter of technical policy. This includes the contents of the technical policy manuals, developers' reference materials, example packages and the behaviour of non-experimental package building tools. This one could be tricky to phrase. Maybe - "Decide on any social matter, including social norms and customs, non-technical communication among developers, and day-to-day organization matters within the Project." The points 6.1.2. through 6.1.7. should all be included, with s/technical/social/g or so. The Chairman can stand in for the Leader, together with the Secretary As detailed in §7.1(2), the Chairman of the Technical Committee and the Project Secretary may together stand in for the Leader if there is no Leader. Adding this could be postponed for later, or just skipped altogether, to avoid the impression that soc-ctte election is a shadow leader election or anything like that. As far as 6.2. Composition is concerned, I would think that the soc-ctte should be allowed to be rather large, growing comparably to the growth of the developer body. After all, its emphasis can't really be on leadership, I would think that we would want to have a decent sample of the developer body in it. Maybe the limit should be a third of the election quorum, or sqrt(number-of-devels)/2? Currently that would be 16 people. I think that's a good sample of people, and a workable audience for a mailing list (of soc-ctte). Even if we expand twice in size, that's still just 23 people (i.e. the ctte would not grow twice as large). The rest should be either copy/pasted from tech ctte or omitted for obvious re
Re: Please appoint one new person to the DSA Team
On Thu, Dec 21, 2006 at 04:06:56PM +1000, Anthony Towns wrote: > Martin, Branden and myself have all been trying to address the original > issue as DPL So it's taking three mandates, three years, and it can't be done? Why not? How can the DPL not get something done by his delegates? What purpose does our constitution serve if we can have people ignoring it for years with no penalty whatsoever?! > messages like the one beginning this thread don't help, Perhaps I agree with the *concrete* example, where one intricate problem was cited as the sole reason for a change. However, if there is also any implication that that complaints in general don't help, and I infer that from the whole context, then I'll have to repeat what I wrote before: that is a defeatist attitude, and the *wrong* attitude in the organization that has a thousand members. It's just untenable! > It would also be helpful if there were people who are able to commit time > to do significant but boring tasks to help DSA, expecting neither praise, > acknowledgement or, most importantly, any additional rights/priveleges in > return. If that's you please mail me privately, probably at [EMAIL PROTECTED] Doing anything in private conversations kills any transparency that we might have hoped to have, and will ultimately not fix the problem. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal
On Fri, Jan 26, 2007 at 01:07:30AM +0200, Lars Wirzenius wrote: > > Why don't I think it is a good idea? Well, because, unlike > > technical issues, social issues are very subjective. Also, social > > and cultural norms differ widely from culture to culture; which > > culture shall be represented in, and whose norms shall be enforced > > by this social/cultural committee? > > That's easy: we should enforce (assuming that is not too strong a word) > the social and cultural norms that we, as a community, agree on. The > comparison to technical policy is not entirely invalid: we make up our > technical policy ourselves, too. > > We can determine social policy by discussion and, if necessary, by > voting. I'd rather see consensus, and, more specifically, see the > soc-ctte spell out the social norms and if the developer body disagrees > with it, and can't convince the soc-ctte via discussion, they can force > a change via a GR. Thanks for saving me from having to say all that. :) The developer's reference, for example, includes several social norms already - anything that isn't a strict technical obligation but instead a matter of procedure and/or courtesy. A code of conduct, if you will. The mailing lists have an explicit code of conduct which is generally not enforced by any technical measure but maintained by consensus (or at least diligence of those who care, for the cynics among us ;). Those are some existing documented topics that a social committee could keep an eye on; there are also numerous matters relating to our day-to-day interaction that go unnoticed because they're so "normal" to us, but are indeed something that we would be wise to take care of. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Please appoint one new person to the DSA Team
On Thu, Jan 25, 2007 at 07:30:41PM +0100, joy wrote: > > It would also be helpful if there were people who are able to commit time > > to do significant but boring tasks to help DSA, expecting neither praise, > > acknowledgement or, most importantly, any additional rights/priveleges in > > return. If that's you please mail me privately, probably at [EMAIL > > PROTECTED] > > Doing anything in private conversations kills any transparency that > we might have hoped to have, and will ultimately not fix the problem. I should, however, mention that I also offer man-hours for any such tasks. (Does it really have to be a private-only mail to [EMAIL PROTECTED] or can it stay Cc:ed like this? I'll repeat it if necessary.) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal
On Thu, Jan 25, 2007 at 05:08:42PM -0600, Peter Samuelson wrote: > > I also think that a social committee would be a good idea. Even if > > unrefined and/or undefined, just the notion of having both a > > technical and a social committee would indicate major progress in our > > way of thinking. > > Pretty words. What problem is this supposed to solve? What benefits > can we expect from "major progress in our way of thinking"? Here's a few aspects of the issue (not necessarily *problem* per se): Debian is a thousand-member entity whose members operate according to numerous more or less standardized beliefes and procedures, with various intricate or general twists and undertones. So far we have attracted at least two sociologists found the project an interesting study for a scientific work. This isn't to say that I particularly fancy those things, but the fact that they happen should make us think about it. Or, alternatively, consider that other kinds of organizations, both for-profit or non-profit, that have as many members as we do also generally tend have a much more complex hierarchy than we do; they have whole human resources departments which organize various schemes to facilitate information sharing, decision making, etc. This isn't to say that I particularly fancy those, either, it's just that we might want to take note of our sheer size. Another point, perhaps a bit closer to our every day life in Debian, would be the simple fact that we still use the mailing lists as the main method of discussion, despite the fact we've grown a magnitude in numbers, and that the lists are actually too high-volume to track for a sizeable chunk of the normal human population :) The way we do this kind of stuff affects the way we do the technical stuff; for good or for bad, but it definitely has an impact. People will also notice that we still have a single leader, democratically elected but with uncommonly few powers; groups formed ad hoc which are influential, or groups formed after much fuss which are ineffective; individuals who can be MIA, or those who can pull entire important transitions all by themselves. Forming a new body that would try to consider various non-technical, social issues would definitely help gain some collective insight. Maybe we'll come to the conclusion that we don't need the committee? Maybe that we don't need the entire constitution?! Maybe, maybe not. But it's worth thinking about and discussing, in an organized setting. > > This one could be tricky to phrase. Maybe - "Decide on any social > > matter, including social norms and customs, non-technical > > communication among developers, and day-to-day organization matters > > within the Project." > > For example? For every social problem I can think of in Debian, the > solutions are not enforceable by a committee vote, unless you give them > the authority currently held by the DAMs, listmasters and ftpmasters. > That is, the only ways I can see to effect social reforms is to be able > to throw people out of the project, or restrict their list postings, or > restrict their uploads. Anything less is just empty gestures. I disagree, it most definitely is not! Most people in Debian are not sociopaths, they can be reasoned with, and they *should* be reasoned with. We have been doing exactly that all this time, and it has not really failed us yet. Also, the social committee shouldn't necessarily effect *reforms*. It might as well evolve into a reactionary entity that aims to maintain the existing social order in Debian. But that's beside the point. The point is that we don't have any group doing any organized thinking about these matters. > People who cause social problems don't stop just because someone asks them > to stop. > > Or is this, just like way too many other threads in Debian, really > about Sven Luther needing a better ombudsman? Umm, what? You do realize by the amount of my participation, or rather the lack thereof, that I barely ever looked at the Sven Luther discussions that caused this latest commotion? Please let's not resort to semi-random cheap shots. Please consider the proposal on its own merit. Consider also the simple fact that I have been in this community for over eight years now, and that I do have better things to do than to go about proposing a generic constitutional ammendment over a single more-or-less transient issue. > Perhaps you need to import a bit more context from -private. What do you have in mind? This is it, AFAICT. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal
On Thu, Jan 25, 2007 at 05:55:03PM -0600, Manoj Srivastava wrote: > But the technical issues are often not subjective; while > social issues almost always are subjective, and very very heavily > influenced by cultural bias. > > Voting implies the tyranny of the majority; and I would expect > the social and cultural norms to be heavily biased towards white, > male, occidental euro-american social and cultural modes; since such > is the composition of the voting population. > > I am not sure I want to be governed by such a social /cultural > policy. All that you say is true, but it is also true that *right now* we all abide by various social and cultural norms which are of various shapes and forms. The forming of a group which would discuss these subjective matters in an organized fashion wouldn't make them any more or less important, but it would give them a much more fair hearing (or at least more fair than a typical flamewar). As far as governing goes, I explicitly said in the proposal that the committee should not have many powers, and indeed that its initial instance should have an even more reduced set of powers from one that we could envision it to have, so that we don't rush anything. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal
On Thu, Jan 25, 2007 at 05:55:03PM -0600, Manoj Srivastava wrote: > > We can determine social policy by discussion and, if necessary, by > > voting. I'd rather see consensus, and, more specifically, see the > > soc-ctte spell out the social norms and if the developer body > > disagrees with it, and can't convince the soc-ctte via discussion, > > they can force a change via a GR. > > Voting implies the tyranny of the majority; I should also note that we have this sort of an effect already - if someone wishes to impose their ideas on others, for example to modify a certain package in a way that they think is right, they can usually achieve it by working hard enough and being patient enough to take over the package. Yet, we also have a tyranny of the minority effect, when e.g. a person with an uncommon opinion maintains a package in a way that contradicts with the wishes of others. Both of these kinds of people are free to participate in public discussions and represent their point of view. But then there can also be people who are not particularly interested in imposing their ideas on others, who don't have pretentions to take over other people's packages, or to contradict other people based on their opinion, or to represent their point of view in public discussions. These are actually discriminated against, because the reality seems to favor the more ambitious, the more active, the more vocal. Having various opinions represented through elected members of a committee will have various effects. It will dampen the effect of any small minority, including those who are otherwise dominant, if they couldn't elect a candidate who would represent their exact views most vocally; they could still counteract that by continuing to voice their opinions and convincing others to join and 'expand' their ranks. It would also support the election of candidates who enjoy support of the other kind of people, those who are otherwise disproportionally discriminated against. Bear in mind that we use a Condorcet method to elect people, meaning that the elected people will more often lean towards consensus than not. That could well be sufficient to avoid anything approaching a tyranny of the majority. If not, the committee's powers would never be as far-reaching as to actually be able to alienate any minority too much. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal
On Thu, Jan 25, 2007 at 06:34:47PM -0600, Manoj Srivastava wrote: > >> I'd rather see consensus, and, more specifically, see the > >> soc-ctte spell out the social norms > > > The developer's reference, for example, includes several social > > norms already - anything that isn't a strict technical obligation > > but instead a matter of procedure and/or courtesy. > > But the dev-ref is optional -- last time I read it, I did not > find it very useful tome, and I disagreed with a lot of its dictums, > and so I largely ignore it while building packages; I rely on my > sense of best practices. The tech ctte does not come down on me like > a tonne of bricks for not removing the . from my short descriptions. The social committee wouldn't do anything of the sort; like Lars said, it could spell out the norms. Coming down on people like a tonne of bricks would be anti-social, which would would go against the very notion of a *social* committee. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal
On Thu, Jan 25, 2007 at 07:06:33PM -0600, Manoj Srivastava wrote: > > I should also note that we have this sort of an effect already - if > > someone wishes to impose their ideas on others, for example to > > modify a certain package in a way that they think is right, they can > > usually achieve it by working hard enough and being patient enough > > to take over the package. > > > Yet, we also have a tyranny of the minority effect, when e.g. a > > person with an uncommon opinion maintains a package in a way that > > contradicts with the wishes of others. > > In both these cases, those that do the work make the > decisions. People who do not like it, and are willing to do the > work, can fork and offer alternatives. > > We don't generally let the majority decude how the working > minority does its work. Er, that's not a technically sound argument. Just because someone is more diligent in making uploads and more vocal in trying to explain why they should maintain a package, that doesn't in any way imply that what they are doing is better than what a person less intent on racing uploads and mailing list posts would be doing. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal
On Thu, Jan 25, 2007 at 09:07:34PM -0600, Manoj Srivastava wrote: > You see, the committee is going to define the norms. It is > going to lay down the acceptable cultural mores. In my experience, > committees never produce minimalist documents. The never know when > to stop. Design by committee is what gave us ADA. Er, do we see this pattern with the technical committee? The social committee would (by virtue of shared demographics) be composed of a similarly-minded people as the technical committee, so it stands to reason that they wouldn't act horribly different from one another. > Given that once codified, style, usability, and social > polices (well, almost any policy) tends to get more and more chiseled > in stone; creating a social policy is not in the Nay^H^Hprojects best > interest, perhaps. > > No, I am not sure I fully believe this, but it is a point that > should be considered as we dash headlong towards creating a social > committee and social policy to mirror the technical committee and > technical policy and constitutional amendments to chisel it into the > codex. Granted. Yet, I think that similar arguments must have been levelled in the early days against having a technical committee. Why did we need that, couldn't we all just get along? :) Self-regulation has worked for us for years, in both areas, after all. Maybe making changes isn't in our best interest. Yet, we've been pretty conservative about social matters for years now, i.e. we didn't tend to innovate in the community all that much. Having a committee for these matters won't really change any long-entrenched practices that people already practice, but it will provide a reasonable forum for discussion. (Before anyone says "but this is also a reasonable forum for discussion", I will just remind that this is a 694-member mailing list, just think about that a bit...) I sense a slightly increasing dissatisfaction among the various people for various reasons, and I tend to notice a pattern: the most annoying of the reasons are the non-technical reasons. Yes, non-objective topics are inherently more emotional, and yes, it would be nice if we could just make them go away. But we can't, we have to cope with them. We've been doing that individually so far, let's try structurally now. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal
On Fri, Jan 26, 2007 at 09:29:41AM +0100, Raphael Hertzog wrote: > I like the principle, but IMHO it should just be a DPL board or something > similar. Otherwise I really don't see the point of the committee. > > A good board would integrate people from the various important offices > (listmasters, ftpmasters, DSA, security, RM, DAM, ...) but that shouldn't be > mandatory. > > It's much simpler to take important decisions within a board: when you're > alone as DPL, you fear taking the wrong decision and end up taking no > decision. Within a board, it only needs one person motivated enough to > bring an issue to a vote and get a result that is way stronger. That's tricky when it comes to social relations. It only takes one person motivated enough to sway opinions in what others may think is the wrong direction. That would be detrimental - just like the technical committee doesn't really *lead*, the social committee shouldn't lead, either. It should offer assistance and guidance, but not too much beforehand. > With such a team you also have a broader coverage of the Debian community, > and potential problems can be discovered more quickly. > > I blogged on the topic in the past: > http://www.ouaza.com/wordpress/2006/09/04/steering-committee-or-board/ That's interesting, and it's probably worth considering, but again, it deals more with leadership than anything. > > As far as 6.2. Composition is concerned, I would think that the soc-ctte > > should be allowed to be rather large, growing comparably to the growth of > > the developer body. After all, its emphasis can't really be on leadership, I > > would think that we would want to have a decent sample of the developer body > > in it. > > In that case, you need to have decision mechanism that scales accordingly: > votes are open for a short period of time (let's say 4 days) and the > quorum for a vote ought to be relatively slow because on a large group, > you'll have always 1/3rd to 50% who are on business trip, on vacation, > busy, whatever. I figured that having the same voting time and quorum as the leadership election. You are right that it tends to draw out, but it's less of a problem if the positions last over a year. You want to give people ample time to get back from whatever distraction and help decide the membership of the committee for the next two years. The reason why I think this should last longer than one year is that there is no need to have yet another yearly election (it would end up just irritating many people) and since project is already over ten years old, we are fairly certain :) that it's going to be around in over one year's time for the next soc-ctte election. > > Maybe the limit should be a third of the election quorum, or > > sqrt(number-of-devels)/2? Currently that would be 16 people. I think that's > > a good sample of people, and a workable audience for a mailing list (of > > soc-ctte). Even if we expand twice in size, that's still just 23 people > > (i.e. the ctte would not grow twice as large). > > I find that number rather large. Around ten people ought be enough. But > then I don't mind trying :) Yes, I agree it's large for a *team*. Conventional wisdom says 5 or 7 people are best for teams. However, this is not a team :) It doesn't need to be streamlined; in fact, it probably *shouldn't* be streamlined, as it is supposed to cover a wide spectrum of people and opinions. > I would like if we could bring such a proposition to vote before the DPL > election of this year (because of the obvious consequences on the election > itself). You mean, we couldn't elect one person for both positions? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal
On Fri, Jan 26, 2007 at 01:15:14AM -0200, Felipe Augusto van de Wiel (faw) wrote: > While we are at the initial steps of discussing this idea, > I would like to "quote" a nice blog entry (thanks to David Nusinow > -- aka gravity -- for the link). David quoted the blog entry a > while ago, it is from a Gentoo Developer about some of situations > in Gentoo, how they tried to deal with the different situations > and how things evolved. There is also a nice followup in the > comments. > > http://spyderous.livejournal.com/80869.html > > Please, do not look to this as something specific to a > given distro or project, I'm also not trying to compare > communities, what I'm trying to do is increase the information > available for our decisions, because I _do_ think that we can > learn a lot from history, specially from similar experiences > and scenarios, in order to achieve our goals. > > This message has no intention to say "go ahead, do > that" or "stop right now, it will blow our toilets". :-) I sure hope nothing in Debian will ever be able to "blow my toilet" :)) That story sounds like they had applied an autocratic model, and a democratic model, and only then seemed to see flamewars as an issue. Heh, no shit :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal
On Fri, Jan 26, 2007 at 02:42:23PM -0600, Manoj Srivastava wrote: > > See, this is part of the problem: every time, and I do mean *every* > > time, anyone want to discuss the possibility of actually doing > > something about the abusive communication culture in Debian, there > > pops up people who loudly reject any changes. They (and you're > > usually one of them) say that it will be a violation of free speech, > > or will turn Debian into Disneyworld, or Teletubby land, or > > whatever. > > Your problem is that unlike Josip and Raphael, you are unable > to brook any criticism whatsoever. They listened to me, corteously, > were not swayed, and managed to convince me to go along with the > experiment. > > You, however, expect there to be no expression of isgivings, > or anything -- just arh rah rah all along. Well, for the record, I don't think that he was all that negative in the thread. He was argumentative, but not obstructive. I think there needs to come a time in every thread where we just acknowledge and enumerate differences in opinion, and stop it, because going further just makes us all repeat things. (/me ponders the idea of having a web interface to the mailing list where we could have a wiki about each major thread...) > > There is no need to become a Disney movie. There is no *intention* > > of becoming anything even like a Disney movie. I said the "don't > > swear" rule was an example and that it was not my intention to make > > up one. Yet you immediately pounce on that and use it as a stick to > > beat down any proposal for change. > > And I said that the fear I have (just look at the code of > conduct someone already came up with -- cloyingly sweet and dainty and > meant for saints, not human beings). I think I have precedence on my > side. Er, this is a moot point. I think that we didn't cover this bit so far very much. Where exactly in the Debian Project do we have a 'disneyland', and where do we have people forcing other people to abide by their unfounded social norms? We have precedents for the same things in the real world, yes. Okay. That point is fully acknowledged. In the Debian world, I don't really recall those things. It's more often that people break a modicum of social norms in order to flame, prove a point, or something. Amusingly enough, I do recall one instance where you wanted my packages to be non-compliant with policy because I didn't write my debian/rules files in make syntax. The policy manual now actually says that I'm breaking the rules, but nobody is enforcing it on me. And we seem to be getting along just fine :) > > Is that the level of discourse you want to engage in? > > No, but it does seem to be your level, which you do > effectively hide very well most of the time. Okay, Lars, Manoj, please let's stop there. The misdirected swearing, and the implication that abusiveness is being hidden, are simply wrong. Let's go back to assuming good faith and keeping it civil. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal
On Fri, Jan 26, 2007 at 03:35:14PM -0600, Manoj Srivastava wrote: > >> You see, the committee is going to define the norms. It is going to > >> lay down the acceptable cultural mores. In my experience, > >> committees never produce minimalist documents. The never know when > >> to stop. Design by committee is what gave us ADA. > > > Er, do we see this pattern with the technical committee? The social > > committee would (by virtue of shared demographics) be composed of a > > similarly-minded people as the technical committee, so it stands to > > reason that they wouldn't act horribly different from one another. > > I am not sure that follows. Case in point: while I think I am > a reasonably good fit for the role required for a tech ctte member > (if I were not, I would have resigned a long time ago), wil horses > would not drag me to a social committee. I don't think I fit the > demographic. > > Another thing is, that we are all self selected to put > together a yet-another-son-of-multics OS -- that is a pretty narrow, > tightly couple technical field, so we are all pretty close in the > technical domain. In other dimensions, liek geography, religion, > language, cultture, politics -- we are all over the field. We've got > liberal members, conservative members, left wing, right wing --- and > given that, I don't think it is easy to come to a consensus and not > impose majority will. Ah, true, but we do have one important social thing that makes close in that domain, too - the thirteen years of social interaction within the Debian Project, and many if not most participants also have personal experience in many years within those thirteen years. We must be guided by that. On related note, again, I wonder if it would make sense to impose a modicum of ratios on tenure for serving in the soc-ctte. Perhaps it would make sense to require that at least 1/3 of all elected candidates have been members of the project for at least Y/2 years, where Y is the age of the project? That wouldn't hamper the 'newbies' too much, but it would bring a modicum of balance that we can reasonably expect from people with seniority. > Well, the technical committee is passive. It does not actively > make policy. Err, didn't I say that the social committee would do the same? Indeed, I mainly modelled the proposed constitution ammendment after the wording for the same passive technical committee. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal
On Fri, Jan 26, 2007 at 11:54:54AM +0100, Raphael Hertzog wrote: > > > It's much simpler to take important decisions within a board: when you're > > > alone as DPL, you fear taking the wrong decision and end up taking no > > > decision. Within a board, it only needs one person motivated enough to > > > bring an issue to a vote and get a result that is way stronger. > > > > That's tricky when it comes to social relations. It only takes one person > > motivated enough to sway opinions in what others may think is the wrong > > direction. That would be detrimental - just like the technical committee > > doesn't really *lead*, the social committee shouldn't lead, either. > > It should offer assistance and guidance, but not too much beforehand. > > Each member of the committee is free to have opinions, however to change > that into a statement from the committee, he needs agreement from others via > a vote or something. > > So no I don't really think, it's detrimental. It's needed... the committee > is (like the DPL) here to support good ideas and give inputs when things > are not as good as they should or could be. Well, I agree that people can always be influential enough to convince others to follow in their tracks. But let's get back on track here. Because of our almost inescapable herd-of-cats mentality, I think that it will be best if we agree on a more-passive-than-active social committee right now, and later when we see how it works out, if it works out well, decide by another GR to put more trust in it and allow it to act more. > > That's interesting, and it's probably worth considering, but again, it deals > > more with leadership than anything. > > I beleive it's tightly coupled. It's difficult to respect a single > individual you have not voted for. It's easier to accept the decisions > taken by 10 persons when you like what 6 of them are doing. Good point, that's why the social committee should have several members elected by a Condorcet method :) > > > In that case, you need to have decision mechanism that scales > > > accordingly: votes are open for a short period of time (let's say 4 > > > days) and the quorum for a vote ought to be relatively slow because on > > > a large group, you'll have always 1/3rd to 50% who are on business > > > trip, on vacation, busy, whatever. > > > > I figured that having the same voting time and quorum as the leadership > > election. You are right that it tends to draw out, but it's less of a > > problem if the positions last over a year. You want to give people ample > > time to get back from whatever distraction and help decide the membership > > of the committee for the next two years. > > I was referring to decisions taken by the committee itself not to the > way we elect the committee. Oh, I'm sorry, I didn't notice the word 'decision', mistook it for 'election'. As far as the decision making among the soc-ctte members, I figured the technical committee rules could be matched. I covered that with a blanket rule. Let's see the section 6.3.1 of the constitution: The Technical Committee uses the Standard Resolution Procedure. A draft resolution or amendment may be proposed by any member of the Technical Committee. There is no minimum discussion period; the voting period lasts for up to one week, or until the outcome is no longer in doubt. Members may change their votes. There is a quorum of two. Oh, now I see why Manoj may be thinking that the soc-ctte could be more active than passive. The sentence 'draft resolution may be proposed by any member of the committee' sounds like it would allow for random social policy to be invented based on Thinking about it, we can easily strike that out. Or replace it with something more lenient, such as random proposals by soc-ctte members themselves being limited to advisory decisions, rather than prescribing and overruling decisions. Thoughts? (Manoj also?) Now, back to the point about the process. We could set a minimum discussion period to seven days (one week). That would seem a reasonable requirement for a group where many could be on vacation, on a trip, etc. The quorum could be set to 50%, for example. That would be good for the aforementioned reason, and for the simple reason of democratic legitimacy. > My view implies replacing the DPL by a DPL board, so it's better if we > change the rules before to elect a board instead of a single individual. > :-) I don't think we can get both things done in time this year, unless we combine the ballot. I really fear that a combined ballot might also mean that there is a conflation of issues. I don't want that to happen. But, in any case, even if we finalize the terms on the soc-ctte ammendment soon, a vote on that will end only after four weeks (minimum GR discussion period is two weeks, and another two weeks pass for voting period). The nomination period for the leader election 2007 should end around the 25th of February, so that is too soon.
Re: Social Committee proposal
Hi all, Andreas Tille sent me some good comments in private mail, and I answered him, but the answers are not private per se, so here go a few more aspects: - The committee should have legalese in the constitution, but also an initial charter-like document that explains all the possible pitfalls. This should be attached to the vote proposal in order to summarize the discussion from -project to all those who will vote. - We actually have ample precedent that we can generally get along nicely when thinking about ourselves socially - witness the successful Debian Conferences held each year. Sure, there are problems with them, but we manage to pull off this social gathering every time, in all sorts of different places and contexts. - Besides, we can always repeal the committee with the same kind of GR that would introduce it. - On the topic of whether the members of the committee would be too technically-inclined or too socially-inclined, and how the leader seems always to be a most technically apt person: If given a choice to pick exactly 1 person for the most honorable position - all of us will prefer the highly technically skilled person. This will never change, nor should it! But, if given a choice to pick 16 people for a position like this, we won't necessarily find 16 highly technically skilled people, nor will we necessarilly all agree on the exact set of them. So we might end up with many technically skilled people in the soc-ctte, but also some socially skilled people. - The selection of people should also happen to reflect the kind of people the developer body is composed of. [Continuing on that note, there is a concern that representative democracy doesn't really make for an accurate representation...] In normal political systems you normally elect a party, which is represented by a few figureheads, and then when they come to power, they distribute their vote percentage onto all their members. Also, those things scale to much larger values, so there's more opportunity for abuse because people don't know each other. With a 16 member soc-ctte, our ratio voters/elected is just 62.5, whereas in real life people are excited to get the ratio down to 200 in villages, but it's usually much, much higher. In our elections, similar to the elections for the SPI board, we would not be electing any parties, but exact people with exact names and platforms and all. That is inherently better. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal
On Fri, Jan 26, 2007 at 10:55:02AM +, MJ Ray wrote: > That, in a nutshell, is my complaint against this draconian social > engineering proposal. It would be a powerful loose cannon on deck, > which could punish whole swathes of WASP developers, or (more likely > IMO) could further support majority prejudices, or something else. I am > fearful because of things like the outright disdain for the suggestion > that DDs should approve the Universal Declaration of Human Rights. > > This isn't even as clear-cut as an east/west or A/B cultural > difference. Even among the cultures most-represented among DDs, > developers seem to be atypical of those cultures as a whole. I must note that it would be no less powerful loose cannon on deck than the technical committee, and indeed it would be less loose because direct election would make it vastly more accountable (currently we can only replace tech-ctte members via proxy, and in a catastrophic scenario, that just doesn't cut it). > If the point truly is that we don't have any group doing any organized > thinking about this, then form such a group, but don't empower it yet. The problem with a an ad hoc group is the composition. We need elections to get it the group be representative and to be accountable. Do you think that we could just form it by way of modifying constitution, but strip out half the proposed Powers section? > > Umm, what? You do realize by the amount of my participation, or rather > > the lack thereof, that I barely ever looked at the Sven Luther > > discussions that caused this latest commotion? Please let's not resort > > to semi-random cheap shots. > > You do realise that other DDs do not generally install keyloggers or > other monitoring software on your -private mailbox and so cannot tell > how much you looked at the Sven Luther discussions? Please don't > resort to cheap shots. Just answer the question. > > I think "Umm, what?" is rather rude - see comments below about register. I wasn't the one who started with the rude insinuation, so please don't point the finger only at me. I'll happily answer the gist of the question directly - no, this is not related to Sven Luther. Yes, I know that there was a lot of commotion about him, and I know that it would be possible for Sven Luther, like all other developers, to bring up an issue in front of soc-ctte, but that's it. > I believe that there should be some lesser process than expulsion for > resolving problems with developers, but I do not believe that a new > "social committee" would be a good way to create that. It would be > better to reform some of the existing posts and make their actions > less binary and secretive. The committee would be a representative way of saying that, for example. Right now we have either unorganized people practically chatting about it, unorganized people voting for the DPL (a proxy, and an inefficient one), or someone calling for a general resolution vote. None of these measures are fruitful, for years now. > > [...] (Before anyone says "but this is also a reasonable > > forum for discussion", I will just remind that this is a 694-member > > mailing list, just think about that a bit...) > > The problem is not the total of 694 members. It's the behaviour of > the 694 members in total. Appointing a subset of them is less > beneficial than educating the 694 members in total. This is a > reasonable forum for discussion, but it needs to be led in an open, > transparent and respectful manner. > > But that's common for many lists and not a uniquely debian problem. It is practically impossible to fully 'educate' the total number of members, and it's practically impossible to even start doing that before we define what this 'education' really is. I'm sure you would like to have a say if someone just suddenly started defining a curriculum :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal
On Fri, Jan 26, 2007 at 08:07:44AM -0200, Gustavo Franco wrote: > I don't see a soc-ctte as a problem, if we define how such a committee > will act to solve some of our problems though. We need some thing like > committee use cases, not just an vague idea. Well, the committee could issue advisory opinions on procedures of mailing list members, packaging groups, infrastructure groups, user groups, developers contacting users, etc. Anywhere where people interact socially. I don't think it's really possible be any more specific than that - once we get the first nominations for committee members, we'll see what people want to do. In the nomination discussions we'll see how they do. After election, we'll see what the elected subset of people does, and how they respond to presented issues, and how they vote on them. I suppose that could be too vague for some people. I don't think that's a show-stopper, though. > Unfortunately, i can see that some people here into this thread try to > spread FUD just based on the idea. Those could get their volunteer asses > and do something more useful and let us discuss if the soc-ctte use cases > we came up with are worthy. You need to understand that this is the nature of public discussion - people will sometimes say something you don't like, and it might seem to you that 'they' have an agenda, or that they are undermining one's effort, or things like that. One of the things that we might as well need to make a tenet is - assume good faith. My experience suggests overwhelmingly that this is the way to go. As far as the concrete issue, rest assured that I'll combine all the good stuff from the thread and compose the exact proposal, with variations if necessary, which you will be able to comment on, and if all goes well, second and we'll have an general resolution vote to see if it's any good. I don't intend to let this die as a proposal, because all comments so far are generally positive enough to give it a go at the ballot box. > Closing, before any soc-ctte that i hope can help us solve a set of > our problems, we need changes the way tech-ctte actually works. I will > elaborate more in the near future and avoid debate with those that > came up here to say "nothing needs to be changed into Debian", > "nothing needs to be changed into tech-ctte", "what's wrong (we're > doing great in the tech and social sides, that's the dreamland!) ?". If you'll be concentrating about the tech-ctte, please start a new thread :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dissent and multiple viewpoints
On Fri, Jan 26, 2007 at 03:26:19PM -0600, Manoj Srivastava wrote: > Have we really forgotten what it is like to jointly work on > something when every one is not a rah-erah cheerleader? Where we can > have people contributing who, not being fully convinced, provide the > loyal opposition viewpoint, without being dismissively labelled as > whiners? > > In a large project it is easy to carve off small groups of > very like minded people, and doing so might even be nicer, since > there is no differences of opinion; but then we have strong > differences emerge between largely unrelated groups of people who are > well along doing things at odds with each other. > > I think the ability to pull together on something even when > one is mildly skeptical of the outcome would be invaluable to the > strong proponents, since these skeptics provide an alternate > viewpoint and also help provide a modicum of check and balance to > irrational exuberance that might otherwise result. > Dismissing co-operative people as whiners and and > obstructionists if their views are not absolutely in line with the > proponents loses the projects which display such characteristics of > potentially useful contributions. Seconded. :) I figured I'd also write something illustrative to avoid making this an AOL message, but that would just detract from the point. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal
On Sat, Jan 27, 2007 at 03:05:29PM +0200, Kalle Kivimaa wrote: > > The problem with a an ad hoc group is the composition. We need elections > > to get it the group be representative and to be accountable. > > An ad hoc group would most likely be composed of those people wanting > to work with the issues. Depending on how the group is composed > (closed or open membership) no one wanting to work wouldn't be left > out. Yes, but that would mean that it could have hundreds of members. That's just not manageable. > An election inherently means that some people wanting to work with the > issues are left out (not always, as often in large volunteer bodies you > struggle to fill out the minimum, IME). That's true, but people who don't volunteer to serve can still later submit ad hoc proposals. If their idea is good, it should still be accepted. > Why would an ad hoc body be less accountable than an elected body? > The body needs some kind of check to have any power, be it either a > DPL delegation or a direct constitutional power, but in either case > there should be a way to make the group accountable, even if they are > not elected. It would be inherently less accountable because people don't have any means to replace its members. Should we really let anyone join, and then have to convince the leader or do a general resolution vote every time we want to replace someone who's doing something wrong? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal
On Sat, Jan 27, 2007 at 04:25:26PM +0200, Kalle Kivimaa wrote: > > Yes, but that would mean that it could have hundreds of members. > > That's just not manageable. > > You're an optimist, I would think that there are at most a few dozen > interested people in Debian. But yes, in theory you could have as many > member as there are DD's (assuming that the membership would be > limited to DD's only). Yeah, and note that if you do actually get less people, you might get a higher ratio of people who are in it for not particularly good reasons - it would be an easy self-promotion method, if nothing else. > > It would be inherently less accountable because people don't have any means > > to replace its members. Should we really let anyone join, and then have to > > convince the leader or do a general resolution vote every time we want to > > replace someone who's doing something wrong? > > Well, now I'm being optimist, but I would think that a vote to replace > a member would happen a lot less often than a (yearly) election. Nevertheless, if you don't have that possibility, it's more likely that bad people would join the group thinking nobody will actually go through the bother of removing them. Note that I proposed an election every two years, thinking that we might want a wee bit less yearly elections and bit more consistency. Not that it necessarily modifies your position, but I'd like to hear if it does. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal
On Sat, Jan 27, 2007 at 08:31:57AM -0600, Manoj Srivastava wrote: > This kind of accountability implies several tacit points: > 1) the committee has some power (whatever those powers may be), > 3) that serving on the committee is a privilege It might be worth noting here that I think that even the single ability to make statements as a member of a constitutional committee is powerful enough to be something to require accountability. That is, even if we strip it off most of the powers as MJ seemed to imply earlier, it's still a noteworthy privilege to be able to do that in our community. > The bad thing about elections, though, is that they do tend to > promote what we call politics; this is because if you do not have a > clear measure of performance, it is highly unlikely you have any > predictive MOPs either. I agree that it's always a possibility that elections convert into a messy popularity contest. This should be alleviated by the fact that we're directly picking a larger number of people via a non-trivial election method, so those who accumulate fans as an agenda should experience the natural effect of also accumulating foes who see through their self-promotion, i.e. it will backfire on them. I hope that this will result in a more meek committee, and since it's a *social* committee, it's a much better default for its members to be meek than for them to be fierce. I was using some rather explicit/extreme terms in the above paragraphs - it is more likely than not that in Debian we won't see these corner cases, but they should be accounted for, just in case. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal
On Sat, Jan 27, 2007 at 07:25:49PM +0100, Andreas Tille wrote: > >If given a choice to pick exactly 1 person for the most honorable > >position - all of us will prefer the highly technically skilled person. > > All with exception of at least one (me): I would try to pick > the person that promisses to fullfill the most honorable > position. I would not regard the technical skills highest > if the position does not primarily needs technical skills. > > >This will never change, nor should it! > > I was not really aware that this is the case. Well, I was thinking more along the lines of people who are so disillusioned with promises that they don't really listen to stories, but instead concentrate on past action from a candidate. And since the main past action that usually happens is technical excellence, that ends up being the main criterion. > >But, if given a choice to pick 16 people for a position like this, > >we won't necessarily find 16 highly technically skilled people, > >nor will we necessarilly all agree on the exact set of them. > > > >So we might end up with many technically skilled people in the soc-ctte, > >but also some socially skilled people. > > Well, this sounds black and white: We need socially skilled > people. The fact that they are socially skilled does not > necessary exclude that they are technically perfect. Yes, you're right, I painted it too much black and white. What I really meant as 'technically skilled' was 'primarily technically skilled and not particularly socially skilled', and analogous for the other one. But maybe we strayed from the point there - I was just trying to address the point you previously made about how soc-ctte might become ignored by 'techies' because they don't regard the 'non-techies' highly - while possible, I don't think it will become a problem, because of two reasons: the first reason is that, by analogy with the DPL election, it will inevitably be firstly techies who will get elected to soc-ctte. The second reason is that the number of seats and the voting mechanism should work to ensure that all kinds of people will be represented in the soc-ctte, so it won't be a group exclusively composed of any single kind of people. > I guess you rather mean we need to include also people that are in > technical positions that are cruxial for Debian to keep the contact > between the soc-ctte and technical core groups as close as possible. That will also be a rationale used by some of the voters, I'm sure. :) > >The selection of people should also happen to reflect the kind of people > >the developer body is composed of. > > Problem: I've got the impression that Debian is a herd of > people showing very individual strengthes and that it is > hard to find or even to identify the "kind of people in > Debian". (BTW, this is one thing I really like at DebConf > meetings to be amongst very interesting people you will not > meet in every day life in this concentration.) I guess that's true. But we'll just deal with it as best we can (as we do in day to day operations, anyway). (A cynic would say that it's the showing of 'very individual strengths' that got us to the point where we need to think more about social issues... :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: something related to the soc-ctte
On Sat, Jan 27, 2007 at 11:41:30AM -0500, Kevin Mark wrote: > > After reading about various issues that arise in Debian on a social level, I > > thought about a possible solution: a Developer BTS. This would be modeled > > upon > > a mixture of the packages bts and Ebay seller comments. > For what ever reason I thought it was a good idea at the time, it > appears folks think its totally evil. I never thought of ebay sellers > comments as evil. But in any case, I shall not purse any future ideas on > this path. It's not actually too evil, but it's sufficiently bad to be avoided. The difference between such a semi-automatic bug tracking system and a committee processing of a problem is that the latter won't really be susceptible to hit'n'run abuse, semi-random insults and whatever subjective nonsense could reasonably be expected to plague a more automated system. This is no different for a technical committee than it is for a social committee - a complaint lodged before the entity will have to come with context, be discussed rationally and at considerable length, and a decision made about it, closing the issue. In the hypothetical situation where someone gets google'd years after a problem, it's not really different whether the problem was a technical or a social matter, because it would still not be some random bashing. Whereas if it was a page with gobs of assorted and potentially unsubstantiated accusations, that wouldn't really be good to have. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal (taking decisions by direct voting)
On Sun, Jan 28, 2007 at 12:40:30PM +0100, Frederic Lehobey wrote: > And what about having the election body enlarged to the complete (or > voluntary) developers crowd with a permanent and _easy_ way of voting. [...] > Note that I do not want to replace debate by voting. I simply prefer > to replace endless (and exhausting) discussions by decisions. Everybody voting on everything is not a direct solution for that problem; having someone break the cycle of endless discussion at the right time would be quite sufficient. Having soc-ctte (to whom people could appeal to get this done) would go a long way towards that fixing that issue. > If I understand well, the currently preferred way to solve conflicts > (even minor ones) is first trying to reach a consensus among the > developers through mailing lists, and in a last resort, in case of a > failure to build a consensus, calling for ctte or DPL mediation or > even start a GR. See, there you identified the major leap - we either have a normal process where everyone gets along anyway, or we have the 'last resort' options. We *don't* currently have a ctte for social problems, so the last resolt is either the DPL, meaning bothering one single person, or GR, meaning bothering everybody. Both of those options are inefficient beyond reproach. > A (free software) tool for making direct voting and decision taking > easy is developed there: > http://www.demexp.org/main/doku.php?id=english > It could be of interest to the Debian project as a whole (that has > been a source of inspiration by its voting method) Well, direct democracy would be a radical change. I'm not convinced that you should lump these two issues together - please start a new thread instead (what you just did is actually referred to as 'thread stealing'). > or for decision taking in sub-committees (as the soc-ctte at discussion > there). That might be more applicable, but we'd first have to have soc-ctte. :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal (taking decisions by direct voting)
On Sun, Jan 28, 2007 at 02:03:13PM +0100, Frederic Lehobey wrote: > I also believe it too difficult to implement in already existing (Debian) > constitutional bodies governed by other (working) rules. But I thought it > might worth consideration (even for experimentation) when designing and > setting up a new body (like soc-ctte). But you might consider it > unnecessary over-kill anyways... Perhaps not, but I wouldn't know how to code it into the constitution :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal
On Sun, Jan 28, 2007 at 01:42:20PM +, MJ Ray wrote: > > > [...] It would be a powerful loose cannon on deck, [...] > > > > I must note that it would be no less powerful loose cannon on deck than > > the technical committee, > > It maybe loose, but we know which way the technical committee is > pointing recently, because it has a history which we can see. > soc-ctte does not yet. Okay. Was there reason to be skeptical about tech-ctte when it was getting founded? Yes, even more so than this time. Should we have run away from it back then? > > and indeed it would be less loose because direct election would make it > > vastly more accountable (currently we can only replace tech-ctte members > > via proxy, and in a catastrophic scenario, that just doesn't cut it). > > Election and accountability are largely irrelevant to my complaint. Well, they provide for a way to fix problems that may ensue. For tech-ctte, we didn't even have that. > > > If the point truly is that we don't have any group doing any organized > > > thinking about this, then form such a group, but don't empower it yet. > > [...] > > Do you think that we could just form it by way of modifying constitution, > > but strip out half the proposed Powers section? > > Maybe it could operate as shadow at first, with s/Decide/Advise/ or > just remove them and rely on the 6.1.5 equivalent. Okay, I expect you to second such an ammendment. :) > > Where exactly in the Debian Project do we have a 'disneyland', and where > > do we have people forcing other people to abide by their unfounded > > social norms? [...] > > The August 2005 -private blow-up seemed like two groups (of totally > different sizes) trying to force each other. You mean the flamewar about how to handle a death? Where exactly was there any forcing there? Yes, people had strong differences in opinion regarding social matters, but how could have the existence of soc-ctte have done anything badly in that regard? Someone could bring it up with the committee, which would first decide whether to deal with the issue (which reminds me - need to add some provisions to the proposal that would prevent DoS attacks :), and then when it did, it would likely handle the issue with much more grace. Sure, you should reasonably expect the committee to have a hard time with controversial issues. However, it wouldn't *invent* those same issues, it would only deal with them once they already existed. > > [...] In the Debian world, I don't really recall those things. > > I'm pretty sure that "norm splits" are usually totally unremarkable to > most members of the majority in each split and they're not so common > as to happen all the time. Indeed. And the decisions that the soc-ctte would make would not be remarkable in a way that they would alienate minorities, because that would defeat the point of the committee that tends after the society as a whole. If they would do that, and not have their decisions reversed by GRs, then that would pretty much reflect the will of the electorate. If most people actually *want* to go against the wishes a certain minority, then you're screwed already, and there's little to be done about it anyway. At least with a soc-ctte there would remain a clear record of what happened and a clear path of appeal. > > It's more often that people break a modicum of social norms in > > order to flame, prove a point, or something. > > Whose social norms? For example, central government officers and > farmers have different styles. I'd rather talk like a farmer than an > officer but others may make the other choice. If these two approaches are wholly incompatible and cause others to think that people are breaking a modicum of social norms - you already have a problem. soc-ctte would merely try to handle the problem gracefully, rather than ignoring it. > I fear that a soc-ctte will try to enforce a particular set of social > norms and perpetuate the harmful Rabid Right meme, which I wrote about > recently http://mjr.towers.org.uk/blog/2007/debian#society I don't quite see how the existence of the committee would imply a tendency to be intolerant. (IOW I don't see the foundation of that fear.) > > The selection of people should also happen to reflect the kind of people > > the developer body is composed of. > > How? Is it known how Condorcet behaves in cross-community elections? > Will it reflect the community mix or will it over- and under-represent? We won't know the exact specifics until something happens, yes. There seems to be little applicable evidence to make a decent conclusion beforehand. > Really, I think electing soc-ctte is heading off into the Great > Unknown again, because none of the surveys I've noticed > http://people.debian.org/~mjr/surveys.html > have produced the basic demographics about who is debian AFAICS. So > far, it's been how and why is debian as it is, or who is developing > or using free software - and I doubt DDs are representative of
Re: Social Committee proposal
On Sun, Jan 28, 2007 at 01:51:28PM +, MJ Ray wrote: > > Yes, but that would mean that it could have hundreds of members. > > That's just not manageable. > > Then nor are ~1000 developers, nor the 6000+ who run a phone company > with me, nor the 3.5million who own shops with me, nor any other large > multi-member business, but that's clearly not true. You need to > manage them in a different way. This needs management in the large. Yet, all of those other groups that you mentioned have some form of semi-social organization: the phone company people have a management and (probably) a human resources department; the shop owners have guilds; and all of them combined have a common representation in the government (legislature) that defines laws and other acts. None of these things that govern their interaction are purely technical, many are social. > > Should we really let anyone join, and then have to convince the leader > > or do a general resolution vote every time we want to replace someone > > who's doing something wrong? > > Yes, you should let anyone join and then convince everyone every time > you want to replace someone. > > It may not be possible and it may be desirable to set things up so you > aren't *required* to do that, but I believe you *should* do it. I can't say I see how that would be a good idea. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Social Committee proposal text (diff)
Hi, Here goes my first try at the exact diff at the Constitution: --- constitution.wml2007-02-12 01:49:13.0 +0100 +++ constitution+soc-ctte.wml 2007-02-12 03:24:57.0 +0100 @@ -34,6 +34,8 @@ The Technical Committee and/or its Chairman; + The Social Committee and/or its Chairman; + The individual Developer working on a particular task; Delegates appointed by the Project Leader for specific @@ -64,7 +66,8 @@ A person may hold several posts, except that the Project Leader, -Project Secretary and the Chairman of the Technical Committee must +Project Secretary, the Chairman of the Technical Committee +and the Chairman of the Social Committee must be distinct, and that the Leader cannot appoint themselves as their own Delegate. @@ -142,6 +145,11 @@ Committee, provided they agree with a 2:1 majority. + +Make or override any decision authorised by the powers of the +Social Committee. + + Issue, supersede and withdraw nontechnical policy documents and statements. @@ -193,7 +201,8 @@ If the Project Leader or their Delegate, or the Technical - Committee, has made a decision, then Developers can override them + Committee, or the Social Committee, has made a decision, + then Developers can override them by passing a resolution to do so; see §4.1(3). If such a resolution is sponsored by at least 2K Developers, @@ -203,7 +212,8 @@ If the original decision was to change a discussion period or a voting period, or the resolution is to override the Technical - Committee, then only K Developers need to sponsor the resolution + Committee, or the resolution is to override the Social Committee, + then only K Developers need to sponsor the resolution to be able to put the decision immediately on hold. If the decision is put on hold, an immediate vote is held to @@ -263,11 +273,11 @@ Appoint Delegates or delegate decisions to the Technical -Committee. +Committee, or delegate decisions to the Social Committee. The Leader may define an area of ongoing responsibility or a -specific decision and hand it over to another Developer or to the -Technical Committee. +specific decision and hand it over to another Developer, or to the +Technical Committee, or to the Social Committee. Once a particular decision has been delegated and made the Project Leader may not withdraw that delegation; however, they may @@ -737,6 +747,210 @@ that includes the commitments those organisations have made as to how those assets will be handled. +10. Social committee + +10.1. Powers + +The Social Committee may: + + + +Decide on any matter of social policy. + +This includes social norms and customs, non-technical communication +among developers, and day-to-day organization matters within the Project. + + + + +Decide any social issue where Developers' jurisdictions +overlap. + +In cases where Developers need to implement compatible +social policies or stances, the social committee may decide the +matter. + + + +Make a decision when asked to do so. + +Any person or body may delegate a decision of their own to the +Social Committee, or seek advice from it. + + + +Offer advice. + +The Social Committee may make formal announcements about its +views on any matter. Individual members may of course make +informal statements about their views and about the likely views of +the committee. + + + +Defer judgement to the Technical Committee. + +If the Social Committee can not decide whether an issue is +social (rather than technical), it defers judgement to the +Technical Committee. + + + +Lend authority to other Developers. + +If a Developer brings up an issue with the Social Committee, +the Committee can vote to lend authority to a willing Developer +in order to assist in resolving the issue. + +The Project Leader may override the aforementioned action. + + + +Overrule a Developer (requires a 3:1 majority). + +The Social Committee may ask a Developer to take a particular social +course of action even if the Developer does not wish to; this requires +a 3:1 majority. + + + +Appoint the Chairman of the Social Committee. + + +The Chairman is elected by the Committee from its members. +All members of the committee are automatically nominated; the +committee votes starting one week before the post will become +vacant (or immediately, if it is already too late). The members +may vote by public acclamation for any fellow committee member, +including themselves; there is no default option. The vote +finishes when all the members have voted, or when the voting +period has ended. The result is determined using the method +specifie
Re: Social Committee proposal text (diff)
On Sun, Feb 11, 2007 at 10:59:15PM -0600, Manoj Srivastava wrote: > 1) When do developers need to implement social stances or policies? > Can you give an example of the kinds of things the constitution > may be talking about here? While copying and pasting :) I was actually puzzled at the amount of examples that were cited for the technical committee. I admit I don't have any so straightforward examples, but then, it was pretty late when I wrote that. I'll have to ponder on it before suggesting an example, because it would have to be worthy of being cemented into the constitution :) > 2) What happens if only some of the paticipants in a social, umm, > tussle, want to submit the affair to the soc ctte? Once referred, > are all other parties now subject to the soc ctte rule? Hm. I have no idea. What happens in the case of the technical committee? I don't think I changed anything with regard to issue scope. > 3) When a developer is over ruled on a technical matter, the tech > ctte can not force a developer to do something they do not want to > do (the developer can't stop other people from doing the task -- > no active work against, etc). Do similar clauses apply to the soc > ctte? Yeah, but this is governed by the same general rules section, 2.1.1. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal text (diff)
On Mon, Feb 12, 2007 at 10:49:51AM +0200, Kalle Kivimaa wrote: > > +The Social Committee may ask a Developer to take a particular > > +social course of action even if the Developer does not wish to; > > +this requires a 3:1 majority. > > OK, what happens if the Developer doesn't take the required course of > action? With the ctte it is easy, somebody does an NMU, but I don't > see how you can do something similar in social situations. Well, the short answer is, we deal with it the way we deal with it right now, just with some official approval. But, this is a reiteration of the desire for examples, which is understandable. Here's one that I can think of - soc-ctte could be asked to rule on whether some developer should be gentler on bug report submitters without closing bugs immediately, or without yelling at them, or something like that. In that case, the overriding mechanism would be for people to reopen such bugs, but the committee could still issue a formal request that the said developer refrains from being trigger-happy, and perhaps authorize the BTS admins to freely lock out the 'close' function for that person if they transgress. I could also imagine how a similar dispute would be handled with regard to mailing list abuse - someone could petition the soc-ctte to have a couple of conflicting developers take a never-ending flamewar off-list. > > + At least one third of all elected candidates should have been > > + members of the project for at least Y/2 years, where Y is the age > > + of the Project in years. If fewer than one third of candidates meet > > + this requirement, the election process is repeated. > > Like Lars already said, this becomes an impossible requirement sooner > or later. (Replying to both) Right. I didn't remember to consider that. Maybe change to: + PY is the age of the Project in years. SY is PY/2 or 10, + whichever is smaller. + At least one third of all elected candidates should have been + members of the project for at least SY years. + If fewer than one third of candidates meet this requirement, + the election process is repeated. > A five year rule would be better, but even then this rule may result in an > impasse, if we don't have enough qualified candidates who fullfil the > requirement. I pondered this a bit. In the current setting, it would require six out of sixteen seats to be filled that way. I don't think it should become a problem, but if you think it will, maybe the ratio should be reduced to 25% or something like that. I actually think that getting 16 candidates over 'none of the above' marker might be a bigger problem :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal text (diff)
On Mon, Feb 12, 2007 at 11:38:12AM +0100, Alexander Schmehl wrote: > * Josip Rodin <[EMAIL PROTECTED]> [070212 03:32]: > > > + During the following month, any Developer may nominate > > + themselves as a candidate member of the Social Committee. > > + Every such nomination must be seconded by one other developer. > > Any specific reason for having a full month as nomination period? Think of scale - right now we need 16 people to 'win' the election, and the seats last twice as long as the leadership seat. It made sense to me - please say if it doesn't to you. > > + The next two weeks are the polling period during which > > + Developers may cast their votes. Votes in social committee elections > > + are made public after the election is finished. > > And why shall votes become public? What's voting about, if not done in > secret? The secrecy is not the point - the point is that we make a cross-section of society, a sample of people who are at least vaguely representative. I don't see any reason against disclosure. > > + At least one third of all elected candidates should have been > > + members of the project for at least Y/2 years, where Y is the age > > + of the Project in years. If fewer than one third of candidates meet > > + this requirement, the election process is repeated. > > An native english speaker may corect me, but "should" is normaly used in > a kind of "would be very fine if, but not strictly necessary" meaning, > isn't it? So why first using "should" and later "if not, then we do it > again"? Well, it's just a matter of wording. (This is not an RFC, BTW.) Many other sentences just use 'is', and I think that's a bit strange :) But I should probably make it consistent, you're right. > And why that rule? I would think in a social ctte, fresh blood is very > welcome, because they (probalbly) haven't taken part in any flamewar and > therefore are the best to choice for a ctte, that should be as objective > and neutral as possible? Yes, and they can very well occupy the other 66% of the committee :) And I disagree that someone like that is inherently a best choice, because they might also not have any experience. Experience is generally a good thing. > > + > > +Public discussion and decision-making. > > + > > +Discussion, draft resolutions and amendments, and votes by > > +members of the committee, are made public on the Social Committee > > +public discussion list. > > +There is no separate secretary for the Committee. > > + > > So a member of the social ctte may not talk to an other member of the > social ctte about topics of the social ctte? Even if they meet in > person? > > An other point, where I fail to see the reason for it. AFAIK the tech > ctte has private list for discussion, Umm, no. This is copy & paste from the Technical Committee section. Their discussion list is (also) public. > and I would think that social problems / discussions should be considered > even more private. I disagree - if a problem is severe enough to get brought before soc-ctte, it's out in the open already, and needs to be dealt with transparently. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal text (diff)
On Mon, Feb 12, 2007 at 11:11:16AM +, MJ Ray wrote: > The above power seems daft. soc-ctte deciding that farting loudly in > DebConf dinner attendees' faces is a social norm would not make it so. > This power needs omitting or rewriting to be much closer to the > equivalent tech-ctte one, so it does not permit contradicting reality. Er, did you notice the part where it (copied and pasted from tech-ctte) says that it only chooses from available solutions already thoroughly discussed? So if developers were actually seriously arguing whether farting loudly in DebConf dinner attendees' faces is a good idea, and they decided to bring it to the consideration of the soc-ctte, the committee should be able to decide on that :) Note that someone could also submit the opinion that such an opinion is daft, and then the soc-ctte could decide so. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal text (diff)
On Mon, Feb 12, 2007 at 01:50:35PM +0200, Kalle Kivimaa wrote: > One question related to the Concordet method: does it fullfill the > representative criteria? > > AFAIUI the Concordet method allows this (please correct me if I'm > wrong): > > We have two groups of people, A and B. A has 20 people, B 10. A fields > candidates a1, a2 and a3, and B fields b1, b2 and b3. We are about to > elect three people. > > All A people post ballots a1,a2,a3,NOTA,b1,b2,b3, and all B people > post ballots b1,b2,b3,NOTA,a1,a2,a3. > > In your suggestion the first three people to be elected would be a1, > a2 and a3, as they all beat all B candidates. In a representative > election a1, a2 and b1 should be elected, instead. Er, I don't think I modified the election method in that way by including that sentence. I thought I said - follow section A.6, which determines the ranking, and then take the list and pick the top X people who are above NOTA. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal text (diff)
On Mon, Feb 12, 2007 at 01:22:41PM +0100, Josip Rodin wrote: > > In your suggestion the first three people to be elected would be a1, > > a2 and a3, as they all beat all B candidates. In a representative > > election a1, a2 and b1 should be elected, instead. > > Er, I don't think I modified the election method in that way by including > that sentence. I thought I said - follow section A.6, which determines the > ranking, and then take the list and pick the top X people who are above NOTA. Actually, upon closer inspection, I see now that A.6 is actually not completely accurate for this case. It has this: 8. If there are no defeats within the Schwartz set, then the winner is chosen from the options in the Schwartz set. If there is only one such option, it is the winner. If there are multiple options, the elector with the casting vote chooses which of those options wins. We need to skip that in case of soc-ctte elections. The list that I mentioned previously would be referred to as a 'Schwartz set', if I get this right. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal text (diff)
On Mon, Feb 12, 2007 at 12:44:40PM -0500, Joe Smith wrote: > >>and I would think that social problems / discussions should be considered > >>even more private. > > > >I disagree - if a problem is severe enough to get brought before soc-ctte, > >it's out in the open already, and needs to be dealt with transparently. > > Not nessesarally. A nasty non-technical dispute could occur on -private. > I belive that the soc-ctte could be asked to deal with this. It may not be > public, and it is possible that it should not be public. > That is especially true if the issue is privacy related. Well, the soc-ctte will function like tech-ctte. If a developer, be they a member of the ctte or not, screws up and posts sensitive info to soc-ctte public list - I'm not really sure that's something that can be regulated. Anyway, things can be discussed on debian-private and then people can decide what to do. I could imagine a situation where the leader delegates it to the soc-ctte to consider a particular issue behind closed doors. It wouldn't be "normal", but this should be an exception rather than a rule. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal text (diff)
On Mon, Feb 12, 2007 at 05:08:09PM +0100, gregor herrmann wrote: > > + If there are fewer than S2 candidates > > + at the end of the nomination period, then the nomination period is > > + extended for two further weeks, repeatedly if necessary. > [..] > > + If "None Of The Above" wins the election, or if fewer than S2 > > + candidates win over "None of the Above", the election process is > > + repeated. > > + > > + At least one third of all elected candidates should have been > > + members of the project for at least Y/2 years, where Y is the age > > + of the Project in years. If fewer than one third of candidates meet > > + this requirement, the election process is repeated. > > How often should the nomination period and the election process be > repeated? I'd suggest to include some maximum otherwise they could go > on ad infinitum. You can see similar rules in other parts of the constitution, see 5.2.4, 5.2.6. Do you think it's likely for it to go on for more than one repetition? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal text (diff)
On Tue, Feb 13, 2007 at 11:14:40AM +0100, Alexander Schmehl wrote: > > >> + The next two weeks are the polling period during which > > >> + Developers may cast their votes. Votes in social committee > > >>elections > > >> + are made public after the election is finished. > > > And why shall votes become public? What's voting about, if not done > > > in secret? > > I think we should default to open and transparent processes > > as far as possible. And people should be willing to take public > > stances on matters of policy, even social policy. It is not like you > > are voting for a human who might have his feeling s hurt. > > I read the cited paragraph as exactly that: The votes of DDs in the > election for the members of the social ctte will be made public. I > agree that the internal soc ctte votes are a different thing; but as I > understood it, they are not the topic of that paragraph. > > So it is exactly about "voting for a human who might have his feelings > hurt". And it is all about possibly voting differently while the public > is looking over your shoulder. > > I just don't see, how that will help to get a better soc ctte. You are aware that most of our elections are done this way, we only use hashes in the tally sheet for leader elections? I suppose we could also obfuscate the tally sheet for soc-ctte elections, too, but I would really be interested to see who would get offended at the votes, and particularly why they think that they should sit on a social committee if they can't handle social differences. I don't think I want anyone who fears the idea of public disagreement to sit two years in a committee that arbitrates social conflicts. How can I be sure that the same person won't act improperly when it comes to resolving other people's issues, if they can't handle their own issues gracefully? Maybe it's asking too much, but I really hope we that can find sixteen level-headed people among a thousand who can handle negative votes... -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal text (diff)
On Tue, Feb 13, 2007 at 11:17:52AM +0100, Alexander Schmehl wrote: > > > > + The next two weeks are the polling period during which > > > > + Developers may cast their votes. Votes in social committee elections > > > > + are made public after the election is finished. > > > And why shall votes become public? What's voting about, if not done in > > > secret? > > The secrecy is not the point - the point is that we make a cross-section of > > society, a sample of people who are at least vaguely representative. > > And how will a public election help us having at least vaguely > representative? I assume that the emphasis was on *public* election, not on public *election*. Having a record of who voted for whom is a good default. Since we don't have any typical real-world election abuses in Debian (e.g. intimidation or harming of people who voted for someone you don't like), I see no serious negative consequences to publishing the votes. The voters can compare notes about who they voted, the candidates can see who voted for them and who voted for someone else, and all can learn from the process. In the real-world, this might lead to a surge in populism - candidates would start appealing to the largest demographics in an effort to garner more votes; but here, the effect of that would easily be diminished as soon as people saw through it and started ranking such candidates down; the election method doesn't give much hope to candidates who are intensely disliked as well as intensely liked. We also don't have trivial mass-communication problems as the real world, and instead have numerous forums and ways of normal voters to communicate their thoughts with hundreds of others, so opinions are shared much more easily and you don't get stuck without a relevant information just because the editor at the TV station didn't think it was cool enough to report. Maybe there's something that I didn't notice - please do share your thoughts. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal text (diff)
On Tue, Feb 13, 2007 at 11:25:09AM +0100, Stefano Zacchiroli wrote: > No matter what's my opinion on whether fresh blood is good or bad for > the social ctte, I doubt it would make any difference to state a rule > like that. The committee will be elected and I seriously doubt any > "fresh blood" DD will be elected in such a position by the DD body. > > Sure there's no warranty that this is the cause, but I'm confident > enough in it to prefer not to write down such a rule. I suppose we could do that, too. I would not be opposed to that. On the other hand, we could also go middle ground and lower the threshold to something that is guaranteed to avoid re-votes. 20%? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal text (diff)
On Tue, Feb 13, 2007 at 05:17:43PM +0100, Wouter Verhelst wrote: > > Having a record of who voted for whom is a good default. Since we don't > > have any typical real-world election abuses in Debian (e.g. intimidation > > or harming of people who voted for someone you don't like), I see no > > serious negative consequences to publishing the votes. > > "I don't like this person, but I have to work with him in this project, > so I would like to hide that fact from him/her. I don't want to rank > him/her above NOTA, but I also don't want to have to explain that" Okay, that's a good point. I'm not automatically convinced that it's a seriously negative thing, however. This kind of openness can obviously cause some friction, but do we have any real evidence that says it's an insurmountable obstacle? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal text (diff)
On Tue, Feb 13, 2007 at 09:14:27PM +0100, Alexander Schmehl wrote: > > You are aware that most of our elections are done this way, > > Yes, I know. > > > we only use hashes in the tally sheet for leader elections? > > Or in other words: I 100% of the votes regarding persons, we have a > secret vote. Yes, but the sample is still just 1. (Also I don't know the rationale for that, so it's hard to judge it - it could have been fully intentional, it could have been some sort of a CYA measure that was grandfathered in.) Anyway. Let's take any other election as an example. What do we do with people who intensely dislike the option X in an election and takes each vote to the contrary as an insulting statement from those voters, or just takes it personally? One could make the argument that keeping the tally sheet obfuscated is good for any election, because we want to avoid fussing over *anything*. In the end, does it really avoid people fussing over things, or does it really just obfuscate the fussing, from 'evil people A,B,C voted against me!' to 'three evil people voted against me!'? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal text (diff)
On Tue, Feb 13, 2007 at 07:39:12PM +0100, gregor herrmann wrote: > > > > + If there are fewer than S2 candidates > > > > + at the end of the nomination period, then the nomination period is > > > > + extended for two further weeks, repeatedly if necessary. > > > > + If "None Of The Above" wins the election, or if fewer than S2 > > > > + candidates win over "None of the Above", the election process is > > > > + repeated. > > > How often should the nomination period and the election process be > > > repeated? I'd suggest to include some maximum otherwise they could go > > > on ad infinitum. > > You can see similar rules in other parts of the constitution, see 5.2.4, > > 5.2.6. > > I think there's a huge difference between "no candidates" (5.2.4) and > "fewer than S2 candidates" in your proposal, and between "NOTA wins" > (5.2.6) vs. "fewer than S2 candidates over NOTA". > > In other words: The threshold is much higer (16 vs. 1 AIUI) and it's > much easier that it won't be reached. > > And the regulations in the Constitution seem logically necessary: If > there is not a single candidate or a single winner there has to be > some "else case" whereas your S2 boundary is arbritary (which is not > bad in itself but it could be any other value too). > > > Do you think it's likely for it to go on for more than one repetition? > > I've no real idea but it might lead to a dead end. And having > infinite nominations/elections because there are e.g. "only" 10 and > not 16 persons seems to defeat the whole idea. (Just a note - my S2 boundary isn't really arbitrary, it's basically a function of the quorum.) I have pondered this previously, but I decided to have a try like that still. If we allow the bar to be dropped arbitrarily down from the quorum-based quota, then how do we decide how many are sufficient and how many are not? E.g. most people will think that a re-vote isn't worth it if we get 15 rather than 16, many will think it's not worth it if it's 10 rather than 16, but what if one day it's 10 rather than 23, and at the same time we get a three times as large a turnout, meaning we are sampling a much larger interested population? Where do we put the threshold? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal text (diff)
On Tue, Feb 13, 2007 at 11:59:06PM +0100, gregor herrmann wrote: > > > > Do you think it's likely for it to go on for more than one repetition? > > > I've no real idea but it might lead to a dead end. And having > > > infinite nominations/elections because there are e.g. "only" 10 and > > > not 16 persons seems to defeat the whole idea. > > (Just a note - my S2 boundary isn't really arbitrary, it's basically a > > function of the quorum.) > > (Point taken but it's still a deliberate decision to say > count($members_of_soc_ctte)=round(Q).) (I was just correcting the adjective used - "arbitrary" isn't the same as "deliberate" :) > > I have pondered this previously, but I decided to have a try like that > > still. If we allow the bar to be dropped arbitrarily down from the > > quorum-based quota, then how do we decide how many are sufficient and > > how many are not? > > I don't have an answer ready but IMO S2 (or Q) is not more magical > then 5 or 13 or 42. > > I guess at the end the size of the committee should: > * depend on its goals and tasks > * allow the group to work as a _group_ > > (The other question is of course what happens if there are not enough > candidates/winners. Maybe an (equally arbitrary) minimum size for a > second round could be defined?) I've discussed in the previous thread why I thought 1000->16 or 2000->23 were decent; but that was more in light of an upper limit, rather than a lower limit. Only when I started writing the exact rule into the constitution text did I realize that there lower limit needs to be thought about :) If there is a serious doubt whether we would be able to elect that many people in less than two rounds of elections (a second round would be bearable; a third would be a real bother) then I would have to be leaning towards either: * Allowing a variable number of members, to a point. I was originally thinking that a fixed size needs to be set in order to have a clear understanding of what the membership in the ctte means; also adding variability adds more nuance into the constitution definition so it's harder to write. * Or cutting the fixed size further down, but that sounds like a workaround. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Criteria for a successful DPL board
On Mon, Feb 12, 2007 at 11:00:36AM +0100, Raphael Hertzog wrote: > Composition: > > * Around 10 members representing if possible the various tendencies that > exist within Debian. One thing that needs to be clarified is the explanation of this number of members. There are several kinds of problems you are trying to address there, let me try to break it down into parts: * the possibility that N is better than 1 * whenever that sole person is bogged down with , simple redundancy might allow someone else to react instead * whenever that sole person is sufficiently perplexed about an issue, more eyes on the problem might help clarify what should be done * the possibility that N+M is better than N * whenever the 'standard' set of people handling matters become less effective or ineffective for whatever reason, the extras kick in If I missed anything major, please add :) Now, conventional wisdom says that optimal teams (that's teams rather than just groups) are composed of 5 or 7 people. Your ten people would mean that we have 5 or 7 people as N, and another 5 or 3 people as M. Now, I don't think that any of the above points are investigated in the project, neither qualitatively nor quantitatively. Some semi-obvious complaints would be (broken down analogously): * N isn't necessarily better than 1 * simplistic redundancy leads to a dispersion of responsibility, so you might actually end up with nobody 'picking up the torch' * more eyes might add more confusion to the issue rather than aid clarification * N+M isn't necessarily better than N * the extras aren't necessarily available or suitable for ad hoc inclusion into the process Yet, I think we've long had enough of the initial option (having 1 leader), and the most recent couple of attempts show that there is a general will to go ahead with changes. > * Ultimately, this might mean that the board should be fully elected. > However this is not going to happen this year since it requires > constitutional change. I'd rather try first and make the change during > the course of the year, even I can prove that the DPL board is a good > principle. That's why I'll try to have a diversified board. This has the semi-obvious pitfall of conflating the eventual success or failure of the proto-board with the prospect of the idea of an elected board. Because of the reasons said in my last two sentences, I think it's actually a good time to go with the 'high road' there. We need to start figuring out a way to elect a leadership rather than a single leader. Now is as good a time as any, given how we all know how we collectively take a lot of time to decide things. I would lean towards separating the aspect of good representation from the aspect of good leadership. The former can and should be left to the proposed social committee - over there it's a crucial aspect (IMO), and over here it's a bonus that can be worked around. To be clearer, let me give two different examples: * A larger leadership team is elected, and this set of >5 people turns out to include various candidates who have various opinions. As they form a leadership team, these opinions escalate into internal disagreements. The team starts deciding things based on internal discussion, which is probably a representative set of inputs to begin with, but this discussion isn't necessarily useful, because it looks more like a quarrel and ends in a vote that can well tend to be contentious. * A smaller leadership team is elected, where people are elected on a joint platform or mutually supported ones. They can still have various opinions, but they don't differ as much. As they form a leadership team, they start to 'click' better. The team starts deciding things based on internal discussion, which is more monotonous. The team depends on general population input in order to argue for different opinions (those which are not held by any of the members of the team). In cases where the situation warrants it, this team ask the soc-ctte for opinion on wide-reaching issues (those that require more input and more consensus, rather than more expedience). Both of the above ideas have other pros and cons: In the first case, election is easier, because we just scoop off the top >5 on the vote result, and throw them in; in the second case, the election is tricky, because how do you regulate nuances to make sure no incompatible people are thrown together? In the first case, you get a better sampling due to more people, but you also get all the problems that redundancy brings; in the second, you skip most problems with redundancy, but also lose if a common problem plagues the whole team (e.g. if most go AWOL simultaeously). In the second case, how do you trust the team to call upon the committees sufficiently and appropriately, and how do you expect them to make a proper decision based on that input? Conversely, in the first case, h
Re: Criteria for a successful DPL board
On Sun, Feb 18, 2007 at 08:34:09PM +0100, Raphael Hertzog wrote: > > Now, conventional wisdom says that optimal teams (that's teams rather than > > just groups) are composed of 5 or 7 people. > > I don't think we'll have any problem as there's no real limiting factor. > When you handle very simple tasks, only one can do it at a time and having > more only lead to troubles. However when most of the expected work is > "discussing issues" and "taking decisions" I don't think that the number > is a problem, but rather an advantage. I think it is, because there will always be a few people demotivated by a too large group. They will feel that their voice makes no difference, and/or that someone else is probably going to voice the same opinion as they would, so they won't participate. Of all the cliches in today's popular psychology :) I've actually seen this one to be true in the real world. :/ > One of the key points that is interesting in the board that I propose, is > the principle of 'discussion by proxy' so we really need some diversity in > the board otherwise the decisions may be too far from the real consensus > of the project. > > If the board wants to be successful leading the project, it will have to > take decisions instead of letting ambiguous situations continue forever, > but those decisions must match as closely as possible what the project > would have decided by himself via a GR. > > That's why I think we can lead even with diversity in the board. I'm not convinced, because letting ambiguous sitations continue forever has been sort of a norm so far, in part because the ratio was 1000:1; if we just improve that to 1000:10, that in itself doesn't necessarily fix the problem; but the *right* 10 (or 3 or 5) might. > > In the first case, election is easier, because we just scoop off the top > > >5 on the vote result, and throw them in; in the second case, the > > election is tricky, because how do you regulate nuances to make sure no > > incompatible people are thrown together? > > Yes, this is really something problematic, in particular when the DPL > elections tends to always interest one or two candidates which are known > to have problems within the community. On the other hand, it's easy to > rank them below NOTA... and we can decide that the candidates must be > acceptable to 70% of the voters (so they should not be below NOTA more > than 30% of the votes). That also has a problem with leading to a deadlock, you'd need a strategy for working around that. > > So, I'm thinking a compromise on the second case should do the trick: > > * elect the top-leader as the first on the vote tally, regardless of > > platform > > * have a 3- or 5-member leadership team, selected by the top-leader > > but composed from the rest of the winning vote tally, where by "winning" > > I mean those top 3 or top 5 who win over NOTA > > it's not clear how the top-leader select here... how can you choose 3 > other out of the top-3 of the other candidates ? There's no choice to do > in that case... If there are only 3 who win over NOTA, then the top-leader only has 2 to choose from :) > > * this selection must be based on a public pre-vote and post-vote discussion > > on platform compatibility, with veto rights by someone, maybe secretary? > > I like the principle of the top-leader with the tie-breaker vote. I don't > think that he should select the other members of the DPL board however, > but we must make sure that the other members are able to work in teams. I > think that the above-NOTA quorum could be used to ensure that. The above-NOTA quorum will give you generally acceptable candidates, but that alone is not a guarantee that they will mutually get along good enough to be a good leadership team. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Criteria for a successful DPL board
On Mon, Feb 19, 2007 at 10:32:40AM +0200, Kalle Kivimaa wrote: > > * have a 3- or 5-member leadership team, selected by the top-leader > > but composed from the rest of the winning vote tally, where by "winning" > > I mean those top 3 or top 5 who win over NOTA > > * this selection must be based on a public pre-vote and post-vote discussion > > on platform compatibility, with veto rights by someone, maybe secretary? > > Why make this so difficult? Why not let the candidates indicate in > their platforms who their team would consist of? That way the voters > would know at the vote time, not afterwards. This type of election is > pretty common in Finland. Like I said, pre-vote discussion would do... I wouldn't make the pre-choice mandatory because it can always happen that people change their minds after election... hm. Maybe that's actually a good rule. But it might narrow down the number of candidates and pose quorum issues. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: BREAKING NEWS: Debian developers aren't trusted
On Fri, Feb 23, 2007 at 12:25:51PM +1000, Anthony Towns wrote: > > > Are you so overworked, or are you deliberately "forgetting"? It has > > > been suggested multiple times in the past to use existing or new > > > hardware and add it to the set of standard autobuilders. Many arches do > > > not meet the redundancy requirement, > > Um, the only archs that don't meet the redundancy requirement today are i386 > > and ia64. > > http://release.debian.org/etch_arch_qualify.html says alpha, amd64, arm, > hppa, i386, ia64, and m68k don't meet it, fwiw. While you're at it, vore.debian.org, which is listed the sparc porting machine, is down, and has been for a while, and this is recorded at http://db.debian.org/machines.cgi?host=vore (BTW, I've recently offered a better sparc machine for use by the project, it's a prospective solution for that problem.) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Fri, Feb 23, 2007 at 12:13:03PM +1000, Anthony Towns wrote: > I think they contribute /better/ if they aren't closely supervised. > I think that's seen some results over the past year, including much > improved spam protection for debian.org addresses, Er, we now have implemented measures that are actually years old. That's certainly a result, but it's not really a *good* result, because a lot of time was wasted. > a new and much faster ftp-master along with two dinstall/britney runs a > day I'm not acquainted with the specifics, but if the hardware upgrade brought on a much faster service, then that's also a result that is certainly a result, but not a *good* result, because it could have been achieved years ago. So, to go back to something that you started with... > I think it's worth recognising that when we say we're not doing a good > enough job, *we* are still the ones setting and raising the bar. ...there was no bar-raising being done there, only lowering. :| And I would argue that this happens *because* there is little real accountability and/or supervision. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: BREAKING NEWS: Debian developers aren't trusted
On Sat, Feb 24, 2007 at 04:03:59PM +0100, Bastian Blank wrote: > See this list some time ago. Debian have a Sun T2000 available. Oh yeah, I noticed, but it also sounds like we're not really using it. That needs to be fixed. Besides, redundancy is good, esp. given that vore is down. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why is there only self-nomination?
On Thu, Mar 01, 2007 at 10:39:11PM +0100, Luk Claes wrote: > Personally, I think the idea of a DD having to ack his nomination, though > only after being nominated by some (Q?) fellow DDs would be better than a > plain self-nomination. What do others think? You don't want Q, Q is too much, it's 15/16 now. I think it's unreasonable to expect someone to get fifteen votes before the voting has even started. A requirement of 1, 2 or 3 seconds would be good. For example, we have one NM advocate already, and a requirement for voting proposals to get five seconds, and that works out all right. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why is there only self-nomination? [Re: Expulsion process: Sven Luther]
On Fri, Mar 02, 2007 at 10:30:53AM +0100, Thijs Kinkhorst wrote: > > Personally, I think the idea of a DD having to ack his nomination, though > > only > > after being nominated by some (Q?) fellow DDs would be better than a plain > > self-nomination. What do others think? > > What would be better about it? I haven't seen any concrete problems yet > with the nominations. Last year (i.m.o.) a troll has nominated himself, > but he was convincingly voted down. > > What concrete problem would this solve? Too many corner-case candidates hogging the ballot, hogging the list of platforms that voters need to read, hogging the discussion, ... I'm not saying that this happens already, but it could. In the soc-ctte proposal, there will be a one-seconder requirement because there it will inevitably be a problem, the ballot-cramming. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Tue, Mar 13, 2007 at 01:09:12AM +0100, Frans Pop wrote: > So, basically my question remains: why does it have to be so incredibly > difficult to allow new members into these teams? Probably because fixing them requires spending a sufficient number of man-hours and a substantial amount of will power, enough so that properly fixing them always gets ranked in the "we can do it later" category. But anyway, it doesn't really matter, I shouldn't rant here, there's no point. There should simply be no more question marks; that sentence should be rephrased into "It does not have to be so incredibily difficult to allow ...". > I have no problem with development work being funded, but an organization > that is founded on volunteers should be able to maintain its core > infrastructure using those volunteers. About this point... I'd mention that we could ponder reimbursing people for doing something either particularly intensive or particularly menial. But anything like that should only happen once we get past the whole unclogging phase. (Although I would actually ponder reimbursing an existing debian-admin for their time going through three dozen machines running visudo, that is just tedious :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: DSA and buildds and DAM, oh my!
On Fri, Mar 16, 2007 at 12:53:52AM +, Steve McIntyre wrote: > >IMO setting up an RT system will not fundamentally solve any of this, but > >will at most make it more manageable. The only way to solve this is by > >having new blood in the teams, people who will take on the most boring > >and routine tasks with enthusiasm because it is new and who bring fresh > >ideas and the energy to implement them to the teams. > > The idea behind the RT setup is to help us on the way to growing the > teams. It might sound unlikely to some, but I'm told there have been > problems in the past with people tripping over each other when trying > to work on tasks. We have multiple volunteers who want to help out; as > more people come on board who may not have worked together in the > past, the probability of coliisions grows substantially. That's one > place where RT will help. It will also allow people to keep better > track of what jobs have been requested and help in terms of feedback > to the requestors too. It's not a magic bullet (we all know that), but > it should help. IMO the best effect of a request tracker will be that it will help document the typical workings of the team, and that way help any new members get acquainted with what needs doing and how it gets done. Poor man's documentation, if you will, but actual documentation nevertheless. The collision handling by 'taking' tasks in the request tracker prior to doing them is a nice idea, but, it's neither a particularly convenient solution (people tend to hate administrivia), and fortunately the problem is not such a show-stopper (the task still gets done, even if a few more man-time-units are wasted). -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: notable Debian contributions in 2006
On Sat, Mar 24, 2007 at 02:08:10PM +0200, Tshepang Lekhonkhobe wrote: > Distors are often viewed as mere packagers, but they tend to drive > upstream development in variety of ways. Here's just a few of Debian's > contributions to the world of FLOSS during 2006: > > * creation of cdrkit, a fork of cdrtools, due to a change of licence > which happened to be DFSG-incompatible > * rebranding of Firefox to Iceweasel due to trademark issues > * rebranding of Seamonkey to Iceape due to trademark issues > * rebranding of Thunderbird to Icedove due to trademark issues > > There must be so much more, in which case I hope you may add to this > list, and if there's enough contributions, maybe a wiki page could be > set up and advertised. You have your priorities wrong. A fork and three rebrandings are more like nuisances compared to for example the bug reports that Debian maintainers forwarded to upstream, without or with fixes. Sure, maybe those aren't PR-friendly, but they count, and they are the heart of our contribution IMO. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian 4.0 finally arrives... does anyone care?
On Fri, Apr 13, 2007 at 11:08:44AM +0200, Adrian von Bidder wrote: > We're telling people that they can/should use Debian, and 5 minutes later > I have to explain [...] I sense a bit of frustration in here :) but it's not really necessary. I mean, you also have to explain people why we e.g. don't have Excel on Debian, and we actually *don't* have it. There are numerous things to have to explain, and a simple s/Firefox/Iceweasel/ rename is perhaps one of the most trivial of them all. Some people like to obsess over trivialities, such is life, let's move on. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Some thoughts on the ARM build daemons
On Tue, May 08, 2007 at 12:02:50PM +0100, Wookey wrote: > I'm not sure money is the issue - it appears to be DSA set-up time. > New hardware has been offered, many months ago, and is there, ready, > online, but (so far as I can tell) it has not been brought into use by > the people with the power to do it (DSA and arm build-admin). > > http://lists.debian.org/debian-arm/2006/11/msg8.html > > I don't know who is waiting for what, at this stage. That reminds me of sparc... where vore is dead since late 2005 (at least), but at least two live hardware offers are being ignored for months (live as in machines are online and waiting to be used). It's not like anyone really cares, as long as the remaining machines provide the modicum of functionality, but you'd expect at least the courtesy of a response. Oh, wait, no, you can't really allow yourself to expect a response, because that would break a long-time pattern of d-a member behaviour. And we can't have such silly things happen, can we! -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Change of the debian code-name base?
On Sat, May 26, 2007 at 04:06:30PM +0200, Torsten Trautwein wrote: > to ask if it was possible to change the naming resource from Toy Story > to The Simpsons? Frankly, I think that both are fairly corny. If we are to change, we should make a more meaningful change. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social committee proposal
On Fri, Jun 01, 2007 at 10:39:53AM +0100, Ian Jackson wrote: > NB that such a committee does not need to be consititutionally > established. The DPL's existing powers are sufficient to establish > it. A big advantage to not establishing the committee > constitutionally is that we don't need to worry so much about it > overstepping the mark, so we do away with the checks and balances that > hedge (for example) the TC's powers and processes. After all, as the > DPL's delegates, the social committee can be overruled by a GR if it > were necessary. [...] I don't quite get the idea of having a delegation where delegates are voted upon. Imagine a conflict situation later - the leader can veto their decisions, change charter, or even undelegate the whole thing. Doesn't that contradict with the idea that those five people were elected to do the said job? What's the point of electing people if they're not going to be allowed to do anything that the leader doesn't like? Why not just let the leader name them himself, and be done with it? Also, I can already see opposition to a committee which is only elected once, and can then change its own membership at will, while retaining all of its the powers that the originally elected members were given. That simply sounds evil. I still think that we should organize a proper GR to put a basic framework into the constitution, and then vote on the members regularly. Social committee would deal with "mere" social matters, but we appear to have ample precedent by now to indicate that such matters are sensitive enough to need checks and balances. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Two GR concepts for dicussion
On Thu, May 31, 2007 at 06:37:53PM +1000, Anthony Towns wrote: > Another thought. Sam's written about having more people in our core teams > a few times, and no doubt will have more to say in the future; but a > single person can only focus on helping one or two teams at any one time, > and there's no limit to the number of teams that can have problems. s/can (have problems)/will at some point $1/ > Maybe it's worth thinking about a more general solution than DPL > intervention for helping teams that have calcified to grow and improve. It should be noted that DPL intervention hasn't really been a solution so far, only a option that nobody ever utilized. That's TTBOMK - someone correct me if I'm wrong. > My idea was to have an annual round where any DD could nominate themselves > to join any team -- DSA, ftpmaster, maintenance of some particular > package, www team, whatever. Acceptance would be automatic, provided: > > * no more than three people are joining the team (if so, > the existing team can select three, or the DPL can if the > existing team don't) > > * the role isn't "core", or the person isn't already involved > in two or more other "core" roles (eg, ftpmaster assistant isn't > core, ftpmaster is; release assistant isn't, release manager is) > > * the person can demonstrate some minimal existing competence > in the area > > * the person is willing to agree in writing to make every > reasonable effort to work with the existing team (which the > DPL will enumerate on request) > > (That's intended to be in *addition* to the existing members of a team > finding people to join in and help, not instead of it.) To avoid the impression that this is something correlated with DPL elections, and to give people more time, maybe it's best if it's done every two years rather than ever year. Or, even better, let's mix it up to have something more useful: * prospective members can nominate themselves every four months (avoids having to wait 2/3rds of a year, but also avoids people annoying the team with repeated applications) * any candidate has to pledge a minimum 18 months availability to the team - to avoid people nominating just for kicks, giving up after a few months, and essentially wasting team effort spent for training them * each team can decide during every such nomination round to accept a candidate, but it doesn't have to accept more than three people every two years * teams have to decide to mark old members who practically went away (aren't participating a lot) as latent, but can unmark them as such every four months * latent team members count for 50% of an empty seat That would be a bit conservative (but much more liberal than today), and it sounds to me like it's viable. It wouldn't necessarily have to be strictly obeyed, i.e. we don't need to carve the exact verbiage into the constitution; the teams can have some leeway, when I say four months I really don't care if it's 4*30 days or 4*29.57 days. I think it's fair to expect that people will observe the general spirit of General Resolution as voted and published on vote.d.o, and not try to horribly contradict it. For reference, we haven't had new member of the debian-admin team in 5.5 years now[1], or a new member of the webmaster team in 2.5 years[2]. These two teams are certainly different and have different helpers and circumstances and all, but both have been brought up in a recent -devel discussion so I'm mentioning their raw numbers as two relevant data points. Under this kind of a scheme, I think that there would have been a fair bit of new blood accepted during that time, even under this conservative scheme. At the same time, there wouldn't be an inappropriate burden on existing team members in order to accept a major influx. [1] the last addition was first documented in http://cvs.debian.org/webwml/english/intro/organization.data?root=webwml&r1=1.65&r2=1.66&diff_format=h but it could have been even longer since then [2] http://cvs.debian.org/webwml/english/intro/organization.data?root=webwml&r1=1.158&r2=1.159&diff_format=h > That has two major prerequisites in order to work: that we're *all* > willing to give up some of the control we're used to exercising over our > domain within Debian (whether that be a package or some infrastructure > or a role or whatever); I think it's worth mentioning at this point that infrastructure teams were never supposed to be (benevolent) dictatorships like package maintainers. Individual packages have to 'click' together with the rest of the system, and on a grand scale, they are a common responsibility of us all, but project infrastructure is nothing else other than a common responsibility of all, there is very little room for having it not 'click' right. So while it's reasonable to expect package maintainters to give up some dictatorship prerogative, it's reasonable to expect inf
Re: Two GR concepts for dicussion
On Sat, Jun 02, 2007 at 05:12:12PM +0200, Frank Lichtenheld wrote: > > * any candidate has to pledge a minimum 18 months availability to the team - > > to avoid people nominating just for kicks, giving up after a few months, > > and essentially wasting team effort spent for training them > > I wonder how you would like to enforce that? Or is this more about > at least publicly giving that pledge? It would be a matter of honour, yes... But like I said, it should serve primarily as a deterrent for people who can't make a reasonable commitment. I don't expect a particular need for penalties for those who don't manage (the teams will demote them to latent members or remove them, on a case by case basis). > Also I think teams very much differ in how long you have to be in them > to make a difference. E.g. the release team has a much shorter > time-frame (IMHO). Well, from the point of view of effective decalcification of teams, that's not important. Even if the main product of the team gets made in a much smaller time period, and even if someone stops actively participating soon-ish, chances are that after a couple of years the tasks will still be similar and that there will be new members who need to be taught the job. Rather than divesting from the current effort by taking the time of more active team members so that they can help the newcomers, you want to have existing team members who learned the stuff to stick around and help out. (This reminds me of grandparents in real life... :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social committee proposal
On Mon, Jun 04, 2007 at 11:05:02AM +0100, Ian Jackson wrote: > > I don't quite get the idea of having a delegation where delegates are > > voted upon. Imagine a conflict situation later - the leader can veto > > their decisions, change charter, or even undelegate the whole thing. > > Yes. But in practice the DPL rarely exercises that authority. This > puts the SC on the same footing as the ftpmasters, release managers, > etc. etc. etc. Well, if you imply that the DPL wouldn't use that authority to curb an SC which was once elected but has since run amok, isn't that an even worse? :) > This latter is an important point: if the SC members are elected, > their mandate - ie, their support from the Developers - is clearly > established. > > People could complain that their robust style was being stifled by the > majority but after all that is the whole point: to `stifle' the > `excessively robust style' (ie, flames and other crap). At least they > won't be able to claim `the lurkers support me in email', `it's only a > junta which is deciding this' and so on. Good. Now that you have established all these reasons why the soc-ctte members should be properly elected, why not have their legitimate election be their right to exist, rather than the DPL's delegation? :) > It seems to me that one election will probably be sufficient to make > the general views of developers clear. But if not the SC has the > ability to request further elections, and if the DDs think it should > but the SC won't then a DPL decision or GR can force an election or > abolish it. Having regular elections would greatly contribute to a sense of accountability, and it would be a decent guarantee that the clarity of the general views of developers is maintained over time. That's both among the soc-ctte members and among the rest of the developers. For these reasons, I think it's best if it's set up like that in the first place, rather than having later elections optional. > > I still think that we should organize a proper GR to put a basic framework > > into the constitution, and then vote on the members regularly. > > Firstly, the SC is an experiment. It should be able to change the way > it works in response to how things go - and the DPL should be able to > do likewise. > > Secondly, entrenching the SC is daft. The SC has no powers that the > DPL already doesn't. Do you think that the DPL and Delegates' power > to (for example) ban people from mailing lists should be abolished ? > Are you proposing that the DPL and and the SC should have overlapping > powers ? If you go back to the original soc-ctte thread, you will notice that we already discussed the extent of the soc-ctte powers. Nobody actually proposed measures as concrete (or as harsh) as you did, to be put into the constitution. It was fairly clear that there would be multiple options on the ballot, for people to choose between several options of various 'softness'. > Note that the existing arrangements for dividing jurisdiction between > the TC and the DPL don't always work very well. Often we end up > arguing about jurisdiction, although this may be because the TC is the > only non-dysfunctional mechanism we have for resolving general > disputes between developers, so it gets the social disputes as well as > technical ones. Yeah. (Would you mind quoting an example or two, so that we're in the clear about what exactly is meant?) > > Social committee would deal with "mere" social matters, but we appear to > > have ample precedent by now to indicate that such matters are sensitive > > enough to need checks and balances. > > The SC has _fewer_ checks and balances if it is entrenched in the > constitution. With my proposal, the SC can be overruled by the DPL or > GR. This means that if the SC is going off-course the DPL can have a > quiet word. I'm not sure that I like the idea of solving matters by having a quiet word between someone who was elected but has a stick, and people who are just elected. And the prospect of leader intervening into the committee certainly won't help with all the Cabal(TM) talk... > If the SC is entrenched then (a) how do you divide controversies > between DPL and SC and (b) who can overrule the SC ? Well, I guess I have to refer you to the previous long thread, the one started on January 25th with Message-ID: <[EMAIL PROTECTED]> In short, and if I remember correctly, the previous proposal was that the soc-ctte first decides whether a matter is a social matter, i.e. whether they feel they should deliberate on it. If they decide so (and there was an internal voting mechanism specified), they take on the issue; if they can't decide if it's technical or social, they defer judgement to the technical committee. I don't think anyone seriously recommended that a social matter can be better decided by the leader, do you think we could have such matters? Note that we could still have that by way of soc-ctte asking the leader to decide inste
hosting offers
Hi, In a recent discussion on the -sparc list, it turned out that we seem to have something of a habit of getting hardware offers, but not knowing exactly what to do with them :) The matter of shipping hardware and the associated cost always comes up. I don't think we've footed the bill for shipping hardware very often, because of a known fact, or at least widely held opinion, that it's very expensive. But a more important matter is that we may not have to ship things very far or so very expensively if we know exactly where we can send them, and if the cost is calculated based on a wider set of options, rather than whatever is known by a handful of people discussing a specific offer. We don't seem to have any sort of a list (database) of available hosting offers. Maybe it would be worth setting up a separate (archived) mail alias @d.o and then tell people that they can send information there. That would be a start, at least. We could then tell people to send information there, it wouldn't be made public (because various details of hosting offers can be private), and they could tell us which kind of stuff they can take, how much of it, what's the long-term prospect of keeping it, who would take care of it on site, those kinds of things. As far as concrete problems, I'll note two things: * debian-admin should have received a fair few offers back when they posted a public call for hosting of those two machines, so if that info can be collected and verified again, it should be a useful chunk of the list * I am of the opinion that if we get charged e.g. 750 USD for shipping a large box overseas or something like that, that sounds expensive, but if the overhead of finding a specific machine and getting it to the right place is large and takes a lot of time to get it online in a decent setting, so large that nobody actually wants to bother, and no progress is made, then those 750 USD were not worth saving. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Committee proposal text (diff)
On Tue, Feb 13, 2007 at 11:26:58PM +0100, Josip Rodin wrote: > > > Having a record of who voted for whom is a good default. Since we don't > > > have any typical real-world election abuses in Debian (e.g. intimidation > > > or harming of people who voted for someone you don't like), I see no > > > serious negative consequences to publishing the votes. > > > > "I don't like this person, but I have to work with him in this project, > > so I would like to hide that fact from him/her. I don't want to rank > > him/her above NOTA, but I also don't want to have to explain that" > > Okay, that's a good point. I'm not automatically convinced that it's a > seriously negative thing, however. This kind of openness can obviously > cause some friction, but do we have any real evidence that says it's > an insurmountable obstacle? Resurrecting this old thing for another question that came to me now - would it make sense to postpone the publication of votes in soc-ctte elections? Like, publish the list of voters after a year or two? By that time, time itself should have eroded much of the problem... -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Social Committee proposal text (diff), updated
Hi, I went back and examined the thread that started with Message-ID: <[EMAIL PROTECTED]> in February, and came up with the following diff at the Constitution. The changes from the last version include: * replaced the somewhat confusing 'day-to-day' reference * added section 'Intervene in communication processes in matters of common interest.', summing up Ian's recent proposal, but genericized, and linked (warning must precede action), with the primary example * noted joint technical+social disputes in relation to tech-ctte and leader * added example for lending authority * added example for overriding a developer * limited nomination period repetition * postponed publicizing votes * clarified that there is a list of winners, removed confusing NOTA requirement (it was in the wrong section) * allowed the list to be smaller than sqrt(N)/2 * limited senior criterion, both relative and absolute * slightly reduced the senior quota * described multiple winners procedure in the Standard Resolution Procedure, with the handling of multiple winners being inclusive The diff is attached (for the benefit of those like me who have syntax highlighting :). -- 2. That which causes joy or happiness. --- constitution.wml 2007-02-12 01:49:13.0 +0100 +++ constitution+soc-ctte.wml 2007-06-05 01:08:50.0 +0200 @@ -34,6 +34,8 @@ The Technical Committee and/or its Chairman; + The Social Committee and/or its Chairman; + The individual Developer working on a particular task; Delegates appointed by the Project Leader for specific @@ -64,7 +66,8 @@ A person may hold several posts, except that the Project Leader, -Project Secretary and the Chairman of the Technical Committee must +Project Secretary, the Chairman of the Technical Committee +and the Chairman of the Social Committee must be distinct, and that the Leader cannot appoint themselves as their own Delegate. @@ -142,6 +145,11 @@ Committee, provided they agree with a 2:1 majority. + +Make or override any decision authorised by the powers of the +Social Committee. + + Issue, supersede and withdraw nontechnical policy documents and statements. @@ -193,7 +201,8 @@ If the Project Leader or their Delegate, or the Technical - Committee, has made a decision, then Developers can override them + Committee, or the Social Committee, has made a decision, + then Developers can override them by passing a resolution to do so; see §4.1(3). If such a resolution is sponsored by at least 2K Developers, @@ -203,7 +212,8 @@ If the original decision was to change a discussion period or a voting period, or the resolution is to override the Technical - Committee, then only K Developers need to sponsor the resolution + Committee, or the resolution is to override the Social Committee, + then only K Developers need to sponsor the resolution to be able to put the decision immediately on hold. If the decision is put on hold, an immediate vote is held to @@ -263,11 +273,11 @@ Appoint Delegates or delegate decisions to the Technical -Committee. +Committee, or delegate decisions to the Social Committee. The Leader may define an area of ongoing responsibility or a -specific decision and hand it over to another Developer or to the -Technical Committee. +specific decision and hand it over to another Developer, or to the +Technical Committee, or to the Social Committee. Once a particular decision has been delegated and made the Project Leader may not withdraw that delegation; however, they may @@ -737,6 +747,246 @@ that includes the commitments those organisations have made as to how those assets will be handled. +10. Social committee + +10.1. Powers + +The Social Committee may: + + + +Decide on any matter of social policy. + +This includes social norms and customs, non-technical communication +among developers, and general matters of organization within the Project. + + + + +Decide any social issue where Developers' jurisdictions +overlap. + +In cases where Developers need to implement compatible +social policies or stances, the social committee may decide the +matter. + + + +Make a decision when asked to do so. + +Any person or body may delegate a decision of their own to the +Social Committee, or seek advice from it. + + + +Offer advice. + +The Social Committee may make formal announcements about its +views on any matter. +Individual members may of course make informal statements about +their views and about the likely views of the committee. + + + +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. Such requests, exp
Re: Social Committee proposal text (diff), updated
On Tue, Jun 05, 2007 at 07:38:24PM +0100, Ian Jackson wrote: > * Josip models the SC's powers on those of the TC. This is wholly >inappropriate because the questions that the SC is required to deal >with are very different. I guess it doesn't make sense to argue much about this, but I have to point out that that's tech-ctte is the best example we've got so far. Maybe it's not perfect, but it's a start. The social committee shouldn't start off being particularly radical. > * Josip's text emphasises the SC's role as a writer of policies. >We do not need policies, we need admonishment and if necessary >enforcement of good conduct. Uhh, I am not sure where you got that. Did you miss the part that said: +No detailed mediation or policy-making. + +The Social Committee does not engage in design of new +proposals and policies. Such design work should be carried out +by individuals discussing in ordinary social forums. Like you said yourself, this is modelled after tech-ctte. > * Josip's text depends heavily on the meaning of the word `social' >which I think is vague to the point of uselessness and will >lead to jurisdictional disputes. Jurisdictional disputes between whom? And, given my proposed rules for deference, exactly how bad can they be? At least if we get to see such a dispute, then we can resolve it and clarify the vague terms. Right now we have... nothing. > The answer is obvious: we want the SC to impose mailing list bans (and > IRC bans and wiki bans and so forth). That single power is enough to > do everything that is lacking, because together with the threat and > expectation of its exercise, the SC can enforce good behaviour. There's a subtle point we're glossing over here - we don't need a body whose ultimate purpose would be to enforce good behaviour. Enforcing good behaviour, once "good behaviour" is defined, is not a particularly contentious idea, it's something we can leave that task to the teams that administer services (public forums in this case). We need a body which considers arguments and decides which nuances of behaviour are acceptable. Or it *doesn't* decide on some nuances. The social committee has to assist in building a consensus, because too much strict delineation doesn't necessarily do much to help the society. It shouldn't be a priori limited in scope (to mere production of decisions and their enforcement). > For these reasons, the powers and processes adopted by the SC and > those adopted by the TC ought to be very different. The SC should be > able to intervene in a public conversation even if neither participant > is upset - because the SC is supposed to be keeping the venues useable > for everyone. The SC should usually be able to act informally, and it > should normally do so privately and quietly. I see little to support the notion of a) preemptive action b) private interventions being something the community would instantly start preferring. We can't go from public flamewars to private pats on the back. I doubt that this would have worked ten years ago, let alone today. > Now, onto the question of policy. Josip's draft suggests that the SC > should be in charge of writing social policies and seems to me to read > as if that is going to be a primary activity of the SC. Again with this suggestion... how did you get to that conclusion, and at the same time point out that it's a search&replace on tech-ctte text? :) > We don't need a definition of arseholeness. Oh, yes we do. There isn't a single definition of arseholeness that all one thousand developers will agree upon. (There is barely a single definition of *anything* that covers all 1k developers, and more in the future.) > The problem of argumenents in the TC about whether something is > `technical' or not is already bad enough (although this is partly > because we don't have a way not to have the rudeness arguments come to > the TC). But at least `technical' actually means something. It will > be impossible to agree what `social' means. I can't say I see a notable difference in vagueness between the adjectives 'technical' and 'social'. In our context, the former refers to applied sciences, and the latter refers to the association of humans. Both of these are fairly general ideas. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social committee proposal
On Fri, Jun 08, 2007 at 01:07:54PM +0200, Andreas Tille wrote: > Well, I don't think it is the best idea to discuss those issues > via mail. I just hope that many people will join > > https://penta.debconf.org/~joerg/events/93.en.html > > which I registered for an open discussion about this topic. I don't see why f2f discussion about this is necessarily better than a list discussion. We want to find a way to get along better in list discussions, but the way of finding that isn't via list discussions... you see where that is going :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
soc-ctte discussion at DebConf7 [was Re: Social committee proposal]
On Fri, Jun 08, 2007 at 10:42:52PM +0200, Josip Rodin wrote: > > Well, I don't think it is the best idea to discuss those issues > > via mail. I just hope that many people will join > > > > https://penta.debconf.org/~joerg/events/93.en.html > > > > which I registered for an open discussion about this topic. > > I don't see why f2f discussion about this is necessarily better than > a list discussion. We want to find a way to get along better in list > discussions, but the way of finding that isn't via list discussions... > you see where that is going :) So, anyway, the discussion was had :) it was moved from the afternoon to the morning, and not many people joined until later in the term, but still, in the end it was a decent turnout, could be two dozen people. Ian said he'll send over his notes, but I'm impatient so I'll have a go :) 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. Sadly, the discussion ended somewhat prematurely, as there was something else scheduled immediately afterwards in the same room, so we had to wrap it up before everything was hashed out. The issues that were touched included: * The scope and jurisdiction of soc-ctte: * We seemed to come to a consensus that soc-ctte and tech-ctte should not be placed in a position where one is subordinate to the other, rather jurisdictional disputes should be resolved by the leader * Jurisdictional disputes should not be allowed to continue ad nauseam, and the committees should not defer to each other to prevent any sort of a ping-pong * In case a complainant disagrees with the leader's decision on the jurisdiction of the dispute, the method of resolution (escalation) is a General Resolution vote * The soc-ctte should not be used as any sort of a vehicle for other possibly desired changes in Debian governance in general (things that were discussed in several other panels at DebConf7), and that it should be a solution only to the social matters, which are a sufficiently huge and blurry area on their own :) * 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) * 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 * 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 :) * 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 * soc-ctte should be authorised to discuss matters such as the expelling of a developer for anti-social behaviour or such, and be able to make an official recommendation to the same effect to the account managers (but this would not be a final decision, it would be overridable by DAM/DPL/whoever) * 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 * The consensus was that the members of the initial soc-ctte all should be voted upon, possibly together with the vote on the establishment, depending on the secretary - Manoj, please feel free to interject here :) * 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
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, 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-c
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 [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), the
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 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: +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: wiki.debian.org: Who's maintaining it
On Fri, Apr 21, 2006 at 01:45:38PM +0200, Frans Pop wrote: > On Thursday 20 April 2006 08:29, Martin Schulze wrote: > > Technically the wiki is operated by debian-admin. For serious > > problems, please drop debian-admin a note. Patches in coordination > > with the python moin wiki maintainer are welcome. Patches that will be > > overwritten when a new version gets installed are problematic, though. > > Thanks, but who is coordinating the wiki as a whole? > Someone should take responsibility for dealing with questions/issues with > the wiki in general, not only its technical side. I just stumbled upon this issue now, when I made my first few meta-contributions to wiki.d.o. wiki.d.o:/srv/wiki.debian.org/ is mainly owned by root, rather than debwww, webwml, or some other user group. Therefore, bug reports on wiki.d.o technically and administratively cannot be filed under the same pseudo-package as www.d.o, because none of us in the web team have jurisdiction over it. This appears to have gone unfixed ever since wiki.d.o was first created, in October 2005 - almost two years now. Also, whatever is low-priority and owned solely by debian-admin tends to decay. debian-admin not paying attention to these things is *all right* - I myself when I sysadmin a machine don't really want to care about upper-level aspects that end-users care about. What is not all right is that nobody else has been delegated the said responsibility. None of the people mentioned in the transition are now involved with maintaining wiki.d.o. jeroen, ivey, js - none of them even have an account on rietz, where the thing is located. In lack of more innovative solutions, I propose that we create a modicum of new input vectors regarding the maintenance of wiki.d.o, with the web team taking some responsibility, in lack of better targets. Requirements: * a [EMAIL PROTECTED] address should be created, which can be pointed to [EMAIL PROTECTED], which can filter spam and then forward to [EMAIL PROTECTED] at first, later to others * wiki.debian.org pseudo-package should be created in the BTS, and have the new address listed as the recipient * files in the aforementioned directory are changed to a new wikiadmin group * js, debwww people, and others get an account on the machine hosting wiki.d.o (rietz) and be added to that group -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: wiki.debian.org: Who's maintaining it
On Sat, Sep 08, 2007 at 12:18:51PM +0200, Josip Rodin wrote: > This appears to have gone unfixed ever since wiki.d.o was first created, > in October 2005 - almost two years now. Hm, here are the user complaints about this: http://bugs.debian.org/352115 "no feedback path given" http://bugs.debian.org/363532 "wiki lacks contact info" Another pearl: http://bugs.debian.org/385797 "Wiki does not have a license" And some other, assorted ones: http://bugs.debian.org/356949 "Please improve styles" http://bugs.debian.org/359116 "InterWiki links not working on wiki.debian.org" (this one might actually be fixed, but no one is there to clean it up) http://bugs.debian.org/363531 "update notifications lack a sane header to filter on" http://bugs.debian.org/437277 "wiki.d.o RecentChanges is broken due to an incorrect comment." http://bugs.debian.org/343319 "superflous characters while searching wiki.d.o" http://bugs.debian.org/362421 "Returns 200 OK for non-existing entires, should be 404" -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: wiki.debian.org: Who's maintaining it
On Sat, Sep 08, 2007 at 08:13:20PM +0200, Raphael Hertzog wrote: > > > Thanks, but who is coordinating the wiki as a whole? Someone should > > > take responsibility for dealing with questions/issues with the wiki in > > > general, not only its technical side. > > > > I just stumbled upon this issue now, when I made my first few > > meta-contributions to wiki.d.o. > > > > wiki.d.o:/srv/wiki.debian.org/ is mainly owned by root, rather than > > debwww, webwml, or some other user group. Therefore, bug reports on > > wiki.d.o technically and administratively cannot be filed under the same > > pseudo-package as www.d.o, because none of us in the web team have > > jurisdiction over it. > > > > This appears to have gone unfixed ever since wiki.d.o was first created, > > in October 2005 - almost two years now. > > I recently asked James Troup about the opportunity to delegate the wiki to > someone external to DSA and he wasn't really interested, pointing out that > DSA hadn't received that many requests concerning the wiki. Probably because nowhere on the entire Wiki does it actually say where to send feedback to. Which is a great tactic to avoid getting that many requests, really ;) The closest that I could find was http://wiki.debian.org/WikiAdmins which is a page imported from the old wiki, and is obsolete. > So I also believe that we would benefit from a "wiki admin/maintainer". > But is there someone volunteering ? Jonas did so in #359116 (on 2006-04-26, a year and a half ago), and I did so in the previous mail. I'm fairly sure we can harness some man-hours from the other developers who used to maintain it before it came under .debian.org and from other people involved in the web site; if not, I'm definitely sure that we can draw new blood from the remainder of our 1049-odd developer pool :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Vender submission problem.
On Fri, Sep 14, 2007 at 11:41:52AM +0100, Paul Cager wrote: > >> I do not believe the query on your URL should upset the process; [...] > > > > Why don't you believe it? The regexp it must match is > > /^([\w.:\/~-]+)$/ - in other words, a string containing only one or > > more word characters (alphanumeric plus "_"), dot, colon, slash, tilde > > or dash. Question marks are not allowed. > > > > That's on cgi.debian.org/cgi-bin/submit_cdvendor.pl line 76 - I can > > view it, but not edit it (and I'm not sure it should be changed). > > I stand corrected, but somewhat surprised... > > Although I don't like the idea of using a dynamic URL for what is > essentially a static page, it *is* still a legal URL. Why should we ban > it? And looking at the UK entries on http://www.debian.org/CD/vendors/#uk, > roughly half of the URLS are illegal according to the regexp above. Oh, I was just too strict when writing that regexp :) I updated it last night. Richard Atterer asked me to do it a while ago, but I got sidetracked. Please submit again. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: wiki.debian.org: Who's maintaining it
On Sat, Sep 08, 2007 at 12:18:51PM +0200, Josip Rodin wrote: > > > Technically the wiki is operated by debian-admin. For serious > > > problems, please drop debian-admin a note. Patches in coordination > > > with the python moin wiki maintainer are welcome. Patches that will be > > > overwritten when a new version gets installed are problematic, though. > > > > Thanks, but who is coordinating the wiki as a whole? > > Someone should take responsibility for dealing with questions/issues with > > the wiki in general, not only its technical side. > > In lack of more innovative solutions, I propose that we create a modicum of > new input vectors regarding the maintenance of wiki.d.o, with the web team > taking some responsibility, in lack of better targets. And, a two weeks later, spammers help prove my point ;) :( RT tickets #182, #183 and #184 were filed because spambots are vandalizing the wiki and nobody appears to be able to do anything particularly efficient against them - normal users revert their edits, but that's it. -- 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 12:43:56AM +0200, Josip Rodin wrote: > * We seemed to agree that a leader's delegation would be a useful tool to > bootstrap the soc-ctte and modify it later Well, that was so in June, but apparently everybody including the leader forgot about this in the last three months. 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. I'm going to post on -vote asking for input regarding the details of the proposed multiple person election procedure, because that was only remaining part of my old proposal that was technically unclear. (Perhaps it's better in general that that part of constitution text modification is done separately, because it's generic.) -- 2. That which causes joy or happiness. -- 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: > 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
infrastructure team rules
Hi, I pondered a bit about that old subthread about infrastructure teams the other day... what follows is what I was intending to post to debian-vote. But I'll post it to debian-project first, hoping that people improve it before we get to the stage where everyone posts GPG-signed messages :) - This originates from this debian-project mailing list discussion http://lists.debian.org/debian-project/2007/06/msg00020.html Proposed general resolution - Project infrastructure team procedures Debian developers acknowledge the following: * The Debian Project infrastructure is run by people who volunteer their time and knowledge in a good-faith effort to help the Debian Project. * Infrastructure teams are groups of developers who deal with project infrastructure and have access to resources in ways other than the standard practice of uploading Debian packages. * Infrastructure teams have an ongoing responsibility to maintain a level of service that is generally acceptable to the developer body. * It is necessary for infrastructure teams to add new members when old members depart from the team or when circumstances prevent existing members from contributing to the team effort. * The practice of existing members of a team finding people to join in and help is the original and natural way of changing team membership. * Training of and otherwise working with new team members requires additional effort from existing team members, so care should be taken to avoid having too much team effort spent on unnecessary new members or new members who would not reciprocate the effort. * Infrastructure teams have to be stable, but they don't have to calcify. * Intervention by Debian Project Leaders is not a practical solution to resolve issues with infrastructure teams. * It is necessary to define a modicum of procedure for how developers can join the infrastructure teams in order to improve them while maintaining fairness towards all. Debian developers resolve the following: * Whether a team in Debian constitutes an infrastructure team is decided by the Debian Project Leader. * Infrastructure teams have to decide to mark old members who don't sufficiently contribute to the team effort as latent. * Latent team members count for 50% of an empty seat in the team. They can be unmarked as such every four months. * Team decisions regarding latent team members have to be communicated to the Debian Project Leader or to the developers in general. * Developers can nominate themselves for membership in infrastructure teams every four months. * Candidates for team membership have to demonstrate some minimal existing competence in the area. * Candidates for team membership have to pledge a minimum 18 months availability to the team. Teams can vary this time period by 6 months, as determined by their specific circumstances and team consensus. * Infrastructure teams can decide to accept any number of candidates after a nomination round. * Team decisions regarding validity of candidates have to be communicated to the Debian Project Leader or to the developers in general. * Each infrastructure team has to populate every full vacated seat (caused by two latent members) every two years. * Each infrastructure team has to accept at least two valid candidates every two years. * New members of teams have to promise to make every reasonable effort to work with the existing team. * The previous team members reserve the right to promptly remove new members who are not willing to work productively in a team or who are otherwise a destructive influence in the team. * Removed members of teams can not nominate themselves for membership in the same team for the period of twelve months since their last removal. - -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: infrastructure team rules
On Tue, Oct 16, 2007 at 06:31:30AM +0200, Lucas Nussbaum wrote: > > * Infrastructure teams are groups of developers who deal with project > > infrastructure and have access to resources in ways other than > > the standard practice of uploading Debian packages. > > Which teams do you currently have in mind? That applies to DSA, > obviously, ftp-master, but also well-functionning teams such as the > release team? > But it could also apply to every team that has a unix group, even if > it's used to maintain a very small part of Debian infrastructure. Yes. They should all have a mechanism to stop them from calcifying. > > [...] > > * Intervention by Debian Project Leaders is not a practical solution > > to resolve issues with infrastructure teams. > > Before acknowledging that, it would be great to know the status of the > discussions between the DPL and DSA members. Frankly, no. This is a specific instance of a problem (that may require a specific solution, too), but that is orthogonal to the general problem we have, and that is that there are no written guidelines or rules about the topic, so when things get broken, and fixing them requires non-trivial action, we get stuck in a limbo. > > * It is necessary to define a modicum of procedure for how developers > > can join the infrastructure teams in order to improve them while > > maintaining fairness towards all. > > I'm not sure that fairness towards all is even a good goal here: the old > team members will have to work with the new team members. We are not > electing a commitee, where it is good if people disagree because of > diversity of opinions. I'm OK with some teams being cabal-ish if they > work properly. I am absolutely not OK with that! A promise of fairness of teams towards the general developer body and vice versa is absolutely essential for each others to even begin to have respect for each other. I'm thinking we may not be thinking of the same definition of the word 'fairness'... > > Debian developers resolve the following: > > > > [...] > > I'm wondering whether we really need all that bureaucracy. Wouldn't it > be possible to resolve something like: > > Debian developers resolve that some teams (pick up at least one > amongst DSA, ftpmaster, DAM) are not functionning properly, and > empower the DPL to take all necessary actions to restore normal > behaviour. What will that ad hoc intervention accomplish in the long run? Does the history of teams persistently losing activity/members teach us nothing? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: infrastructure team rules
[will check the wiki page, but I deleted the quote by mistake :)] On Tue, Oct 16, 2007 at 09:13:38AM +0200, Raphael Hertzog wrote: > > * Infrastructure teams have to decide to mark old members who don't > > sufficiently contribute to the team effort as latent. > > * Latent team members count for 50% of an empty seat in the team. > > They can be unmarked as such every four months. > > * Team decisions regarding latent team members have to be communicated to > > the Debian Project Leader or to the developers in general. > > The concept of "latent" team member is a somewhat strange. I agree > something like that is needed because one can't be expected to be fully > invested in a team 100% of the time. But your mathematics are strange, why > would a latent member count only for 50% of a "empty seat" ? That's simply for later calculation of how much they have to repopulate :) > I think teams should be free to coopt new members at any time as usual, > but additionally there would be those nominations rounds so that > candidates have an occasion to get a decision and a rationale (at least > they can know what they were doing wrong and can try to improve) instead > of the usual lack of answer. Yes, that's the point. This would define this procedure, but nothing prevents teams from acting otherwise (in good faith). > > * Team decisions regarding validity of candidates have to be > > communicated to the Debian Project Leader or to the developers in > > general. > > Teams have to communicate their decisions and the associated rationale to > the candidates and to the DPL. The decisions (a simple yes/no/not needed) > have to be communicated to the developers at large (on debian-devel) and > the candidate can follow-up with the rationale he has been given if he > wishes so. Oh, yes, to the candidates too, I missed that. But I don't think we want to force everything to be published to the public list. If someone wants to complain about their rejection, they should start in the same venue and work their way upwards - with the team, with the leader, then the developer body (via the -private list for example), and only if all of these fail, the general public. We don't want instant flamewars for every rejection. > > * Each infrastructure team has to populate every full vacated seat > > (caused by two latent members) every two years. > > * Each infrastructure team has to accept at least two valid candidates > > every two years. > > There must be some limit somewhere. I agree new blood is good and needed > but you can't expand the team indefinitely. > > Maybe there should be a minimal size for each team and that minimal size > must always be met and comprises only active members. And the upper limit > would be 2.5 × the minimal size (including latent members). I actually thought about it, but decided not to do so because it leads to too much micromanagement :) The point of having an ever-growing policy is to address the ever-growing amount of work that makes people go latent more and more. But it's also slowly ever-growing, mind. If everyone in an old team stays active, and there appear two valid candidacies every two years, they have to accept those two people. That's not a lot. If an old team loses two members to inactivity, they have to replace those two with one new one, and also accept another valid candidate in the same time period. That's not a lot - perhaps even too little given the loss. If an old team is already large (say, 8 to 10 people), and gets two latent members, but nobody perceives this as a problem, nobody becomes a candidate and no addition is made. If the same team from the last example has a couple of annoying wannabes who want to take advantage of rules, they can be rejected as invalid candidates (because of lack of expertise or lack of good faith), or they go away before two years lapse, and there is no problem. (If they persist after two years, and improve their skills, then they should be given a chance. They can still be thrown out post res, if they continue to piss everyone off.) If a team continues to be very active for a period of ten years, and they have an abundance of valid candidates to choose from, they get to expand in size by ten - but a) I'd like to see that team! :) b) if they get unwieldy, they can always branch out, such as have a team with tiers, and have the DPL unmark some of the tiers as infrastructure teams, so that the problematic rules don't apply (but general stance still does). Or we revise the rules in five years. That's a lot of time in our universe! :) > Latent members that have been latent for 18 months have to be removed. I don't agree with that - they don't hurt, they should stay, maybe they reactivate at some point. Or just do a thing or two every year. Or just act as a backup in case everyone else suddenly goes inactive. I trust you can see my point here :) > Otherwise it looks sane in general and I like the fact that it doesn't > re
Re: infrastructure team rules
On Tue, Oct 16, 2007 at 01:34:15PM +0200, Stefano Zacchiroli wrote: > Once we have resolved something as he propose the DPL will be empowered > to solve the problem with any team in the present and in the future. Sorry, but that won't work. The Constitution already empowers the DPL to do things that nobody else is explicitly in charge of, yet none of them ever did anything substantial to e.g. bop DSA to be more active. If we explicate that ability of theirs, that won't necessarily make them more efficient, or at least I don't see any proof for that. > A big part of our current problem is that some team do not feel they are > under the authority of the DPL whereas IMO the should be. > > Indeed reading the first part of your proposal (btw, thanks for that!) I > was expecting a second part precisely on the lines of Lucas' POV. What I > had in mind is something like: the developer body resolves that whatever > team is under the authority of the DPL. This argument is a red herring, but an apparently successful one. Well, at least my proposal resolves as the first matter of business that the DPL decides whether a team is governed by these rules, and the set of rules is then resolved by the developers. I think having agreed-upon rules is the best way to proceed. I don't want to give the DPL or the existing team members a blank cheque authority over infrastructure teams. They are nobody's personal playground, they are a common good and they need to be governed as such. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: infrastructure team rules
On Tue, Oct 16, 2007 at 09:13:38AM +0200, Raphael Hertzog wrote: > Good initiative. You might take some inspiration in the "Team guidelines" > that I drafted earlier this year: > http://wiki.debian.org/Teams/Guidelines Okay, my proposal was aimed primarily at the process of composition, these guidelines go further and advise about communication and documentation. The first matter to consider is - whether these two things are as important at this point as the composition is, sufficient to be part of general resolution; and if so, which parts :) I'm thinking that if we extend beyond composition, the GR will become too long and intricate, with more possibly contentious issues. But, one general resolution point could be made about the rest: * With regard to communication and documentation, infrastructure teams should try to work under the guidelines laid out in the Debian Developer's Reference. The DR sounds like a good place to refer to - wiki.d.o inherently can't be a stable reference, unless we protect the page :) but even then, devref has BTS support where issues can be hashed out, whereas a wiki page doesn't (at this time at least). How about that? -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: infrastructure team rules
On Tue, Oct 16, 2007 at 02:29:08PM +0200, Lucas Nussbaum wrote: > > > Which teams do you currently have in mind? That applies to DSA, > > > obviously, ftp-master, but also well-functionning teams such as the > > > release team? > > > But it could also apply to every team that has a unix group, even if > > > it's used to maintain a very small part of Debian infrastructure. > > > > Yes. They should all have a mechanism to stop them from calcifying. > > I really don't think that the qa group, the webwml group, the list > admins, etc need such bureaucracy ... According to your definition, your > proposal apply to them too (they have a unix group, and have access to > resources in ways other than the standard practice). Well, let's put it this way - do you think that the hordes of people anxious to see changes in the design of the web site think that we should keep the webwml group as it is? :) Seriously though, let's examine a more pertinent example - the listmaster team needed such bureaucracy a while ago, as you can see from the recent announcement. We had numerous latent members - I'm one of them :) and it took a fair few years to make significant progress. The change came from within in that case, but that was practically a stroke of luck. The project infrastructure shouldn't depend on luck... > So your proposal aims at solving the problem at the meta level, which > might (or might not) help to solve the DSA problem ? Wouldn't it be > better to solve the DSA problem first, learn from that, and then make > sure that this doesn't happen again? But with DSA, we're way beyond learning anything new, aren't we? :) > > > I'm not sure that fairness towards all is even a good goal here: the old > > > team members will have to work with the new team members. We are not > > > electing a commitee, where it is good if people disagree because of > > > diversity of opinions. I'm OK with some teams being cabal-ish if they > > > work properly. > > > > I am absolutely not OK with that! A promise of fairness of teams towards > > the general developer body and vice versa is absolutely essential for each > > others to even begin to have respect for each other. > > > > I'm thinking we may not be thinking of the same definition of the word > > 'fairness'... > > I'm talking about fairness in the choice of new members: teams are > likely to work better when people inside them aren't ennemies. Of > course, the "service" should be provided in the same way to all > developers. Well, they can discard candidates that they think are "enemies" using this process. They can mark them invalid, explaining how they are enemies, and that's fine. :) > > What will that ad hoc intervention accomplish in the long run? > > Does the history of teams persistently losing activity/members > > teach us nothing? > > We know we have a problem with teams losing activity/members. But we > don't know what will be the good solutions to that problem, or how to > avoid that proactively. Your proposal is just one possible solution: > maybe not the best one, and maybe it won't even work. What leads you to > think that your proposal will work better than another one? Well, what other proposal is there? We have different kinds of practices in place, but I'm not aware of any other deterministic methods or proposals for unblocking teams that are already blocked up. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: infrastructure team rules
On Tue, Oct 16, 2007 at 04:31:32PM +0200, Raphael Hertzog wrote: > > > I think teams should be free to coopt new members at any time as usual, > > > but additionally there would be those nominations rounds so that > > > candidates have an occasion to get a decision and a rationale (at least > > > they can know what they were doing wrong and can try to improve) instead > > > of the usual lack of answer. > > > > Yes, that's the point. This would define this procedure, but nothing > > prevents teams from acting otherwise (in good faith). > > State so explicitely then, otherwise it looks like all member > additions/removals have to go through this process. OK. It's actually in the first section in general, but it should be repeated in the second one, too, and phrased exactly. I intended to leave alone the existing practices of adding or removing people; this is meant to be a fallback procedure for when that fails. > > But I don't think we want to force everything to be published to the public > > list. If someone wants to complain about their rejection, they should start > > in the same venue and work their way upwards - with the team, with the > > leader, then the developer body (via the -private list for example), and > > only if all of these fail, the general public. We don't want instant > > flamewars for every rejection. > > Yeah, I agree but I also like to follow the evolution of teams and I'd > like to be informed of candidacies and additions/rejections. (I already > see every addition through the script that maps Debian groups into Alioth > :)). > > There doesn't need to be a flamewar every time just because we publish > such information. People could get used to it. > > Anyway, I don't consider this to be required in such a text but it would > still be nice. I'd still prefer it left to each team's discretion whether to just tell the DPL or the public. Inquiring developers can always check with the DPL and he can share that information (it's not really secret). You can propose the publishing by default as an amendment. > > > > * Each infrastructure team has to populate every full vacated seat > > > > (caused by two latent members) every two years. > > > > * Each infrastructure team has to accept at least two valid candidates > > > > every two years. > > > > > > There must be some limit somewhere. I agree new blood is good and needed > > > but you can't expand the team indefinitely. > > > > > > Maybe there should be a minimal size for each team and that minimal size > > > must always be met and comprises only active members. And the upper limit > > > would be 2.5 × the minimal size (including latent members). > > > > I actually thought about it, but decided not to do so because it leads to > > too much micromanagement :) The point of having an ever-growing policy is > > I think the count of latent member and conversion into vacated seat is more > work than handling lower and upper bounds of the number of active members. Possibly, but it's a much clearer criterion. If the team doesn't submit a summary of how many are active and how many are latent in some reasonable timeframe, the DPL can easily decide that they are all latent. If they say they have 5 active team members but nobody ever hears about three of them, that's fairly easy to dispute. But in cases where the team submits faulty information about the minimal number of members, then we have to have a procedure to override them. Or if that number changes over time, but that single person or two team members go AWOL, then we can't intervene without extra rules about that. > > If an old team is already large (say, 8 to 10 people), and gets two > > latent members, but nobody perceives this as a problem, nobody becomes > > a candidate and no addition is made. > > "nobody becomes a candidate" is not really under control... :) and "nobody > perceives this as a problem" is difficult to estimate. Well, candidates can also be rejected as invalid if the team members have a consensus that more new people would not contribute to the effort. They could technically do that by taking them and then immediately declaring them a bad influence. :) I'm thinking of this also as a good method to address burnouts - if there is a reasonable amount of certainty that new people will be able to come and contribute in two years time, and eventually a reasonable amount of redundancy in the teams, people won't feel much pressure to work for the team and won't burn out as before. In real-world circumstances this decreased incentive would likely be a bad thing, but in Debian we're all generally intrinsically motivated. > > If the same team from the last example has a couple of annoying wannabes > > who want to take advantage of rules, they can be rejected as invalid > > candidates (because of lack of expertise or lack of good faith), or > > they go away before two years lapse, and there is no problem. > > (If they persist after two years, and improve their
Re: infrastructure team rules
On Tue, Oct 16, 2007 at 06:53:26PM +0200, Lucas Nussbaum wrote: > > Well, let's put it this way - do you think that the hordes of people anxious > > to see changes in the design of the web site think that we should keep the > > webwml group as it is? :) > > Do you think that the reason why the website isn't changing is because > there's a lack of new team members in webwml? TWAJS. But let's give it some thought - webwml has many members, but that's a *group*, not a *team*. debwww is the Unix group that designates the web team, and that one hasn't significantly changed in years. > > Seriously though, let's examine a more pertinent example - the listmaster > > team needed such bureaucracy a while ago, as you can see from the recent > > announcement. We had numerous latent members - I'm one of them :) and it > > took a fair few years to make significant progress. The change came from > > within in that case, but that was practically a stroke of luck. The project > > infrastructure shouldn't depend on luck... > > s/luck/reasonable decisions from intelligent people who didn't need > another level of bureaucracy to take those decisions/ ? How do you know you have those people, and what do you do when you don't? :) > > > > What will that ad hoc intervention accomplish in the long run? > > > > Does the history of teams persistently losing activity/members > > > > teach us nothing? > > > > > > We know we have a problem with teams losing activity/members. But we > > > don't know what will be the good solutions to that problem, or how to > > > avoid that proactively. Your proposal is just one possible solution: > > > maybe not the best one, and maybe it won't even work. What leads you to > > > think that your proposal will work better than another one? > > > > Well, what other proposal is there? > > The "statu quo proposal", i.e "things aren't that broken in most > teams, we can just solve problems in an ad-hoc fashion where problems > occur" ? Judging by history, I don't think our current approach is exactly flourishing. We've mentioned sysadmins, list admins, web admins, all of those had breakages. We haven't mentioned bug admins, ftp admins, docs admins, key admins, account admins, but all of them had fairly major issues too. It's hard for me to recall any other major infrastructure team in Debian where I can point and say that they have always functioned fine, i.e. they only had technical issues (rather than manpower issues). > > We have different kinds of practices in place, but I'm not aware of any > > other deterministic methods or proposals for unblocking teams that are > > already blocked up. > > My point can be summarized as "do we need a deterministic method or > proposal to solve problems inside teams?" Aren't you trying to find a > technical/bureaucratical solution to a social problem? A solution where you empower more people to do things and make processes transparent should be a social solution, I don't know why you'd think that those things are just bureaucratic technicalities. Indeed, perhaps the calcification of teams stems from people having the view where a deterministic approach to social organization is frowned upon, because that serves as a general excuse, and so things end up falling through the cracks. "We're all buddies here. Writing things down is bureaucracy, screw that. We can solve any problem on the fly. Except when we can't." :) -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: infrastructure team rules
On Tue, Oct 16, 2007 at 07:00:08PM +0200, Stefano Zacchiroli wrote: > On Tue, Oct 16, 2007 at 01:54:12PM +0200, Josip Rodin wrote: > > Sorry, but that won't work. The Constitution already empowers the DPL to do > > things that nobody else is explicitly in charge of, yet none of them ever > > did anything substantial to e.g. bop DSA to be more active. If we explicate > > Fine to me that you think that won't work, but let me disagree. AFAIK > none of our foundation documents explicitly states that DSA (since we > all know that is the *current* problem) is under the "control" of DPL. > So the other powers you're mentioning above do not (unfortunately) > apply. I do think that we, as the developer body, need to make a move > and state that the DPL is in power of un-delegating, or whatever you > want to call that, DSA members. > > I do believe this can solve the problem, but I understand you disagree > on this. Your proposal is, in principle, fine with me, but I do fear the > large amount of bureaucracy it will add to various teams. > > > I think having agreed-upon rules is the best way to proceed. I don't > > want to give the DPL or the existing team members a blank cheque > > authority over infrastructure teams. They are nobody's personal > > playground, they are a common good and they need to be governed as > > such. > > Being under the authority of the DPL is not being in someone's personal > playground, since the leader is elected by the developer body. To me > that would just be a instance of representation, and the DPL already > represents Debian in various contexts. See, I can't reconcile these two sets of statements. If the leader rightfully represents the developer body and that allows him to exercise his powers, why is there any dilemma whatsoever as to whether the DPL is authorized to exercise any of his powers in the matter of Debian machines, like in any other matter where they also represent the developer body? Furthermore, if the leader having been elected by a vote of the developer body isn't sufficient proof that the developer body authorized them to act upon their constitutional duties, which also includes Debian machine matters, what hope do we really have that another vote by the developer body would make any difference to the issue? In any case, we have strayed from the general point to the specifics of that case. The general point should be... > I do fear the large amount of bureaucracy it will add to various teams. My answer is, sadly, this - it's that kind of reasoning that is the root of our problems with disorganized teams. People dislike documenting, communicating, distributing, organizing - so they avoid doing it. Sometimes even just a token amount of those activities is skipped, because nobody could be bothered. Some time later, we learn why those activities were necessary in the first place, the hard way - things don't get documented, too few people are told how they work, not enough people help carry the burden, the team is a mess. Taking half an hour of time every four months (to have a look at incoming mails about new candidates), and another hour or two every two years (weighing possible expansion options) is not supposed to be a problem. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Frequency and reasons for team breakage (Re: infrastructure team rules)
On Wed, Oct 17, 2007 at 05:45:49AM -0400, Philippe Cloutier wrote: > Lucas writes about "that broken" team, you write about teams which "had > breakages" and "had fairly major issues". If there are really 8 teams > which were at one point "that broken", I suppose your proposition is > interesting. Would you estimate that all of the teams you mentioned are > or were at some point broken to the point of being unable to accept good > candidates or justify rejection of bad candidates? > > I am curious to know more about these teams... from the teams that > recovered, what was the problem in these teams? How were they fixed > (internally/externally?)? It's the sysadmins who are usually cited as the most lagged. They still have just four members (and have had only two changes in the last decade, AFAIR), they are all generally haphazardly active, and they had no issue tracking system for years, instead people used to send mails to their list which went unanswered for months or years or never, even if issues were fairly trivial. This, coupled with the fact that many if not most people in Debian are qualified for the job, has made people bitter. There were also major problems with account managers, ftpmaint and keyring-maint, their incoming request queues tended to get very much lagged (several weeks or months). Others have generally coped better, but I know from personal experience, sometimes as team member, sometimes as someone trying to get a team to do something, sometimes as a team member who contributed to the decay :) that all other teams that I mentioned have had periods where people couldn't get stuff done because nobody from the team was tending to incoming requests, or at least not tending to them properly. Sometimes problems had more to do with there being too few people to just answer incoming e-mails, rather than the group being actually unable to get their main work done. It should also be noted that this can be a matter of people missing mails because of huge amounts of spam, or other junk, such as completely clueless requests that essentially waste people's time. Sometimes team organization problems escalate, sometimes they don't. Obviously there are also team problems which aren't related so much to organization, but to the quality of work, or lack of new quality being added. It's when both quality and organization suffer, it's more likely that problems will escalate. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: Frequency and reasons for team breakage (Re: infrastructure team rules)
On Thu, Oct 18, 2007 at 01:32:31AM -0400, Philippe Cloutier wrote: > I don't understand what you mean. Like many, I know that there are > several "problematic" teams in Debian due to manpower issues. What I > asked is how many teams are broken beyond repair...to the point that new > manpower can't help because the team doesn't treat offers of help. Did > you mean that you consider recruitment issues to be simply a result of > general lack of manpower? > > If not, which teams do you estimate are "broken beyond repair", i.e. so > much that your proposition could help fixing them? Your premise is flawed. You don't go fixing things that are not broken, but you also don't wait with fixing things until they are already so broken that they are "beyond repair". An infrastructure team can be completely functional without any thought about manpower, if several people are working on problems and handling everything all right - today. But if nobody ever pays any attention to how the team is going to look in a few years time, there's a clear risk of having problems with that later. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
infrastructure team rules (second edit)
Hi, Take two. - This originates from this debian-project mailing list discussions at http://lists.debian.org/debian-project/2007/06/msg00020.html http://lists.debian.org/debian-project/2007/10/msg00064.html Proposed general resolution - Project infrastructure team procedures Debian developers acknowledge the following: * The Debian Project infrastructure is run by people who volunteer their time and knowledge in a good-faith effort to help the Debian Project. * Infrastructure teams are groups of developers who deal with project infrastructure and have access to resources in ways other than the standard practice of uploading Debian packages. * Infrastructure teams have an ongoing responsibility to maintain a level of service that is generally acceptable to the developer body. * It is necessary for infrastructure teams to add new members when old members depart from the team or when circumstances prevent existing members from contributing to the team effort. * The practice of existing members of a team having people join in and help, and new people volunteering without a particularly formal procedure, is the original and natural way of changing team membership. * Training of and otherwise working with new team members requires additional effort from existing team members, so care should be taken to avoid having too much team effort spent on unnecessary new members or new members who would not reciprocate the effort. * Infrastructure teams have to be stable, but they don't have to calcify. * Intervention by Debian Project Leaders is not a practical solution to resolve issues with infrastructure teams. * To avoid issues with teams which are not proactive with regard to adding or removing members, it is necessary to define a modicum of procedure for how developers can join the infrastructure teams. * The primary goal of this additional set of procedures is to improve the teams and to maintain fairness towards both the teams and the developer body. Debian developers resolve the following: * Whether a team in Debian constitutes an infrastructure team is decided by the Debian Project Leader. * Infrastructure teams are encouraged to continue adding or removing members on their own accord. * Existing team members who don't sufficiently contribute to the team effort have to be marked by the rest of the team as latent. The basic requirements for this are: * Latent team members can be unmarked as such four months after marking, provided they become active again. * Team decisions regarding latent team members have to be communicated to the Debian Project Leader or to the developers in general. * Developers can nominate themselves for membership in infrastructure teams. These nominations are communicated to the whole team and they can be made every four months. * Infrastructure teams have to decide to accept or reject candidates who nominated themselves. The basic requirements are: * Candidates for team membership have to demonstrate some minimal existing competence in the area. It is recommended for candidates to have helped the team in some way in the past. * Candidates for team membership have to pledge availability to the team. It is recommended that candidates pledge no less than 12 months of availability. * Candidates for team membership have to promise to make every reasonable effort to work with the existing team. * Teams can require any number of other qualities from the candidates, as determined by their specific circumstances and team consensus. * Team decisions regarding validity of candidates have to be communicated to the Debian Project Leader or to the developers in general. Each decision also has to be communicated to the candidate in question. * If a new member is not willing to work productively in a team, or if they are otherwise a destructive influence in the team, the previous team members can and should promptly remove them. * Removed members of teams can't nominate themselves for membership in the same team for the period of twelve months since their last removal. * Infrastructure teams should ensure that they don't have too few members. The basic requirements for this are: * Whenever the team has had to mark two latent members, and has not had any new members added during in the period of two years since the marking, they have to accept at least one new valid candidate. * Each infrastructure team has to accept at least two valid candidates every two years. * Infrastructure teams should ensure that they don't have too many members. The basic requirements for this are: * Each infrastructure team should review their membership roster every four years. During the review, the team is encouraged to remove members who have been latent for very long periods of time. * If the team has sufficient active members without having fulfilled the requirement of ad
Re: infrastructure team rules (second edit)
On Fri, Oct 19, 2007 at 10:01:56AM -0400, Clint Adams wrote: > On Thu, Oct 18, 2007 at 10:50:29PM +0200, Josip Rodin wrote: > > * Infrastructure teams have to decide to accept or reject candidates who > > nominated themselves. The basic requirements are: > > Why should teams decide on their own membership? I don't think this > should be allowed. If the team is functional, why would we even consider someone/something else deciding it? Revoking the teams' right to decide their own membership would go against all recorded history (AFAIR), so one could question whether that kind of a change is done in good faith. -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
