[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
    them - I don't believe we clarified this point
  * The consensus on later changes to the committee was that it should not
    be done often in general, though we did disagree somewhat regarding the
    method of accomplishing that goal. I had previously proposed that normal
    elections be held every two years; Ian had previously proposed that the
    initial soc-ctte varies its own size and membership.
    Observations on the matter included one generally agreed-upon idea -
    that members of soc-ctte should be able to be recalled by the developers
    by some other method other than an ad-hoc GR vote just for that purpose.
    The opposition to the idea of normal elections is that it would require
    campaigning for re-election, even if that just meant spelling out what
    was done, because of the private aspect of the relevant work; and also
    because a year or two years might not be a sufficient sample to consider
    someone's work on the committee.
    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. 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.

I think that covers most of it, but maybe I forgot something.
Corrections and comments are welcome, obviously...

-- 
     2. That which causes joy or happiness.



Reply to: