Meeting the Debian Technical Committee

It is something of a DebConf tradition that members of the Debian Technical Committee (TC) take the stage to talk about the work that the committee does—and more. DebConf24 in Busan, South Korea was no exception, as TC chair Sean Whitton, who will complete his term at the end of the year, and one of its newest members, Stefano Rivera, described the constitutional underpinnings of the TC, how it tries to make decisions when it needs to, and the constant process of recruiting new members. After that, they took a few questions from the audience. The session provided a nice overview of the TC and its role in Debian, but it may well be of interest further afield.

The presentation was given by Whitton, who began with something of a "roll call", listing the eight current members of the committee. He also recognized and thanked former members, both those who had been appointed after the general resolution that limited terms to around four years and those who had served prior to that. There are some whose original appointment dates are lost in the mists of time, he said.

Powers

The powers that the TC has are enumerated in the Debian Constitution, specifically in section 6.1. The committee is tasked with making technical policy decisions for the distribution; the TC determines "how policy ends up shaking out in packages in the real world", he said. When developers' jurisdictions overlap, and they disagree, the TC can make a decision between them.

Normally, the TC is approached by both (or all) sides in a dispute, asking for a resolution to their disagreement. Sometimes, though, the TC has to decide whether to overrule a developer at the request of another. That requires a 3:1 majority vote in the committee, so it does not happen often.

In addition, the TC has an advice-giving role. The committee will often offer advice, rather than making a decision, especially if the members feel that it is too early to force a solution. Even if the dispute was not brought to the TC requesting advice, it often chooses to offer advice, instead of taking another course of action, Whitton said.

There are some constraints placed on the committee by the constitution as well. All of the discussion of an issue before the committee must be done in public, for one thing. The TC is meant to "choose between options on the table, as opposed to coming up with new ones", which is a "pretty significant restriction" because it means that if there are no good options offered, the TC has to bow out. The committee is only meant to be used as a last resort, but it has to decide "whether it is a 'last resort' yet, that's part of the challenge", he said.

Another constraint, which is sometimes surprising to Debian developers, is that the TC cannot override the decision of delegates appointed by the Debian Project Leader (DPL). So, for example, a dispute with the release team cannot be resolved by the committee, since that team is appointed by the DPL.

Interestingly, the TC is the only organization in Debian that can change the maintainer of a package; even if the Debian Account Manager (DAM) team determines that someone is no longer a member of the project, the developer can still upload their packages. But the TC never uses this power, Whitton said, which means that it is "this informally defined role of the 'package maintainer' who ends up having almost all of the power unless there is a relevant delegate". It is a somewhat odd consequence of the way the powers are distributed in the constitution.

Technical versus social

The TC is meant to "decide technical matters and not social matters, but that almost never happens"; things that come before the committee "almost always have a social component". The recent TC bug report around the question of distinguishing the testing and unstable versions is likely a case in point.

Ian Jackson wrote the Debian constitution as a graduate student in the 1990s, Whitton said; Jackson had this idea of separating technical from social, "but that doesn't work". The TC tries to coordinate with the DAM and Community teams to handle the social side of things but, each of the organizations has its own point of view, so it is difficult. This attempt to separate the technical from the social is considered by Jackson to be "a great mistake" in retrospect, Whitton said. There are advantages to the split, because some TC members, including him, would not be interested in serving on the DAM team, for example, "but it also causes us no end of problems".

There are some other projects that do not have that separation or have it to a different extent. He noted that Matthew Garrett, who is a current TC member, has also served on the Fedora Engineering Steering Committee (FESCo), which has a role in setting the technical direction of the project beyond the option-choosing role of the TC; he was not sure what role FESCo played in disciplining project members, however. The FreeBSD project has a core team that is elected for two- or three-year terms; it is "explicitly empowered to deal with issues that are both technical and social". Whitton thinks that Debian should perhaps look at other projects for ways that it could improve its situation with regard to the intertwining of technical and social considerations in intra-distribution disputes.

Over the four years or so that he has been on the TC, it has considered changing how it does its work, but its members do not want to do so unilaterally. The project as a whole should be involved in any kind of change like that. Meanwhile, the members of the committee are also busy with the day-to-day work of the TC. He is not quite sure where that should lead, exactly, "but that's the situation".

To summarize, the TC is meant to break ties when solving the problem by consensus has been tried and failed; it can also offer advice. It is a "self-nominated, DPL-appointed, last-resort conflict resolution and advice-providing body".

Decisions

Whitton went through the items that the TC has considered, or decided since the last DebConf. Two of those were procedural in nature: recommending Craig Small for the TC and re-electing Whitton as TC chair. Whenever the TC changes, as it did when it added Small, the chair resigns and a vote is taken on a new one. As can be seen in the TC-chair "bug" thread, there are plans to transition to a new chair sometime well before Whitton's term expires at the end of the year.

The TC bug filed that asked for a reconsideration of merged-/usr was considered and rejected. In another procedural decision, the committee repealed its moratorium on moving files to /usr. Another bug was a request for advice from the TC on a "pretty complicated issue about a couple of interacting packages"; the committee discussed it and supplied advice. From the bug, it would seem that the packages supply different versions of the same file.

There were also three bugs that were closed without a resolution; two of those were closed "because we thought they were premature", since there were no options to choose from and the process of finding consensus had "not been tried hard enough" (1052460 and 1052697). Another, 1065170, "resolved itself while we were still talking about it, so that's always nice".

There is one open issue, 1065416, which is a "classic overlapping-responsibility issue", Whitton said, where the owners of two packages disagree about "who has ownership over an API". The committee is trying to mediate and is hopeful that the problem can be solved without a formal resolution by the TC.

New blood

He turned back to term expiration, noting that the algorithm for who expires and when is a little complicated in order to ensure that no more than two people can expire at once, he thinks. The slides and WebM video of the session will show the list of expirations that he created; the upshot is that there is a need for one or two new people for the committee every year.

In fact, the committee spends a lot of its time recruiting new members, Whitton said, because a lot of people do not want to do that work. "We wanted to say that it is not as bad as people sometimes think it is". For one thing, not every issue is like the init system decision (which was resolved by the TC in 2014, but has cropped up multiple times since then). For another, given the existing structure, there is not all that much that the TC can actually do, which may be a different problem, he said, but it does keep the workload manageable.

The TC meets once a month for an hour, generally on IRC; "we look at each open issue and see if we can move it forward". Based on that, assignments of various tasks are made to members to try to take those next steps. The work gets divided pretty evenly between the committee members and the intent is to make steady progress. Sometimes there is a lot of email to read, but since the TC works as a group, the focus of the work is in the meetings; that may mean that the committee moves too slowly, but "that's the reality of it". There are a number of skills needed, "given that it is mostly about resolving disputes", but they mostly boil down to dealing with the people involved in good faith.

There is a need for more diversity on the TC, he said. On the train that morning, he was chatting with someone who had turned down a nomination to the committee, in part because of the amount of English-language writing that gets produced for disputes that the TC is handling. While that's true, Whitton said, it means that only people from English-speaking cultures end up on the committee, "which sucks". In truth, he thinks that "all of Debian should probably write less", but if the volume was reduced for TC disputes, in particular, that might lead to more people being willing to join the committee.

Debian members can nominate themselves or someone else for the TC. The self-nominations are preferred, mostly because it is clear that the person is willing to serve; nominating others means the committee has to check with them and "they often say 'no'". Normally, the committee members are deciding between three people or so each time, but it would be better if it could be five or six candidates, say. Those who are not recommended in a given year are often asked to return the following year, which works out well.

Questions

DPL Andreas Tille opened up the Q&A section by thanking the TC members for their hard work; given the technical-social overlap, he wondered if it made sense to have a "Debian Social Committee", which had been brought up in the debian-private mailing list along the way. Whitton said that, in theory, the Community team is meant to fill that role, though its former name, the Anti-Harassment team, points to the focus of the team. He reiterated that he thought Debian should look at what other projects are doing to try to learn from their experiences. Rivera added that the issues that reach the TC are really about a lack of ability to communicate between the parties; there is never a situation where there are two perfect solutions, so it should be about finding some middle ground, but that is obviously failing in those cases. All of that is inherently social.

An Ubuntu member in the audience offered to explain that distribution's ways of handling conflicts of this nature. There is a community council and a community team at Canonical, with some structures and procedures about how they operate, he said. Whitton and Rivera agreed that a discussion of that sort would be helpful.

Junichi Uekawa said that he might be interested in volunteering, but wondered how much work it entailed. Once a month sounds reasonable, but "do you have to read like 1000 pages" every month as well? Whitton said that the committee "asks people to summarize, we're generally not willing to read the entire dispute"; each side is expected to provide a summary of the dispute from their perspective, "so it's not that bad". What is needed is people who can jump into a discussion quickly when it arises, which might require "a few hours in any given week".

Rivera said that TC bugs "tend to come to the committee with a lot of text"; the submitter typically tries to explain why they are bringing the issue to the committee "and that means a long read". There are usually relevant mailing-list threads, as well; waiting for the members to read all of that would significantly slow things down. Fortunately, he said, it is often the case that one member researches the problem for the committee, and then condenses out the potential solutions for the others; they become something of a subject-matter expert for a given dispute. "No one on the committee expects anyone else on the committee to read everything", Whitton said; "it would be impossible", Rivera finished.

Former DPL Jonathan Carter noted that Whitton had mentioned some areas of difficulty for the TC and, perhaps, indicated some level of unhappiness with how the committee, and the distribution as a whole, are working. Given the opportunity, would Whitton "fix a few things in TC or, rather, start the discussion to redesign what our top-level problem-handling methods are?" Whitton said that "no one is happy with Debian's governance, right? We're really bad at making changes and we all know that we need to make changes."

He said that he is no expert in governance; if making changes was up to him, he would try to become an expert by looking "at what everybody else does and see what works and what doesn't work and try to integrate it with our stuff". He would not be comfortable making any recommendations before doing that research.

Rivera said that Debian is different than other distributions in that it does not have a corporation providing overall direction, so "we are largely rudderless". Occasionally, a DPL candidate will have a technical goal as part of their platform, but "a lot of the project looks down on that" and prefers a more administrative DPL. Without some kind of constitutional change, the TC cannot provide technical leadership for Debian and "I'm not sure that having some graybeards drive the direction of the project is what Debian wants".

With that, the session ran out of questions and/or time. The talk definitely gave a nice look inside the TC and some of the challenges it faces. In keeping with Whitton's interest in seeing what other projects are doing, this presentation can perhaps return the favor; one of the most obvious benefits of governing in the open is in sharing the successes and failures between projects. It is, effectively, applying the principles of FOSS to project governance, so projects can learn from each other—both for code and organizational matters.

[I would like to thank the Linux Foundation, LWN's travel sponsor, for its assistance in visiting Busan for DebConf24.]