Moray Allan

Who am I?

I have been programming for about 24 years (I'm now 32), and wish that all
software were free software.

I did a PhD in machine learning (then some years as a postdoc researcher in
France).

Before that I did a humanities undergraduate – besides being a free
software geek, I'm a geek of history, languages and music.

I enjoy travelling; destinations in recent years outside DebConfs included
Uzbekistan, Lebanon and Albania.

For paid work, I am currently a freelancer.

When I am not travelling, I am based in Edinburgh, Scotland.

What have I done in Debian?

Here are some of the things I have done in Debian over the years:

I have maintained packages in Debian since 2003, and been a DD since 2004.
(Debian has been my preferred operating system since 1998.)

I became a DD to create Debian packages for the GPE project, where I was working upstream,
and later created a small team to maintain related packages.

In recent years, most of my Debian time has been taken up by DebConf. DebConf
handles a large financial budget every year compared to other areas of Debian,
to bring Debian contributors together for talks, discussions, and to work on
projects. The DebConf team works closely with many other Debian teams,
including the DPL and Debian auditors for money, the press and publicity teams
for outreach, and core technical teams to arrange events that will help their
work. Each DebConf has a hard deadline, when attendees will arrive, that we
have always met!

I am part of the publicity and press teams (including helping with the Debian
Project News).

I worked as an Application Manager in the NM process from soon after I joined
Debian. More recently I have sponsored packages for a few people, and
encouraged them to get involved in Debian.

I participated in the Debian Women project from when it started.

I have participated in zack's DPL helpers initiative since it began last
year.

Since the DebConf team should be a black box to most of you, but has taken a
lot of my time in the last few years, I'll comment a bit further on what I've
done there. I have worked there in different roles over the years, which have
brought me into contact with many aspects of Debian:

I've been working in the DebConf team since about 2006.

I made local arrangements for DebConf in Edinburgh in 2007.

Since then I have helped coordinate each DebConf, as well as working in
specific subteams each year.

In recent years I pushed formalisation of some of aspects of DebConf
organisation, including agreeing a set of goals for DebConf, a written process
for making decisions about DebConf venues, a budget-setting process, and a DPL
delegation for the new position of DebConf Chairs.

I am currently a DebConf Chair, coordinating work in the DebConf team, and
keeping track of what is happening and what is stuck and needs help.

Platform

Debian is now in its twentieth year. Looking back at the project's
development, the first years showed the rapid development of early childhood,
open to try anything. In the following years it started to be more careful,
and its permanent character emerged in our Social Contract and the Debian Free
Software Guidelines. As Debian became a teenager, it showed typical
stubbornness even in minor squabbles, and had a tendency to fight with its
friends. Debian's calmer atmosphere and greater predictability in the last few
years may be signs of adulthood, but we need to hang on to the project's
feeling of fun even if that means occasionally being childish, and to hang on
to a child's sense of surprise and excitement.

To me it is indeed surprising that Debian has lasted, and prospered, this long.
I'm very happy that it has, but we should remember the level of success (and
perhaps also some luck) involved in that. In particular it's surprising to me
that despite the many arguments over the years we never had a permanent schism
in the project and a fork into separate groups working independently. Of
course we now have many derivatives, each with a different character, but each
of those makes Debian a more important part of the free software community. We
have many users who take Debian for granted, including many who don't even know
they are using Debian's work – we should be pleased about this as a sign
of how mature and stable a project Debian is seen to be. Recent W3Techs
surveys show Debian as the most popular choice for Linux webservers, with a
market share of over 30%.

Debian is also surprising for working very well as a flat organisation. Much
work on Debian is done by people working independently or in loose,
unstructured teams. Most teams in Debian were not created top-down but
bottom-up by people doing a specific type of work. This looseness and lack of
lines of hierarchy can occasionally lead to conflict about specific decisions,
or prevent any definite decision from being made in a reasonable time, and the
DPL can help in such cases by mediating between different groups. I would also
like us to take a more pre-emptive approach to such issues by encouraging more
turnover of members between different teams so that teams share experience, and
by encouraging more organised discussions between teams about their plans and
requirements, including where appropriate at face-to-face inter-team sprints.

Below I comment on a few aspects of how I would work in the DPL role if
elected. While we only elect one DPL, I am sure that my fellow candidates will
present good ideas which would benefit the project. If I am elected, I would
also work with them to make sure that those ideas are implemented.

I have grouped topics below going in order from the general to the more
specific. Although I can say clearer things about my own specific ideas than
about, for example, coordination which where the DPL needs to react to problems
that aren't known in advance, if I am elected I would treat the more general
points of delegation, coordination and communication as higher priority than
pushing my own specific ideas.

Delegations and teams

I believe that as well as experience and skill in the relevant area, Debian
teams need:

transparency – teams' work, including their problems, should be visible
to others outside the team;

communication – teams should report to the broader project, and actively
seek feedback;

openness – teams should be pleased to hear new ideas from outside the
team, and genuinely consider what aspects of them they can usefully adopt.

If elected, I would lead a discussion to establish some guidelines on good
practice for Debian teams including these aspects. When making delegations, I
would ask teams to define their points of contact and specify how they will
communicate their results.

Where I saw a lack of transparency, communication and openness in an existing
team, I would work with the existing team members to address this problem. I
don't believe that any Debian team wants to be opaque, uncommunicative or
closed, and I think that our teams generally have high standards in these
respects, but we know from past problems that maintaining those high standards
can be hard when there are more immediate pressures on teams to get work done.

I would encourage teams to plan ahead how they will enable a turnover of people
in delegated roles. This could mean, for example, that a team defines in
advance a rotation schedule that commits it to recruiting new members. It
isn't healthy for team membership to stay static until too many members get
bored or burn out. Our ideal should be for people to retire from roles while
they are still performing them well, and then transfer their experience to
other areas of the project.

I would continue the intention of previous DPLs to ensure that all delegations
are clearly listed on the Debian organisation webpage. I would ask delegated
teams to see if the scope of their delegations should be expanded or otherwise
updated.

I would also intend to record publicly formal delegations for specific one-off
tasks, not only ongoing teams, more often than has happened recently, to
increase transparency.

Coordination/mediation

Much of the time the DPL's role is coordination and mediation, working by
encouragement and influence rather than through power. This is quite similar
to the coordination role I have played in DebConf organisation. Already within
DebConf I have also been ready to set aside my own preferences when neutral
mediation is required between different positions.

I also think that many others in Debian can help with coordination and
mediation. I would continue the recently formed DPL helpers initiative
as a point of contact for people interested in this kind of activity to hold
discussions, share out tasks, and work together.

However, I believe that Debian is at its best when it is a flat organisation
where different groups and individual contributors work together directly as
needed, including of course groups that themselves have a coordinating purpose,
like the Release Team. In my view, coordination and mediation from the DPL or
helpers should only interfere where it looks like something is going
wrong or being forgotten, and an important part of their goal in interfering
should be to restore things so that less interference is needed in future.

Internal communications

Internally, I would continue Stefano's attempt to make as much of the DPL's
activities as possible public at least to project members, including an
activity log. The DPL and helpers have a responsibility to provide a good
example of the criteria of transparency, communication and openness that I
defined above.

Where possible, I would push DPL-related discussions from private venues to
public ones. For example, many DPL-related topics should be discussed on the
debian-project mailing list where others can follow what is happening and
provide feedback and new ideas.

More importantly, I would encourage all Debian teams to be transparent and
communicative, and to have clearly defined points of contact.

External communications

Externally, I would try to help the press and publicity teams find more
volunteers so that they can build more active relationships, for example with
sympathetic journalists, company representatives or government officials,
rather than only pushing out announcements and hoping that they are picked up.
(I am currently part of both teams.)

Building relationships with company representatives and government officials
also goes beyond the responsibilities of the press or publicity teams alone.
These teams currently cover one aspect, of pushing information to them. A
second aspect could be fundraising, as I discuss below. But a third aspect
would be to listen to what these organisations, as major users, would like to
see from Debian, and to motivate them to fund contributions to Debian in ways
that will make it more useful for them. Some work in this direction, limited
to companies that already contribute to Debian, was started in the
debian-companies initiative that launched last year.

I would be willing, and available, to attend events and to give talks on behalf
of Debian. But I don't think that this kind of role of representing Debian
should be limited to the DPL, or to people in high-profile technical roles.
Where Debian money is used to fund travel purely to give talks, the priority
should be to send a good speaker who will present Debian well, taking into
account travel costs for possible candidates. Where good speakers feel that
they lack an appropriate Debian position from which to represent Debian and
gain speaker slots at conferences (including because they previously held such
a position but have retired), I would be happy to give them some appropriate
title by a delegation.

Local communications

In my experience, although most Debian communication happens online, it is much
easier for us to recruit new volunteers where there is some existing personal
contact.

I would like to encourage more local meetings of Debian contributors, as a way
for us to reach out to potential new contributors. I don't mean by this that I
want us to try to split up existing local groups that are wider than Debian,
but while many locations have regular Linux User Group meetings, most of these
are very different in participants and intentions to a Free Software Developer
meeting. In addition, it would be good to have more immediate ways to answer
the frequent queries for who to contact about Debian in a given region, through
a database of local groups and of Debian people who have agreed to be regional
contacts.

As a more immediate goal, I would like Debian's 20th birthday this August to be
celebrated by many Debian Day local celebrations round the world, not just at
DebConf for those of us present there. Where possible, these events could be
used to inaugurate ongoing regular local meetings.

Fundraising and spending

Now that we have greater clarity about what assets Debian holds, and how funds
have been spent in the past, due to the great work of the Debian Auditors, I
would like us to more actively plan both how best to spend the funds available
to us, in a transparent way. Our constitution already demands that major
expenditure should be debated in advance, not merely authorised by a DPL edict.

I certainly don't want us to start scattering nagging advertisements across
users' desktops, but we already seek significant levels of donations, most
significantly for DebConf and individual team sprints and for hardware
replacement, and I would like to see people working on this coordinate their
work through a shared fundraising team. The work of raising this money needs
some central coordination, even if only because having multiple fundraising
teams saying different things to the same organisations could be dangerous. I
am pleased that Brian Gupta, from the DebConf fundraising team, has recently
taken up this topic, and as DPL I would seek to push this forward.

I would seek suggestions on how we could try to advance Debian's goals by
spending money in ways we're not currently doing. While I think we should be
careful with money, I would be willing to authorise spending to try out new
ideas from others, where goals can be defined and the success of an initiative
can be judged.

Merging from the DebConf branch

In the last few years I've been pushing for some aspects of DebConf to be
merged back with their main Debian equivalents, where some branching had
happened, or to be made more general where they only existed formally within
DebConf. The next steps of this would be easier to push by having a DPL focus
on them than from within the DebConf team.

I would like to note here that while I would have rather less time for
day-to-day DebConf work as DPL, I am confident that the other DebConf Chairs
and the rest of the DebConf Team would continue very well even if I disappeared
utterly from doing work there tomorrow.

Specific ideas

Most of what I have said above is intentionally general. If elected DPL, I
would not see pushing my own specific views as primary – our Constitution
in fact requires that when leading discussions the DPL should not use the
Leadership position to promote their own personal views. But since you're
reading this, I'll take the opportunity to advertise a few specific ideas I'd
like to see taken up or, better, improved on:

We should have a process, preferably mostly automated, to spot
abandoned-but-not-yet-orphaned packages and to try to resolve the situation.
Volunteers can't be obliged to work on packages they have lost interest in, but
it would be better for the distribution's quality if they recognised it sooner
when they lose interest, before the package becomes stale.

Some types of distribution-wide changes have become much easier with increased
use of higher-level package helpers and especially of dh. In some
circumstances we might now be able to adopt more aggressive timescales for
changes that affect many packages, if we explicitly authorised NMUs to help in
the latter part of a changeover period.

Besides the great work of debian-mentors/mentors.debian.net, it might be good
to provide more ways to learn about how to contribute to Debian. One
possibility would be to encourage teams to take interns, perhaps for a summer
period like GSoC, and give them tasks that they can learn from. While it's
usual for interns to create more work for existing team members rather than
reduce it, this could help recruit new long-term contributors for Debian even
where people don't continue afterwards in the specific teams – finding a
first way to contribute and enter the community is often a difficult step.

Similarly, we could do with clearer ways for potential new contributors to find
initial tasks. We have often suggested to look at the list of orphaned
packages, but often these have been orphaned for a reason. Even for people who
are ready to just start doing work, Debian is so large that there can be
an overwhelming list of choices. Some ongoing curation of a list of suggestions
would be helpful.

What would I intend to do differently from Stefano?

I have been asked what I would intend to do differently from Stefano if I
became DPL. I have mentioned some points under the topic headings above. Here
are a few more comments:

I think Stefano has been a good DPL, and I wouldn't plan for any radical break
in style from him, but I think we have different interests and priorities.

For example, I wouldn't focus on legal issues myself, though I would be happy
to delegate them and push for action if needed.

I feel that Stefano has expanded the amount of coordination from the DPL
– not necessarily from intending to be centralist, but perhaps
unintentionally through people seeing him do a good job and wanting him to do
more. I see DPL coordination in a routine matter as itself a sign of a wider
problem that should be addressed.

I have been very impressed by Stefano keeping his daily log, and the regular
bits from the DPL mails. While seeking to continue these, I would try
to push more DPL-related communication directly into regular public Debian
mailing venues such as the debian-project mailing list.

How would I have time to be DPL?

On previous occasions I'd ruled out running for lack of time, but I am more
flexible currently – and I might not have such flexibility any more in
another couple of years, so am running now.

I currently spend a large amount of time on DebConf, and would reduce this,
while drawing on the experience I have gained there.

I am self-employed, so can be confident that my employer will be flexible when
required.

Comments on the other candidates' platforms (Rebuttal)

I'm grateful to the other candidates for standing, for taking the time to write
thought-provoking platforms, and for participating in the
debian-vote
discussion, where we have touched on many Debian topics that don't normally
get much attention.

For better or worse, my platform is the
most
dependent on holding the DPL role, since it grew out of my experience doing
coordination work in Debian and is directly related to coordination-level
changes that I would have no mandate or authority to push through unless I am
elected. In contrast, I think that Gergely and Lucas could implement the major
ideas from their platforms without needing to be DPL, and if I am elected I
will encourage them to do so.

Gergely Nagy

It seems that I'm more positive about the current state of Debian than Gergely,
but I share some of his concerns about communication, including the idea that
we should encourage more local communication and events, and about the need to
more actively encourage people into Debian contribution. I'm glad that the DPL
campaign period has been an opportunity to raise these topics. If I am
elected, I especially hope that Gergely will help coordinate work on local
Debian groups and events, and on finding other ways to reach out to new
contributors.

I'm also generally grateful to Gergely for his perseverance in standing once
again and for making the election discussions more interesting.

Lucas Nussbaum

For me, the most important points in Lucas's platform are his suggestions on
documentation, development practices, and sponsorship infrastructure. I would
like us to take a more active approach than he suggests to reaching out to new
contributors (as well as to the media, companies and governmental
organisations), but these points of his are complementary to the more
coordination-level ideas I want to push. If I am elected, I will strongly
encourage Lucas to continue his work on these topics. I especially look
forward to us having concise documentation to bring old contributors up to date
with current best practices. I am interested by Lucas's suggestions about a
project observatory, and encourage him to apply his technical skills to
improve our tools in this area too.

As Lucas has noted on debian-vote, most of the things he mentions in his
platform don't require special powers, but if I am elected, I would be happy to
give his work on these topics formal support by a delegation.