Re: Candidacy: Ryan Lortie

[Allan Day <allanpday gmail com>]

Thanks for the responses, Ryan.

Ryan Lortie wrote:
> [removing foundation-announce from the cc:]
> 
> hi Allan,
> 
> On Mon, 2011-05-23 at 14:59 +0100, Allan Day wrote: 
> > * Do you have any concrete ideas of what 'strong and coordinated
> > technical leadership' would involve? It sounds very nice and all, but
> > I'd like to hear some specifics before I cast my vote. ;)
> 
> I think it's premature to say "this is the solution" which is why I've
> limited myself to identifying a (perceived) problem.  I am simply
> stating that we should move in a direction of more coordinated technical
> decision-making.
> 
> That said, it's true that I've had some ideas of how this *might* look. 
> 
> The most obvious solution to me is the creation of a technical board,
> directly elected with membership restrictions by affiliation (basically,
> just like the foundation board).
> 
> This board (in conjunction with the release team) would be actively
> involved in the feature planning that takes place at the start of each
> cycle.  The board would necessarily improve communication between the
> hackers of different companies serving on it.  It would also serve a
> 'crisis response' role by acting as the point of contact for people who
> feel that they've hit a brick wall with a maintainer or when a long
> annoying technical debate is going on in the community with no clear
> consensus.
> 
> The scary part: this board would be given a stick: the ability, by
> supermajority (2/3rds?), to veto maintainer decisions.
> 
> Of course there is quite a debate about if it's desirable (or even
> possible) to use the stick in certain situations.  The hope is that
> maintainers would generally respect the decisions of the technical
> board.  Peer/community pressure alone may be enough here.  The board
> would also clearly be aware of its own limitations and would act
> accordingly.
> 
> Another possibility is to empower the release team, identify them as the
> 'crisis response' point of contact and ask them to be more proactive
> with respect to the above listed situations.  After discussions with
> Frederic Peters, it is unclear if some of the existing members of the
> release team would be comfortable with these new roles.

I had intended to avoid direct discussion of your proposal, since this
is supposed to be a candidacy discussion. Others have pitched
in with their opinions though, so I'll do the same. ;)

The current governance issues that we're currently facing are, in my
opinion, something like this:

 * There have been cases where patches have been refused by a
maintainer, and that the contributor has felt they have no recourse.

 * Maintainers sometimes refuse changes which are in accordance with
the design direction of the overall project. This isn't good for our
user experience.

 * There is an increasing perception, I think, that GNOME lacks
independence: that it is not an open space and that it is not a good
place to collaborate. This is extremely concerning, particularly
because it serves as a disincentive to potential contributors. Why
would a company or a volunteer invest in a project which appears to be
controlled by people who lurk in the shadows and which it is difficult
(if not impossible) to know how to influence?

 * Relatedly, we don't do a good job of communicating where the project
is going to our partners and to potential contributors.

Some of these issues are more pressing than others, but I'm certainly
very concerned about some of them, and I'm clearly not the only one.
Our community and our status as a open space are what makes GNOME
great; that those things are perceived to be in decline is troublesome
indeed.

As much as I think we should tackle these issues, I think we need to be
very careful about introducing new kinds of bureaucracy, however. J5
and Andrew Cowie have already expressed some of the issues in this
thread (I agree with them), so I won't repeat them. To summarise my
position, though: I don't think we want to introduce new governing
bodies that compete with the ways of working we already have. Instead,
we should aim to temper our current ways of working to make them more
transparent, comprehensible and accessible to outsiders.

The question is, how should we do that? 

First and foremost, we have to define GNOME's products. This really is
essential, since we can't arbitrate decisions until we have set out
exactly what those decisions are supposed to be achieving. Furthermore,
if we don't define our products, any new governance body is likely to
become a battleground in the attempt to define what GNOME should be.
We'd simply be relocating the contest rather than resolving it.

In the process of producing that definition, we need to clearly set out
what the role of our platform is, as well as what consumers of that
platform can expect from us as a project.

Once we've defined what we're producing, I think it would be an
excellent idea to establish an arbitration process for when
irreconcilable difficulties occur with maintainers. It is vital that
arbitrators should be domain experts. In my own field, it would be
counterproductive for non-design experts to be weighing in on design
matters, for example. We could have several panels of domain specific
experts for different kinds of issues, or a member of the release team
could assemble such panels as and when is necessary.

Those involved in arbitration should be the people who are
actively involved in GNOME, but they should have diverse affiliations to
ensure that the process is independent.

We could aim to have our product definition finished by the time of the
3.2 release and introduce our arbitration facility in the subsequent cycle.

The other challenge is to give greater transparency to our decision
making activities. Honestly, I think most of these problems would be
solved by a more active communicative stance by those who are leading
our project. There has been no public attempt to persuade our community
that GNOME OS is a good idea, for example. It just seems to be
happening. (To be clear, I think it's a good idea.) It is not
surprising that people are suspicious. A few blog posts from well
placed individuals would make a huge difference.

The other thing we need to do is provide more documentation of
decisions made by our teams, particularly in design. GNOME design is
still young, and we're a small team that was exceptionally busy last
cycle. We also produce good work and we need to keep doing so, but I do
think we need to invest more of our time in community process. I just
read Andre's proposal about team meetings and minutes and I think that
it is certainly worth considering.

Finally, we can and should do more to communicate our goals each cycle.
We have our feature proposals now; publicising those proposals that
look like they will happen is an easy way we could improve things. In
the process, we could potentially get our 'panels' (or 'boards')
involved to express their opinions, either by encouraging particular
proposals or by pointing out their concerns.

Ryan: basically (and apologies for the length of this mail), I share
your concerns and think we need to address them. I agree about needing
arbitration, but I don't think an elected technical board would help
the project, and I think that there are other things that we need to be
doing that you haven't mentioned. There isn't a single fix.

> > * If you are elected, you will have to fulfill your role as a board
> > member, yet you have not mentioned anything to do with your suitability
> > for this post. Indeed, it almost makes me think that you are unsuitable
> > for the position! So, do you think you will be able to do a good job in
> > the day to day running of the Foundation?
> 
> I would not take election lightly.  I understand that the board was
> reduced to seven people to give each member more of a sense of
> individual ownership of the business of the board and this is a
> responsibility that I would take quite seriously.
> 
> As mentioned in my candidacy statement, I'm not the most organised
> person I know.  I am quite good, however, at taking on a task and
> getting it done.

That's good to hear; it still feels like you're a bit of a single-issue
politician, however. :)

> > * I presume that your candidacy is an attempt to gain a mandate for the
> > changes you are proposing, yet I wonder whether it will count for much
> > without the support of the release team and maintainers. Have you had
> > any discussions with either of the above about your ideas?
> 
> I've been loosely discussing this topic with very many people over the
> past year and a half or more.
> 
> Most discussion that I've had on this topic has been in person at
> events.  I've talked to quite some maintainers, the former release
> manager and the new release manager.  I've also talked to at least one
> other member of the release team.  I've also talked to our downstreams
> and other outsiders to the project about their problems.
> 
> By and large, the impression I get from most people when discussing this
> is that they believe that a problem exists and that we should solve it.
> Individual maintainers tend to believe (more or less) that since they
> are not part of the problem, the solution is unlikely to impact them in
> a negative way.
> 
> Some maintainers have expressed scepticism about the negative impact
> that this proposal might have on maintainer motivation (or the
> motivation of their employers).
> 
> It's possible that my selection of conversation partners is not
> representative of the project.

Thanks, that's useful information.

> > * Following on from the above: do you think that you personally need to
> > be on the board for these changes to take place? Why not just get a
> > discussion going and come up with a plan?
> 
> Very many of the people that I've talked to about this issue
> (particularly recently, due to the timing) suggested that I run for the
> board so that I could advance this issue.  I agree that my election to
> the board would not be strictly required to this end.
> 
> At the same time, this is not the only issue that motivates me to want
> to be a member of the board.  My rushed candidacy statement certainly
> focused on this issue, but it's not like it would be my only concern.
>
> I did intend to start a discussion.

Well it looks like you've done that. :)

Allan
--
IRC: aday on irc.gnome.org