1.社区中的常规事务由个人申请，申请到的人全权处理问题。
    2.在申请前，需要在社区公共平台呼叫请求。大致类似于"我要做某事了，有没有人在做或者能够提供帮助，请联系我"。
    3.如果有人对贡献者所做的工作有异议，可以请求修改或者复议。
    4.如果仍旧不满意，可以申请替换贡献者。经过全社区成员投票后就会变更贡献者。
    5.如果不能明确归属的事情，或事情本身就比较重要，则由全社区成员投票。
    6.如果具体操作者在不确定做法的时候，可以发起讨论和投票，获得社区意见。

    为什么社区通常具有以上工作模式？
    首先，社区的原则是自愿。通常社区是不会为个人的工作支付薪酬的。因此，谁愿意做什么事情，做到什么质量，完全是不可控制的。这也就是为什么社区事务是由个人申请的，因为并不能向社区中的具体人员指派工作。当一个问题比较严重的时候，也只能由资深社区人员呼吁有没有人志愿解决，而不能强行分派。这是社区为各个软件公司所诟病的特性之一。
    为什么申请前需要在公共平台呼叫请求？这样首先防止了工作冲突。尤其是上游发行一个新包的时候，如果没有呼叫请求(debian社区好像叫做ITP)，就会出现两个打包者重复工作的问题。其次，如果前任因为某些因素放弃了继续处理，也许他能给你一些额外的帮助。尤其是兼容性问题上的帮助，这样比较有助于保障一致性。
    为什么通常事务由申请到的人全权负责？因为一个事务会牵涉到非常多和复杂的细节问题。例如一个包的临时文件位置是使用/tmp还是/var/tmp，依赖库是使用gcc4.1还是gcc4.4。这些细节问题要一一搞定，社区没有那么多时间。如果志愿者是个熟练的人，往往问题的决策会采用比较通用的方案，社区会无条件接受志愿者的方案。当志愿者的方案比较糟糕，或者至少说有待推敲的时候。如果有人用的不爽，就会提出异议，或者更进一步提出解决方案。如果没人关心，那就让他去了。
    为什么对于仍旧不满意的问题，只能替换贡献者，而不能强迫贡献者接受方案呢？因为，上文阐述了，贡献者是出于自己的自愿，来帮助社区的。强迫他们接受某个他们所不习惯的想法首先并不尊重他们，招致他们的强烈反感。其次，这些方案可能扰乱他们的工作思路。所以从这个角度来说，当志愿者愿意接受你的方案时自然好说。而如果万一他不接受，要使得自己的想法实现只有让全社区基本同意，你，或者其他人接替这个志愿者的部分工作。
    为什么社区在决定性的问题上，采取贡献者民主投票的方式呢？因为，如前我们看到，社区的发展是每个贡献者提供自己的力量共同发展的。这样的社区一定会有不协调的情况。而让冲突升级，导致社区分裂，是不利于社区发展的。可以看到，社区是要讨好贡献者的。更多，更强力的贡献者，社区就能够有更好的发展。所以，采取民主投票的方式，是征求最多贡献者的同意，让他们支持社区，愿意继续为社区作出贡献。并且期待不同意的贡献者，能够理性的作出一定妥协，接受社区的大多数意见。
    当然，由于意见未能统一而倒置社区分裂的情况常有发生，尤其是社区同时拥有两位强势的领导的时候，并且他们的意见碰巧相左的时候。但是在大多数时候，贡献者会考量，自己是否值得为了某个意见放弃整个社区。考量的结果往往是接受社区的结论，但是保留自己意见。这种行为会保留社区中最多的人，并且可以期待剩下的人能够接受。这一原则，我们称为"尊重大多数贡献者"。而社区中，部分事物自主可决定的规则，只是因为社区假定你的行为会被大多数贡献者接受。
    我们可以看到，社区在发展中采取了很多自主判断假设和市场机制。社区需要假定你的行为是被大多数贡献者所能接受的。社区假定你能够分辨什么是"比较重要"的事情，从而需要征求多数意见。什么是你不需要劳动社区帮忙的事物。在正常的世界中，我们的假定通常都是成立的。debian社区大部分打出来的包并没有人提出异议。对于社区中文名定名或者下一开发版代号之类的问题，通常也是社区协商确定后再行处理的。因此，我们的社区通常工作良好。但是在某些特例下，例如有人无法理解什么问题是重要问题，哪怕大多数的人对这个问题的认识并没有困难。或者，更进一步说，有人捣乱。在这些特例下，社区往往会陷入一种比较混乱的状态。国外经常有所谓"民主效率低于专制"的结论，就是这个现象的集中爆发和体现。