Platform for Andreas Schuldei

Presentation

I am 34 years old, am married and we have one child. I have been a Debian Developer since 2000 and have worked professionally with Linux (and later Debian) since 1996. Presently I am paid to work on Debian-Edu. I would continue to enjoy the support of my employer, if elected, as he believes the role of DPL is crucial to Debian - this would also allow me to work on DPL issues during work hours. Many of you might also know me from the Debian conferences that I've helped organize.

I would like to run for the office of Debian Project Leader because:

I believe that Debian needs some change in how it works (even on a social level) and I have some experience in implementing change in volunteer contexts.
I have experience with leadership in real life volunteer/FOSS contexts.
Where necessary, it will be possible for me to serve as DPL full-time.
I have a track record of being a good organizer.

I also started some time ago to work on some of the problems that we have today, namely the FTP-master confusion¹ and the release delay².

What I want to achieve

The overall goal is to make Debian a fun and rewarding context to work and spend time in. So much so, that one misses and longs for it when one can't be or work in it.

Part of this goal would be:

promoting lots of small teams all over the project, in which people work together, communicate and help and even integrate and train NMs
having a more friendly and helpful environment on mailing lists and IRC channels
making people aware of their leadership role in the project and encouraging them to accept it more consciously and confidently
having more frequent and regular releases
having more frequent real-life meetings³ like DebConfs, bug-squashing parties or development/hack meetings (like the debian-installer team does in Oldenburg or the Debian-Edu team does in Oslo)

These steps would make Debian a more enjoyable place and at the same time address scalability issues⁴ that Debian suffers from.

Implementing those changes as a one-shot measure is sure to fail and will do harm: social change needs to be implemented gradually and gently. Nonetheless it is important to start as soon as possible, and even though we won't see instant results, it is important to continue steadily and patiently.

It is not necessary to have perfect leaders, prospering small teams, and a friendly and helpful working climate, all within one month. But we will soon start seeing noticeable changes for the better if we manage to perform many small improvements, one step at a time.

How I want to achieve it: a DPL team

I believe that the DPL has become a harder job throughout the years, with more and more time consuming tasks. I also believe that Debian could do here and there with some serious attention which should not be limited by the resources of a single person. In order to be better able to achieve my goals, I have solicited the help of a small team of Debian Developers. At present this team consists of (in alphabetical order) Andreas Schuldei, Bdale Garbee, Branden Robinson, Enrico Zini, Jeroen van Wolffelaar and Steve Langasek.

Having a DPL team will allow us to:

distribute workload, avoiding burn-out and problems related to real-world unavailability of individual developers;
keep regularly in touch with a larger part of the project, to be more proactive about difficulties, and detect them earlier;
help build broader consensus by functioning as a 'chair' in Debian;
make sure that decisions that need to be made are really made, even though that means to keep track of a lot of things, takes time and perhaps requires to be in multiple places at the same time;
have the most appropriate person be responsible for their areas of expertise. Everyone has unique talents and motivations which make certain tasks more enjoyable for them than for others and lets them deal with them more efficiently.

Implementation details:

DPL is chairman of the DPL-team.
DPL remains formally responsible for all decisions.
Whenever possible, smaller tasks are micro-delegated to the team member that is most appropriate for it.
Important and/or controversial decisions are made in discussion with the whole team.
The team meets regularly and frequently (weekly, up to 1h), to discuss new issues and review ongoing tasks.
It is a real team, each member can represent it and communicate the team's viewpoint above personal viewpoints.
Public minutes of private meetings are made available where discretion allows; likewise, a public agenda is made available in advance listing all non-sensitive agenda items, in order to allow and invite public discussion and public feedback before decisions are made.

We strive for transparency and are open for more people, but we don't intent to grow too much (say, above ~7 people) to keep group-work efficient. Low fluctuation/turn-over and steadiness is desired, however, there is no expectation for team members to stay on longer than they're able to.

Leadership

Good Leadership exists in the free software world, Debian included, and happens mostly without anyone noticing, not even the person who took the lead. Good examples in Debian are Steve Langasek in the release team, Petter Reinholdtsen in Debian-Edu or Joey Hess in Debian-Installer.

Leadership in voluntary organisations like Debian lacks the instruments of power that are used in business environments and give leadership its bad taste. That does not keep some people from trying to apply them anyway: usually this results in people leaving or frustration in general. The answer to fear of bad leadership is not to have no leadership at all, but to seek good leaders. Great leaders do not just appear out of nowhere, but they need to grow. Small teams are good environments for them to develop their skills and learn from others.

The "Herding of Cats" failed. The problem is in the word "herding" which implies "keeping people in the place where they are". People are more inclined to pursue some fascinating goal. Debian's goal is to produce an excellent free operating system and have fun doing so. The leader's task is to keep that vision alive and vivid and to encourage people to want to go there.

Make Life better!

What leaders in voluntary projects can do and must do is to:

empower the right people to do work that fits their talents, motivations and temperament;
find and help other leaders on the way towards their fields of interest;
inspire people about where Debian, their subproject or small teams could and should go;
make their area of influence as fun, pleasant and rewarding as possible for people to work or dwell in;
make themselves redundant.

It will take time to gently introduce this in Debian.

Small Teams

Small teams are probably the single most important characteristic that a group like Debian needs to have to be able to grow in a healthy way. If done right they can solve many problems.

What small teams could do

They provide a smooth entry point for new people to learn the ropes and skills (NM).
They are the place where one can get to know people quickest and best (due to the small number of people in the group).
Due to the stronger social bonds in smaller groups the likelihood of people going MIA is much reduced.
People can form a knowledge pool when cooperating on package maintenance, infrastructural or organisational tasks, and that pool is less likely to get lost than a single person. This would make Debian more resilient against wild busses, unmaintained packages or head hunters.
Because these teams can grow and divide on their own, they are self-organizing and provide for very good scalability in numerical growth.
They serve as a sandbox for people to discover their inherent motivations, talents and temperament relevant to Debian work.
They make communication easier.

What small teams need to be like

For a team to be able to fully serve those functions it needs to have a couple of necessary features:

It must not grow too big (7 seem to be a sweet spot) or it becomes less personal.
Team members are aware that the group will divide itself after it grows past a certain limit and the opportunity arises.
The members of the team must be socially compatible (the basic chemistry must fit).
People must be able to have contact frequently (IRC would be good).
The team should not only concern itself with technical matters, but the whole human being. It should be possible to discuss TV series, politics or football, find friends or fall in love.
The team should be open for new people.
It should have a leader as described in Leadership.

Introducing such a small team organization into Debian takes time and is a gradual process. While group maintenance of packages is no novelty and normal teamwork does happen, this concept is more.

If you elect me to be your DPL, I will be in a much more effective position to advocate and implement such teams within the Debian project.

Working Climate

The attractiveness of a group depends significantly on the feeling of how welcomed, respected, and appreciated their members feel. Even though the word is incredibly hackneyed and frequently abused, I still want to describe the relationships we need as "loving" since it communicates the concept best. The quality of communication in groups is strongly correlated to this key characteristic.

Indicators

The tone of conduct in Debian is a good indication of how "loving" the people are towards each other. Is the atmosphere friendly and constructive, or caustic and corrosive? Humor, laughter and fun are the positive components which make a group a pleasant environment to be in. Random acts of kindness are possible in virtual communities as well and can even extend into Real Life.

Where it works better

Sub-projects which are smaller, more personal and where people meet regularly achieve a much better signal/noise ratio in communication and feel warmer than the big busy mailing lists and IRC channels Debian has.

Change is possible

It is possible to purposefully change relationships and the tone of conduct in Debian. We can inform people about basic group dynamics and help them to find better forms to express themselves. Everyone should learn when a mail or remark is not worth sending, for example.

Conclusion

What I propose in this platform is at the same time "radical" and "just common sense": most of it is about making Debian less stressful and more fun. The only changes that will ever be accepted are those that people want, in Debian as in other places where people are free.

I believe that these changes are so obviously good ideas that we want them, regardless of who will be elected as a DPL. Electing me is a way of showing that you agree, and to get started.

^[1] The FTP-Master confusion

For some time there has been some irritation, general flaming or even open hostility between FTP-masters and some other Debian developers regarding the job of FTP-masters and the way they think it is supposed to work. This is an example of negative working climate in Debian.

The situation has reached a dead-lock where one side demands transparency and accountability and the other refuses to comply as long as the climate remains hostile.

The multi-stage solution to the problem takes some time and will provide a long term scalable solution. I discussed it with some FTP-masters and individuals who could do the work. As an additional bonus it fits well with the "Small Teams" approach I will push elsewhere and resembles the release master/assistant and the AM/Frontdesk/DAM model that works satisfactorily already.

This is just one example of what I would do if I was elected DPL. While I can de-escalate and mediate already today, having the authority that comes from being the chosen leader of all developers is a help for leading this project to successful resolution of internal conflicts.

^[2] Release Delays

Debian needs more frequent, regular releases. The present delays cause frustration and a decline in morale in Debian country. To pave the way for a smoother development cycle and release process I took the initiative, acquired sponsorship (from NUUGF) and organized a meeting of the release team and FTP-masters taking place soon.

^[3] Real-Life Meetings

Besides being fun, meetings serve a few vital functions, especially for virtual communities as Debian:

They help people get to know the person behind the on-line persona, and have a better understanding of one another
They help to see the greater Debian community.
Real Life provides unparalleled bandwidth for communication, minimizing misconceptions.
People get newly inspired for Debian by meeting people and listening to good talks.
Group settings can be very productive for problem solving.

So while meetings themselves are not a goal per se, their results definitely are and have proven to be of high value to Debian.

^[4] Managing Growing Needs

Capacity planning is frequently a challenge for large organizations, and once you fall behind, it's even more difficult to catch up. A lot of Debian's hottest issues over the past few years have been capacity issues: making sure the autobuilder network scales to handle our package count; making sure the NM process scales to meet the number of incoming applicants; making sure the security team scales to handle the architecture count; etc. While many of these issues are largely technical in nature, the task of identifying and resolving choke points before they become a problem is one that requires managerial attention, and the DPL is best suited to provide this oversight.

Rebuttal

What has characterized this years platforms and campaigning seems to be that most candidates (Branden, Anthony, Matthew and also Angus) recognized the shortcomings on some social level within the Debian Project. The most obvious symptom they identified is the limited efficiency of communication on some of the projects mailing lists.

I take that as an indication that my approach to try to influence the social characteristics of the project actually is the right way to go.

What is different in my approach compared to theirs is that it will not only address one symptom of the problem by adding additional rules for communication within the project, but change the bigger context. By introducing conscious and empowering leadership, strengthening and expanding small teams, working on loving relationships and increasing frequency and quality of real life meetings, real change for the better can be achieved. In this context I would like to point to the very helpful question by Henning "[...] how will your being DPL make a difference [...]?" and my passionate answer to that.

All other candidates (besides Branden) seem to either underestimate the workload which the office of Debian Project Leader brought in recent years or will need to work on it full time. Our current Leader, Martin, is both highly intelligent and organized and still carried heavily on the workload, partly even neglecting his research.

The great option to rely on the DPL team would help Branden or me to both accomplish our respective goals and still stay sane in the process.

Branden and I were unable to identify areas where we are in profound disagreement. This is a good thing, since we intent to work on the same team. But we do have different priorities. While i intent to use the available powers of the DPL proactively to address everyday problems, I also strive for informal changes enabling the project to take charge of core social challenges while Branden proposes improvements based on greater process formalism.

Another way in which I differentiate myself from Branden is in how I engaged in active community building by my involvement in DebConfs and numerous other gatherings and development meetings.