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 helpersinitiative 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.
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.
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.
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.
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.
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.
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 DPLmails. 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.
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.
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.