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

Re: [Debconf-team] Collaboratively drafting the next DebConf delegation



On 19/10/15 at 22:49 +0200, Daniel Lange wrote:
> Dear team,
> 
> as you may be aware the DebConf chairs have resigned two weeks ago.
> I have had many discussions before and during DC15 with chairs and other
> long time DebConf contributors about how to improve the DebConf
> organization.
> I also moderated a sprint during DC15 that (to me) showed the chair system
> itself (not the persons serving as chairs) has inherent issues that we
> should address.
> Neil supports the team to come up with a governance proposal for him to
> consider when issuing an updated DebConf delegation.
> 
> As of today (aka my back in the office and before leaving again deadline),
> there are two proposals that people came up with to provide some initial
> thoughts for the discussion in the DebConf team:
> 
> Alternative I: Two delegates (Controller and Continuity), very clear
> responsibilities, election after initial delegation terms end
> https://titanpad.com/DC16-draft-delegation-proposal

So, the way I understand it, this proposal does three things:

1) explicitely restrict the decisions which the chairs can interact
with. I understand that the goal here is to avoid chairs that will
nitpick about each and every decision. I'm a bit concerned that the
current list does not cover all the opportunities for causing serious
harm to DebConf organization.

The wording of this in the current delegation is:
  When necessary, e.g. when the DebConf team's inability to make a
  decision has an major impact on DebConf organization, or when a
  decision taken by the DebConf team is perceived by the DebConf chairs
  as creating serious risks for the organization of DebConf or for
  Debian, the DebConf chairs can override specific decisions.  
I'm still not sure whether the problems arose from the scope of this
wording, or from an inability from chairs and the DebConf team to work
within this wording. I wonder if what's missing isn't a stricter process
for chairs to communicate that they are making a statement as chairs.
Really, I think that the technical committee sets a good example here
(about how to restrict the discussion about a specific question, how to
make a clear decision, and how to communicate it).


2) move the chairs selection process from designation by the DPL to
election by the DebConf team. Given that the chairs are supposed to
protect the Debian Project from serious issues with DebConf
organization, I find it backward that the DebConf team is able to
self-select the controllers. Of course it's obvious that the DebConf
team should have a say about possible chairs (to ensure that they are
fine with working with the chairs), but I think that an election goes to
far. I wonder if a suitable result could not be achieved with a
negociation between the team and the DPL about possible chairs for a
specific edition of DebConf. (The important change here would be that
chairs would be nominated for a specific edition of DebConf, which makes
it possible to choose them based on the ability to work with specific
organizers)


3) The proposed delegation also increases the power of the chairs by
putting them in charge on selecting the location of the next DebConf (if
I get this right -- I'm not sure of how to read "decide on the team
awarded the right to conduct the N+1 DebConf"), and in charge of
selection a "DebConfXX project leader". I'm not sure that this is
necessary:
- will that really help in improving the DebConf bid selection process?
- do we really want to force each and every DebConf to explicitely
  have a project leader? I think that different organization models can
  work here, and I would prefer the team to decide on a organization
  model that suits them, as long as it works.

Just my 2cts, feel free to ignore and think "Gosh, it's good he isn't
the DPL anymore :-)"

Lucas

Reply to: