Debian developers have various responsibilities, and as official project members, they have great influence on the direction the project takes. A Debian developer is traditionally generally responsible for at least one package, but according to their available time and desire, they are free to become involved in numerous teams and projects, thus acquiring more responsibilities within the project.

Package maintenance is a relatively regimented activity, very documented, or even regulated. It must, in effect, comply with all the standards established by the Debian Policy. Fortunately, there are many tools that facilitate the maintainer's work. The developer can, thus, focus on the specifics of their package and on more complex tasks, such as “squashing“ bugs.

政策，是 Debian 项目中重要的元素，它是保障该发行版软件包品质与完美互通性的纲常。正因为有政策的约束，Debian 才能在愈来愈庞大的同时依然保持一致。然而，政策并非铭刻在石不能更改，要随着 debian-policy@lists.debian.org 邮件列表中型塑出的提案不断演进。修订案在所有关注的各方有所共识后，才会被一小群没有编辑责任的维护者编写 (他们只接纳前述邮件列表内众 Debian 开发者接受的修改提案)。目前臭虫追踪系统内的修订提案在此：

The Policy provides considerable coverage of the technical aspects of packaging. The size of the project also raises organizational problems; these are dealt with by the Debian Constitution, which establishes a structure and means for decision making. In other words, a formal governance system.

This constitution defines a certain number of roles and positions, plus responsibilities and authorities for each. It is particularly worth noting that Debian developers always have ultimate decision making authority by a vote of general resolution, wherein a qualified majority of three quarters (75%) of votes is required for significant alterations to be made (such as those with an impact on the Foundation Documents). However, developers annually elect a “leader” to represent them in meetings, and ensure internal coordination between varying teams. This election is always a period of intense discussions. The Debian Project leader's (DPL) role is not formally defined by any document: candidates for this post usually propose their own definition of the position. In practice, the leader's roles include serving as a representative to the media, coordinating between “internal” teams, and providing overall guidance to the project, within which the developers can relate: the views of the DPL are implicitly approved by the majority of project members.

特别地，领导人拥有真正的特权；他们的投票可以解决票数相等的问题；他们可以对某个尚未归属于任何人管辖名下的事件作出决定，同时可以将他们自己的一部分职责委托他人代为执行。

Since its inception, the project has been successively led by Ian Murdock, Bruce Perens, Ian Jackson, Wichert Akkerman, Ben Collins, Bdale Garbee, Martin Michlmayr, Branden Robinson, Anthony Towns, Sam Hocevar, Steve McIntyre, Stefano Zacchiroli, Lucas Nussbaum, Neill McGovern, Mehdi Dogguy, Chris Lamb, Sam Hartman, Jonathan Carter, and Andreas Tille.

宪章同样也定义了一个“技术委员会（technical committee）”。技术委员会的核心角色是对于那些在开发者之间尚未达成一致意见的技术事宜进行决策。除此以外，委员会则作为顾问角色，为任何无法为他们所负责的事宜作出决定的开发者提供帮助。值得一提的是，只有在相关问题方给委员会发送邀请时，委员会才会介入。

最后，宪章定义了一个“项目秘书”的职位，这一角色负责组织各种选举和决议的投票。

The “general resolution” (GR) procedure is fully detailed in the constitution, from the initial discussion period to the final counting of votes. The most interesting aspect of that process is that when it comes to an actual vote, developers have to rank the different ballot options between them and the winner is selected with a Condorcet method (more specifically, the Schulze method). For further details see:

Even if this constitution establishes a semblance of democracy, the daily reality is quite different: Debian naturally follows the free software rules of the do-ocracy: the one who does things gets to decide how to do them. A lot of time can be wasted debating the respective merits of various ways to approach a problem; the chosen solution will be the first one that is both functional and satisfying… which will come out of the time that a competent person puts into it.

这就是升级的唯一方法：做有用的事且显示把事情做好。Debian '管理' 团体以增选方式管理，采用已有效奉献且证明其能力的志愿者。新的奉献者看到这些团队做了具有公共利益性质的工作就会主动加入协助。这就是 Debian 常被称为 '任人唯贤'。

This effective operational method guarantees the quality of contributors in the “key” Debian teams. This method is by no means perfect, and occasionally there are those who do not accept this way of operating. The selection of developers accepted in the teams may appear a bit arbitrary, or even unfair. Furthermore, not everybody has the same definition of the service expected from these teams. For some, it is unacceptable to have to wait eight days for inclusion of a new Debian package, while others will wait patiently for three weeks without a problem. As such, there are regular complaints from the disgruntled about the “quality of service” from some teams.

有的人可能会感到奇怪，不明白为什么要在讨论 Debian 计划内工作的成员时加入用户。答案是确定的：用户在整个计划中扮演了关键的角色。其中不只有“被动”的角色，更有部分用户会日常使用 Debian 的开发版本并定期提交错误报告以指出软件的缺陷和问题。还有一部分用户会更进一步提出改进的意见，以“愿望清单（wishlist）”等级的错误报告阐述自己的观点，甚至提交对源代码的修改提议，或称为“补丁”（参见 第 1.3.2.3 节 “发送修复和补丁”)。

$ diff -u file.old file.new >file.patch

$ patch -p0 file.old <file.patch

From the start, Debian has been organized around the concept of source packages, each with its maintainer or group of maintainers. Many work teams have emerged over time, ensuring administration of the infrastructure, management of tasks not specific to any package in particular (quality assurance, Debian Policy, installer, etc.), with the latest series of teams growing up around sub-projects and blends.