Re: Questions for the DPL candidates
Matthew Garrett wrote:
Anthony Towns <aj@azure.humbug.org.au> wrote:
I'm not sure I've seen any evidence of people becoming more tolerant,
just because things happen more often. I'd be more inclined to expect
the opposite, really. Especially if the complaints are focussed on the
process rather than the outcomes; since that can't be mitigated by good
results down the track.
Right. That's kind of worrying - if we had a move towards a larger
number of teams, do we risk spending more time arguing over the
conclusions that these teams have reached?
I'd like to split that into two questions: are we going to spend time
discussing their conclusions, and are we going to spend time flaming
over their conclusions? I certainly think we should discuss them,
especially if there are disagreements or details that need working out;
but there's a difference between that and the sort of "argh, they're
stealing my beloved project out from under me" stuff that seems to
appear with rather dull monotony.
I think that's more a matter of bad preconceptions, and just plain bad
habits, than anything. Venting on mailing lists is a vicious cycle; you
vent, other people stop listening to you, you vent about people not
listening to you, rinse, repeat. And if you've got a preconceived notion
-- like Martin Krafft's been talking about -- that people won't listen
to you, that you can't help, and the only thing anyone will do if you
ask how you can help is tell you to "RTFM" or "FOAD^H^H^H^HUTSL",
there's not much else you can do *but* vent.
I think we're well into the vicious cycle, and something pretty, well,
vicious needs to be done to break that -- more than just random people
killfiling, hoping people'll ignore trolls, and being mean to people.
Mainly because I've tried all that, and it didn't seem to work :)
It does need to be dealt with from both sides though: making the lists
more pleasant and tolerant, and making it easier for people to know
what's going on.
What clearer communication do you expect? Should we replace Steve with
someone who has a more gilded tongue? I mean, the whole "clearer
communication!" line is great, but we spent a week trying to make that
as clear as possible, and apparently it's still "the worst possible way
to announce it" or so.
It's much easier to argue against conclusions if there's no
justification. It's also much easier to jump to conclusions about /why/
those conclusions have been reached. In this case, a description of the
decision making process would have been likely to focus discussion on
the issues the proposal aims to address, rather than simply criticism of
the conclusions.
So, what changes would you suggest? I mean, it's easy to say these
things *after* something's gone wrong, but you can only solve the
problem if you can stop it from going wrong in the first place. You had
some opportunity to help Steve out before the announcement went out --
was that not enough?
It's possible you've got something else in mind -- eg, Linux Australia
has started (as of last year, and hopefully continuing this year)
providing "media training" for the people running Linux.Conf.Au and
others -- giving some instruction on how to answer media questions and
how to get press releases out so they get paid attention to. Should we
be doing something like that -- whether paying for some sort of
professional communication tuition for people in key roles, or just
providing some guidelines for how to write "Bits from..." mails?
What happens if people still aren't happy after you've followed the
guidelines? I mean, in this case, Steve did his best to follow
established procedure for things like this, yet there's still a
many-hundred message flamewar about it.
(We'd still have had the anti-cabal flames, of course, but that's fairly
unrelated to the post-meeting announcement)
Uh, wtf should anyone contributing to Debian have to put up with random
"anti-cabal flames", exactly?
So, how would you have made that happen, had you been in say Martin's
shoes (which, at least as far as access to information you pretty much
were), or in mine with added Supa-DPL Powahs (ie, at the meeting, and
DPL at the time)? Or how would you encourage Steve or Andreas to do
things differently for future meetings they might organise?
It turns out that I probably found out about the meeting before Martin,
but in any case I don't think there was a great deal anyone could have
done at that stage other than ask for a clearer description of what
issues were planned for discussion (of course, with hindsight that would
have made fairly little difference - it's clear that the contentious
issues are the ones that weren't on the schedule originally).
So, that kind-of sounds to me like "there's nothing that could've made
the communication clearer here, but it's fun to criticise anyway".
I don't mean to say that it's not worth looking at what can be improved;
but at least while I was RM, I found it very difficult to work while I
was being accused of being malicious, incompetent and insincere
simultaneously, at the same time as the DPL and tech-ctte were being
very careful not to offer any particular support, and stay at arms
length from commenting on any controversy without a very explicit
invitation, to the point where I couldn't distinguish their reactions
from "If you really insist, we'll repeat what you write for us".
In terms of future organisation, more warning would be a good start.
You've said that the discussion of a new strategy for etch was something
that had been on your mind for a while.
Like I said, that wasn't the case -- the announcement went out about ten
days after I first heard about the idea; and the meeting took place,
hrm, a month and three days since I first had any idea one was planned,
and it was a week or two after then before there was any indication when
it would be.
A pre-meeting brainstorming of
potential things that /might/ be discussed would have allowed for people
to have some more input (yeah, there'd have been noise as well. Fixing
that involves rather more social change), and would have avoided the
feeling that people now have of being left out of the process entirely.
So, the meeting could've been held up for this, which would've in turn
held up the discussion of sarge release issues that happened at the
meeting, and thus, presumably, held up sarge, further.
That's the cost; on the benefits side, you've got YA random flamewar on
-devel, where no one's even game to suggest anything so controversial as
dropping architectures from stable.
Or, at least, that's how it strikes me.
How about the creation of a checklist for meeting organisation and
reporting? Something along the lines of:
1) Has the meeting been announced well in advance?
No, not even to the participants. What now? Delay the meeting, or hold
it anyway?
2) Have we defined the scope of the meeting?
Yes. "Work on release issues."
3) Have we given others an opportunity to provide input on the issues we
hope to discuss?
Dropping architectures has certainly been raised on the lists before,
but in any case, the discussion afaik went beyond what was hoped to be
discussed. Should that have been forbidden? Should everyone at the table
have said "Woah! Sure, we've just flown thousands of miles to talk about
this sort of stuff, but we can't discuss anything *this* controversial!
Let's eat some chocolate then go get drunk instead!" ?
4) Have we recorded the process that led to our conclusions?
"We threw ideas across a table." Did that help?
5) Does our write-up start with the problems we wish to address and
then logically progress from there to the conclusions we reached?
Yes, it did -- the introduction to the plan was:
"The release team and
the ftpmasters are mutually agreed that it is not sustainable to
continue making coordinated releases for as many architectures as sarge
currently contains, let alone for as many new proposed architectures as
are waiting in the wings. The reality is that keeping eleven
architectures in a releasable state has been a major source of work for
the release team, the d-i team, and the kernel team over the past year;
not to mention the time spent by the DSA/buildd admins and the security
team. It's also not clear how much benefit there is from doing stable
releases for all of these architectures, because they aren't necessarily
useful to the communities surrounding those ports."
would result in less ill-will in future.
Even if it had been possible, do you *really* think posting "Hey, we're
going to have a meeting to discuss dropping everything but i386 and
powerpc" would have generated less ill-will?
Cheers,
aj
Reply to: