Comment 27 for bug 882274

On 29/10/11 20:49, Tal Liron wrote:
> Mark seems to think that such work is all "easy" for us to do, because
> we don't have to face the consequences of the "real" programming-design-
> testing cycle, but in fact we're in it for the long haul and do face the
> consequences of decisions. Including such a decision as not supporting
> multiple-monitor setups or right-to-left languages in Unity (for three
> releases of Ubuntu thus far).

Whoa. Those are not design decisions, those are bugs or unimplemented
features. Please don't confuse the two. And please recognise that having
to write the code to support a movable launcher would delay those
features further.

> As a side-note, I think you've misrepresented the "inside" process a
> bit: Mark is not a benevolent dictator in any sense. In fact, his
> leadership is all about empowering and totally trusting the people who
> are responsible for their domains to make decisions. Mark *never*
> overrides these decisions, even if he disagrees with them. That means
> that whoever is in charge of designing the Dash gets total control over
> all design decisions, even though the team (and the community) as a
> whole will face the consequences later on. Mark's role is merely as an
> arbiter: to step in and make a decision one way or another when teams
> *cannot* agree. Compare this to, say, Linus Torvalds' role in Linux, and
> it's hard not to be inspired by the Ubuntu way of governing.

Much as its to the detriment of being praised I'm afraid it's not quite
like that. I do empower folk to do design work, both community and in
Canonical; but I do occasionally override them too, in order to maintain
a clarity and coherence of the whole, at least in my eyes.

> I don't think that process is broken. Specifically what is broken is the
> process involving the "outside" community, on Launchpad and beyond. Mark
> has been very focused on perfecting the internal team process -- and has
> done an astoundingly productive job with it -- but the remaining problem
> is how to properly include us "outsiders."
>
> Unfortunately, I don't see this problem fixed given Mark's current
> attitude. He just doesn't think what we do is very valuable for Ubuntu
> at large. Apparently we're a tiny minority of nerdy curmudgeons who hate
> change and love to whine. Not only does he devalue our work, but he
> seems to find it distracting and a waste of his and his teams' time. It
> seems he would be happy if we abandoned Ubuntu and went off to bother a
> different free operating system. Then the small team of Ubuntu
> programmers could do their work in peace and quiet.

Hold on a sec. If you look across the thousands of bug reports on which
I and others comment, you'll find lots of supportive and collaborative
work. Many of the bugs that are filed are genuinely interesting. Last
night, for example, I supported an idea in a bug report that rearranging
icons on the launcher should automatically lock them onto the launcher
(in the case of apps that are running, but are not favourites). I have
no idea who filed that bug, but I bet it was not a Canonical person.

My frustration is not with having to engage with a community. If I
didn't want to, I would neither read these bugs nor perhaps even bother
to have written the bug reporting system in the first place. It's an
article of faith for me, and the rest of Canonical, that community
engagement produces richer, more interesting products. Faith, because
that's as yet unproven as a workable model.

So my frustration is not with bug reports and community ideas or
opinions. My frustration is with those who fail to see that flamewars
and extended unproductive debates about single issues are slowing down
all the OTHER conversations going on.

Take the minimise-on-launcher bug. It's not a complex story, it's either
going to be supported or it isn't. After three days we had all the
possible opinions expressed - from all the relevant parties. Most of
what's gone on there since is not constructive. There are no new
arguments, no new ideas, no new perspectives, no new compromises. So, I
ask you, is that a constructive process to be celebrated? And is
ignoring and disregarding further commentary there a failure of
community engagement? Every minute spent on that bug is a minute NOT
spent on another, more interesting and useful community conversation.

What it boils down to is selfish demands of time and attention by those
interested in that specific feature, to the cost of everyone else.

We will not win or lose this battle by going back and forth on every
issue. Surely that's self-evident.

More importantly, if any given decision that has both proponents and
detractors can turn into an endless will-won't-should-shouldn't
mailfest, and if the only resolution of that dynamic is to add an option
to keep both sides happy, we WILL FAIL in the same way that GNOME and
KDE have failed to make a difference in the consumer world. And that's
what I'm working for, I'm not working for those who want to have very
possibility in their UI; as far as I'm concerned, most of them already
have vastly more options and vastly more choice than the average human
being. I'm working for everyone else, and I want to work with other
people who care about that mission.

> Except that some of us think that such "quiet" would end up hurting our
> favorite operating system.

I'm not asking for quiet. Dissent is valuable; riots are not.

> Yeah, it's hard work to include the community. It takes a lot of time.
> Welcome to free software! Mark, you set the ball rolling, but perhaps
> the project you created doesn't have what it takes to face the
> consequences of managing free software in the long haul. Let's fix this.

Do you seriously suggest I don't know anything about free software, or
working to include the community?

Mark