Yeah, I am happy that some people made it here
I'm happy that there's still seats free on the team
I started this very late, and I'm tired
and these are my thoughts, and I think probably go through them and see what we do then.
Oh, yeah, I didn't do this part,
I can do it after this talk, I think
So, there was strong feedback from people from the team
which are actually not here at the moment
they don't want to discuss now
maybe define the time for discussion
other people are fine to discuss
still, they like the DebConf - "The view is fantastic".
(space, please, Luca)
I'd say time, but this is my (please continue)...
Then, at night, Phil Hands brought the idea
of DebConf at Frankfurt/Hahn
which is the airport close to Frankfurt
and there are conference facilities, is easy to reach
and would be different.
My reply was, basically, (please press space)
"Stop smoking crack".
And to which, Phil replied:
[screen]: "You or me?"
Because... It can be seen from very different view angles.
Who has been to a DebConf which wasn't good?
Wow.
Ah! So you have...
Anyway, so most people have been to only to good DebConfs, which is great.
Who was skeptical of DebConf13 before coming here?
Who stays unconvinced and thinks this wasn't a good DebConf?
OK
And yes, this should absolutely not be about DebConf13
originally, my slides started after this one
I didn't to have anything about it.
But people I guess made me to add this.
As we all experienced, or, who experienced this DebConf
or also other DebConfs, our decision making process is quite often way too painful
I think it's because it's not documented
it's not a clear process, there are no clear responsabilities
no way how to make decisions.
We all know this.
And this is personally the perception.
For some months I had the impression that the Chairs were asked to decide everything.
And in the last days or weeks, I had rather the impression that the Chairs were ignored.
And that's not good.
So, DebConf is Debian,
Debian has these foundation documents
the Constitution, the Debian Free Software Guidelines.
But some other important documents that define how it all works
but DebConf has only Wiki pages and a "Manual" category.
Which is something, but very little.
And different people have different interpretation
as to how DebConf works.
Not only they have different ideas on how it should work
but also different interpretations to what we agreed
how it shall work.
And...
When I shared this slides with Gunnar and Moray,
and got feedback from Gunnar only,
that he absolutely prefers "decision structure" rather than "governance"
because DebConf is Debian, and because we have a governance
...And he has a point.
The current delegation was done by Zack two years ago.
Delegating Gunnar, Moray and me
as DebConf chairs.
With the text, "The main responsibility of the DebConf chairs
is to act as a liason between
the Debian Project and the DebConf organization.
In that capacity, the Chairs will be responsible
to the project for the DebConf organization
on Debian resources.
For example money, but also the Debian name are used to that end.
DebConf organization itself does not need to change
in response to this new delegation
and the former DebConf team is free
as it always has been to establish its own structure
and decision mechanisms.
The Chairs are expected to help the team
in establishing those things
and to break decision ties
if and when they occur."
This is a very...
Very wide delegation
It leaves many things open.
I talked with Zack what he intended about this
and he told me he wanted to spell out that DebConf is Debian
and clarifying who is responsible for Debian resources usage.
And...
That was very much needed:
clarify that DebConf is Debian
and there's no doubt about this.
I'm very thankful for this.
And of course, DebConf is also not Debian
there are differences between
or... DebConf works quite different from other Debian projects.
But then, all Debian projects
are in several ways different than the other.
So there is still a difference
but it's not on the
identical, or the...
we still are part of the same project,
even though there are different sub-projects.
And I think probably the DebConf team
doesn't really need to be redefined
but rather formalized, probably
as I think we agreed that people who are here
or who want to be here as a team
but it's completely not clear how to become a team member.
So, idea 1: anybody on the list, the IRC channels is on the team.
Next.
Idea 2: Formal process to join and leave,
for example, public mail to the list
auto acceptance by default
and the Chairs/delegates can
put this on hold or deny it.
And yearly after DebConf it is cleared by the team or the chairs.
And we maintain the list on a
public repository.
Would be one idea.
The other is the same, except
that it's not auto-accepted, but
one existing team member needs to advocate.
Next.
Or, instead of Chair delegation, what about Team delegation?
And then the team is free to add more members to it
how they fit
this would be the same as the previous idea
and the DPL can deny those.
There are many different ways to form the team.
Other suggestions?
David: So, you started by stating a problem
which is that making decisions within DebConf is painful
to which I agree.
But... Is this working towards a solution to that problem?
Is that the goal that you have in talking
about the team formation process?
Holger: I have that goal, but I don't think
we can reach it today.
David: OK.
Arne: I believe this is going quite in
the direction of the goal.
Because one problem that we had
at least in the last round of discussions
was that there were quite different people
in different sessions
and the same problems got reiterated
quite a number of times because people
had not been involved in previous decisions
and then the next time that the "make decisions" came
they tried to intervene on already made decisions.
David: So, it's the idea is that, if the team
was well defined by some mechanism
you could say the team,
you would be in a better position to say that the team
has decided something.
Gaudenz: I have my doubts.
I think that if formalizing the team membership
leads to more of a feeling of responsability
for the team on the side of the members
and there is more continuity in the meetings
it might be a good thing, but
the problem Arne stated is more
of continuity pf team between different meetings.
And I think that if you can solve that
fuzzy border, then the team is no longer a problem.
Holger: I agree. I think defining the team
is part of many things we need to do.
Steve: Right, this is something that I spoke with Holger
about, over the course of the leadup to DC13
where I was feeling personally that
I had opinions about things
but I didn't feel I was necessarily a part
of the teams, I wasn't involved in DC13 organization,
and I did have concerns about some things
but I didn't know what was right.
Should I even be voting if things are being voted on?
Should I be participating in discussions and on the IRC meetings?
It's very difficult for people to know
with the existing setup
how much they should participate, how much loud they should be
and I think having a clear idea who's in and who's out
means that we have a clearer process of making decisions
because the situation now is that,
anybody that feels strongly enough about an issue
to make noise about it, effectively
moves the needle on where the consensus is
and I don't think that actually makes sense
to have people who have strong opinions
about a particular issue
show up and argue, if they are not participating
in the DebConf team the rest of the time.
And I also think that
if we have this idea of "you are part of the team",
it's also social pressure on people who might
otherwise just drift away bit by bit,
to stay involved.
So, think about it in the terms of the
Ubuntu Code of Conduct,
the idea that if you are no longer doing a role,
you step down gracefully.
And I think having this more formalized idea of a team
helps with ensuring that people recognize
that, OK, this is a responsability that I have.
And if I'm not living up to that responsability
I should step down,
so that the remaining members of the team know
they should make decisions without me.
And in that way, having a more...
a shared understanding
of what the team's structure is
whereas right now we have this kind of
amorphous group of people who show up on IRC
and participate on some meetings or others
and have the effect of...
Holger: I'd like to stop this discussion
as I have some more stuff prepared.
I also... What I haven't put in here, but I realize
It's absolutely vital that we get members
new people easily on the team.
Like Raphael.
Nobody knew him eight months before
Or maybe two or three people
and he was a super good team member
so it must be super easy for new members to join the team
every year
and I really would like to continue
unless you really insist on saying something.
Gaudenz: I have just one alternative suggestion
I don't think we have to discuss it, just that it's noted.
We might also want to think about having
something similar or the same to the process
that we kind of established
for adding new members to the
DebConf team subversion repository.
Which is that, each year there should be
one admin from the local team
that is trusted by the global organization
allowed to add local team members.
Holger: I think this SVN access is derived
from the team membership
but anyhow...
Next slide, please.
I don't know how many people remember the times
when this was the Debian motto.
Was in the mid- and end- 1990s
So, "rough consensus and working code".
And, for Debian it's probably easy,
because "working code" is quite easy to define
exit(0);
Next slide, please.
So, what is consensus?
Idea 1: Consensus is when we all agree.
Consensus means "decision by a clear majority"
Hmmm....
Next slide,
"Consensus means an absence of significant dissent"
Maybe that?
Next one?
Other suggestions?
No, no, no, no, please let me continue with this!
Or use the microphone, but you don't get it.
[laughter]
Next slide.
And yes, this also needs to be formally documented.
What does it mean?
To some, 8 people agreeing, 1 vocally disagreeing
and 2 a bit unsure, is a consensus.
But Debian is a diverse community.
So this is not true for all.
So we need to document this.
Really, really, really, really, really.
Even if we were mostly white males.
[laughter]
Which we are not.
And we, in Debian, will change in the future too.
So our assumption now might work today for a group,
but will not work
in whatever time.
Final decisions.
Debian is a project where Debian via delegates or GR
has the final decision power.
And, this is required by the constitution (8.3 + 4.1.4).
Please read it out if you want to.
And this means that nothing is final.
Like the only final thing is death.
Death is final.
In the sense that, if you fuck up,
delegates or GR might override you.
There are and there have been many
final and good decisions.
The view on the lake is fantastic.
Thank you!
Now, some more random ideas...
So, maybe the term "Advisory board" might
make things clearer than "Chairs"?
Or maybe redefine things:
Is an Advisor something else than a Chair?
No matter what name we choose,
we also need to define the procedures
Maybe "Steering board" is better than "Chairs" or "Advisory board"
It's, again, something different.
Then there is also the DebConf Committee.
Which are those people who
are entitled to reach the decision
where the next DebConf will be.
And there would also be the option to keep that name.
And another idea which could be implemented
is, LCA has "ghosts", who are previous organizers
which are happy to help running next conferences.
And they also do, after LCA directly,
a handover from the previous team to the next team
including some ghosts.
That would mean that, whatever, 20 people
of us, or maybe 10, I have no idea
meet after this DebConf or the next one
meet for one or two days,
maybe just at one house here, or somewhere else
...whatever details, and plan the next conference.
Seems to work well for LCA.
I have here...
Lucas: Yes, so... That is probably useful
But that does not sound like there is
a core issue we want to address.
It is about sharing experience,
I think we are not too bad at that
I mean, the fact that the next
DebConf team members are attending
the previous one also helps that.
It is just a different way to the same thing.
Holger: Yes, it's just an idea
one detail to make things
more smooth.
Yes. And no matter no model we choose,
the real important part is that everybody
understands the same and can live with it,
and that future generations will do the same.
And this maybe sounds easy
I don't think it sounds easy, actually.
Yeah, but... (Please press space)
I think (press space once again)
What occurred to me two minutes ago
to end this...
Who thinks that wants to be involved
in DebConf 14 and wants to sit here?
[laughter]
Hopefully more on the Internet!
[laughter]
Lucas: So, if you go back to the previous slide,
No, the one before, yes.
So, the fact that you state that
future generations will do the same
that's quite strange.
You started by saying that Debian
has many different teams with
many different decision processes,
and I wonder if each DebConf should
not be seen as a different Debian team, kind of,
with a, maybe, different
DebConf decision making mechanisms
based on, for example
the past experience of DebConf organizers.
About Debian and DebConf.
For example, next year we have a local team with
people from a small derivative who are not
very familiar with Debian, so
[laughter]
No, I'm just joking
But it could raise some different issues
from a DebConf where there is a really
strong local team from people who
don't know Debian very well.
As it has occurred in the past.
And then, the decision making process
could need to be different in two cases.
Didier: I quite concur with what was just said
because my personal experience from, at least
the transition from last year's DebConf
and this DebConf is that it's just a
different set of people
working on the DebConf.
And the Chairs are like the
the thing that connects the different DebConfs
and maybe tries to get some homogeneity
between the DebConfs, but in the end
the people doing most of the work
to make it happen is a completely
different set of people.
So, as well as I agreed that
documenting decision processes
and all that, we can also not expect
everyone willing to participate in DebConf
organization to spend a week reading Wiki pages.
Although it's good to have documentation,
it's also a team of people that maybe
know each other, have ways of
taking decisions, or working towards a goal together
and that is also something valuable in
the DebConf organization.
I think.
Holger: But why do you have to read documentation?
You also read documentation for packaging.
Andreas: Now I need to, a bit,
disagree with what you said
I have noticed that... I have been now to
this is my sixth DebConf I am at
and at previous years, for example,
when we had the DebConf at Mexico
the team was even mostly staffed by
the global team, there were a few
local team members, and I'm actually
not so sure that it's good
to have a complete reshape of the team
for every DebConf.
So I think we should try that
we have some people involved in all DebConfs
to have some people involved in more than one DebConf
that they share the experience
that we don't need to repeat the same mistakes
we did before
and actually what I think is really
we should have a Governance Board
which helps us doing this in the ways that we want
so nobody says about, you have to read
one week of documents, but you should
write your documents in a way that
helps us reach our goals.
That it makes actually easier, faster
and less painful for all involved.
Yes, I think it's worth to try to do that.
And so, I think we should write more things up.
And that the governance might be a bit different
every different years of DebConf, as there
are different people involved.
That is OK for me
however, if you change it, I think
we need to agree on it first, and then change it.
Rhalina: Yeah, that was
you summed up my point quite well.
I think we...
It should be possible to establish
a kind of process or experience things
which could apply to many many DebConfs
and could save us a lot of redefining
and finding procedures
as the issue is with new team members.
I think, it must not be spelled out for all details
but I think there are some things which are quite...
which are similar between DebConfs, like
whatever... "What do we need for network stuff",
accomodations, we talked about this a lot...
Holger: Let Gaudenz speak. Let's have...
Gaudenz: I just want to throw in one
thing that is, from my point of view, missing.
We should think about when defining
kind of a governance model, and that is
we have to have a view on what's local and
what's global.
I think one year ago we kind of were
at this idea of, "let's drop this local team
and merge all things into global", and
in my personal view, it failed.
And the failure, I was thinking about this quite a lot,
and I think one important point of the failure
was, at the point of the failure, we were
had quite a big local team
like, taking everyone from the local team
to the global team, and they were
quite motivated by then, led to
just the locals taking over the global team.
Because we were quite a lot.
And at the point, when the globals were
recovering from the previous DebConf.
I think that is something that needs thinking about.
I don't have a solution, I currently
rather tend to reinforce the local team
more than what we did in the past,
defining areas that are clearly
in the competence of the local team
and defining things that have to be done
in a global level.
And, one other thing about the consensus
we should keep in mind is that
as it is in real-life meetings,
I can also observe in our lists and IRC meetings
that basing everything on consensus
and pushing back votes as far as possible
leads to dominance by those that speak a lot
those that feel comfortable to speak
and so on and on.
And I think we should also think about ways
to value more the opinion of those
that are probably not so comfortable in English
and speak less.
Holger: I'd like to say two things at least
One is that the idea to have one team
and not local and global team
is not a year old idea, but rather something that
is five or eight years old.
It's really a long topic where we worked
to have one team because there were
problems in the past, and now
when we achieved that, but we have new problems.
Things change, and what you just described
is throwing away experience
which I think we must avoid.
I'm sure that the DebConf14 team, even
if they had nobody from DebConf13,
or from previous DebConfs, will lead
to a good conference, but I think
it will be a better conference if
there is some continuity.
And, that was the one point
and the other point which I'm
having is really that I think that
it's a very difficult discussion at the moment
because many people are not here
also, didn't come to DebConf 13.
And also, want to hold myself back now
because I've said a lot of things
but I don't think the discussion is now
...leveled.
And I don't want to shut down
your words, but I'd like to keep in mind
that this is talk, and talk is cheap
and somebody needs to do something.
Sometime.
Arne: Yes. My question is now for the oldies
in this round: which experiences do you
actually talk about? This is something that came up
a number of times in the underpinnings
of some discussions over here,
that there have been experiences from past DebConfs
which makes joining the local and global team worthwile.
So, there was never an explicit
"what experiences are this".
Holger: For example, the DebConf 12 team wanted
to sign a venue, was about to sign a venue,
for which there was no money.
Steve: Sorry, I'm trying to unwind now,
trying to remember what I was about to say,
Regarding, oh, the DC14 perspective
I mean, we are looking to put on a good conference
and we would like to do that with the help of
those who have been in DebConf a while,
and have the experience and knowledge
on how all the infrastructure works,
that we can leverage, to put on a conference.
But the other thing that I am hoping
that we can accomplish here is...
Because this year the conference is being run
at the local level by folks who have
been involved in DebConf in the past, which
for the past years has not really been the case,
which is not a problem, but I'm hoping
we come from a position that we can
as we go along, we can be writing down
the things and helping with the documentation problem
in order to pass things on for the next year as well.
That's one of my goals in DC14, it is
to be able to provide for future conferences
well, perhaps more systematically
than we have done in the past.
Didier: One thing about consensus is
I think, I have the feeling that it can
work for technical decisions
we can postpone, like, a release [laughter]
But DebConf is time-based.
And maybe that's related to how Switzerland works,
but we just... it's not possible and it has
not been possible to postpone
the signature of a contract,
or the giving out of money,
and definitely because you then have
counterflames that come back, by that postponing,
and by that just taking time to find a good
consensus is just...
It's all fine for us, and it's good
that we can find consensus,
but when we have a time-based deadline
and time-based things that we have to get out,
and DebConf happens on a specific date,
we have to find a way to shorten
this consensus-finding period
in a situation where people can
actually take a decision and go ahead.
Steve: I'd like to quite strongly agree
with Didier on this point.
Because it is time based.
The effect of always requiring a consensus,
although we should certainly try to be a team
that works well together, and
does things based on consensus,
because when you have consensus
people feel better about things
The problem is, when you don't have consensus
and you don't have a process for deciding
in the absence of consensus, the net result
is that it drags on, it drains everybody
and everybody feels miserable at the end of it
because, some people get their way, but
had to fight for it, other people didn't
get their way, and had to fight for it,
and repeats itself over and over again
and, so, I think it's important that
as we are talking about processes for DebConf
that we do have a way to efficiently
decide on the absence of consensus.
And some of this, I think, means also
developing more a culture of actively seeking
consensus, and understanding what the
consensus is, and taking decisions that
the whole team can support, but some of it
is that you have deciders of last resort,
who will take the decisions when they need to.
And I think that is something that has not happened
in the recent past within the DebConf
organization, and that's important that we address.
Andreas: And I really think that, better
than consensus, rough consensus.
I don't think we need to have a total consensus ever,
and I believe on the idea, but that at least
we have to say, yes the team wants to go this way.
Steve and I, we know we have had both lots of discussion
where we had had different opinions while
we were both release managers
I don't think any of you has ever seen a friction
between us on the topic, but there were
discussions and we had a proper way
to handle that.
And that's the same that I think that
is really needed for DebConf
it's, we should try to arrive to consensus
or rough consensus, but if that doesn't work,
the right decisions have to be made
and they have to be made fast.
But in a way that nobody is hurt and we can go on
and continue to seek consensus again for the next one
because consensus also means, well,
rough consensus means that as a team
agrees, we go ahead with it, and not just
some will run around and the next ones
is going to fight against it.
Because fighting is even worse,
it introduces a bit of delay most often.
Bremner: Would one of you like a microphone?
Andreas: So the question was, how did we
do in the Release Team?
I think there were two different answers for that
One is, I mean, we all know we couldn't...
that we need to come to a common opinion anyway
because there is no need to do it otherwise
so it was hard, and lots of cases, I still
disagree with you, but still go ahead, or
ask a way around, so this is one way to go.
Then there was consensus not only on the
Release Managers, but on the Release Team.
So, when one of us noticed he was alone in
the Release Team, the Release Managers would
say, "just do it".
I don't mind too much.
And in the exceptional case where one of us said
"yes, I do mind so much", then mostly
we tried to respect it, because we had a lot
of respect for each other's hard work
And the last one, there was one case where we
really couldn't agree, we escalated it together
to the Technical Committee for decision.
Bremner: I wanted to make a remark which
wasn't about consensus or voting
but about decision making
And my experience this year on Bursaries was
not that we had difficulty reaching consensus,
but that there was nobody who felt
responsible for driving the process enough.
I know. Steve is pointing at me, and I think
eventually it was me. Which is fine!
But it would have been better if I knew that earlier.
Holger: Details!
Bremner: So, I think, when we talk about
organizing things, it's not just about
how we make final or difficult decisions,
but to deciding who is responsible for
gettings things done is also important.
Holger: I'd like to comment... You both
described how consensus is difficult, or has problems
before the conference. To me, it's way more difficult
during the conference, because there's even less time usually.
So, I think in this consensus model there needs
to be, "what do we do if we don't reach consensus".
that needs to be in there definitively.
And I'd like to ask, is there anybody watching the
Talkroom 1 IRC channel? Is there some useful input?
And I'd like to end this session, because
I think we are getting in circles. I think we
have five more minutes left
but I don't think we need to use these five more minutes
because we have to work with documenting
and I really regret I did not put this document
on Gobby before this session, and then didn't
had it happen.
So, did somebody check IRC? Is there something?
Bremner: I can forward Madduck agreeing with me.
So, Madduck says, "I think the important thing
is exactly related to what Bremner has just said.
Conflict prevention is a lot about definition of roles
and management of expectations."
Gaudenz: And I think that's one reason why
we should not just end the session now and go out
but try to follow that and have at least
some understanding on how we will actually
reach to a better point.
If there's someone who wants to do proposals
or a small group or whatever
or we all should write to the mailing list, or...
Because I feel a bit that we had a nice session now,
we had quite some good discussions, but it
won't change anything.
Holger: I think this will be the case anyway,
whether we continue five more minutes or not.
There are five more minutes.
Steve: The point is not whether we are using the
five minutes here, but what are we doing
to continue this discussion.
Holger: OK, but then lets spend the five minutes
to talk about this, and not about whether we should...
...details in the decision process.
Gaudenz: I was probably not clear enough...
Holger: And what you [gaudenz] said yesterday
that you would be, after Debconf, be very busy
with finishing DebConf13, and so, my idea
would be to discuss this decision making process
and define it
when the DebConf13 Final Report is done.
[laughter]
Don't do it now.
Lucas: Yes. So, one thing I'm kind of wondering is,
Wouldn't quite a good solution would be
to ask the DebConf Chairs to actually make that work,
of defining... Making sure the rules are clearly defined
and defining decision making processes that
work with the local team for each DebConf.
Instead of defining one that would always
be applied to each different DebConf, maybe
that's part of what, or that should be part of
what DebConf Chairs responsibility to ensure
that... I'm not sure which phrasing on the delegation,
but that budget is used in a sensible way.
Holger: The Release Team delegates also decides
how the Release Team works, as far as I know.
Or other delegates decide how their...
OK.
Arne: So, I must somehow put my word against
the idea of putting this decision back until
the final report is out, because that's
the case is that the last DebConf that would have
been by the middle of this year.
Holger: By the time that the Final Report is out,
or in two months.
Arne: Better.
Bremner: Ok. So I just want to relay
a complaint from Ganneff.
You will be surprised to hear Ganneff complaining.
So Ganneff says, he won't change anything because
there's not enough people in the session or at DebConf.
He remarks on the fact that we are missing two Chairs
and lots of team members.
Holger: I think this is a good closing statement.
Enjoy the last day of DebConf!
[applause]