On extending Debian membership to non-programming contributors

August 3rd, 2010 by lucas

Stefano raised again the issue of providing some kind of Debian membership to people that contribute to Debian in unusual ways (not involving deep purely technical skills), like doing translation, documentation, marketing, design, etc.

Each time this discussion comes back, people seem to think that we need another membership status for them. But what for?

It’s true that the name “Debian Developer” is suboptimal for non-programmers. But it’s also suboptimal for most DDs, since most of us don’t strictly develop software: we “just” maintain packages, mainly developing meta-data around the upstream source code. “Debian Developer” is how we call our full-fledged project members. Do we want to classify those non-programming contributors as second-class citizens? If not, we need to make them “Debian Developers”, not some strange other name.

Of course, there’s the issue of security and trust. Debian Developers have upload rights on all packages, and access to the project’s machines. And it’s a bit strange to trust non-programmers with that level of power. On the other hand, we have many Debian Developers that are mostly inactive, became DDs half a decade ago, and have the same access rights. Worst, it’s possible that they remember how to use dput, having used it before! And 95% of DDs (me included) should probably not be uploading the libc, even if they can. Why should they be more trusted than active non-programming contributors that probably would be quite scared by the idea of breaking something?

Overall, I think that this issue is actually a non-issue. We should:

  • Acknowledge that, when a non-programming contributor has made notable contributions to Debian (proven by the advocacy of current members) and passed the relevant parts of the Philosophy and Procedures check, it should be made a Debian developer.
  • Orthogonally, acknowledge that we have a problem with security due to the size and the volunteer nature of the project, and address it independently. For example, shell accounts could be disabled after 3 months without connecting to Debian machines (and be re-enabled by the DD on http://db.debian.org/). And upload rights could be limited to non-core packages (and extended by the DD on http://db.debian.org/ too). It’s not about adding intermediate levels of membership, just about giving the possibility to developers to add a safe-guard against themselves.

9 Responses to “On extending Debian membership to non-programming contributors”

  1. Giovanni Mascellani wrote on 08/3/10 at 11:08 am :

    +1 for the safe-guards and for having easier people exchange in the project (making the life easier for who works and wants to become DD and having stricter policies for inactive people).

    For example, I also would like to give people voting powers for GRs only if they’ve made some contribution in the past, say, 6 months. I fully understand and have nothing against who decides not to contribute anymore to the project for personal reasons or choices, but having many people marked as active while being inactive effectively is a weight for Debian social and decisional processes.

  2. Richard Hartmann wrote on 08/3/10 at 11:09 am :

    I am not a DD or even a DM, but fwiw I agree with everything you said.

  3. Patrick wrote on 08/3/10 at 11:11 am :

    Lucas, I can mostly agree with you. But I must note that I even don’t really get the idea of the people who think that the term Developer is wrong:

    A Developer is factual not the same as a programmer. The term “Developer” derives from development which is defined as “the act or process of growing, progressing, or developing”. Basically this includes everything which makes Debian progress. Documentation, translation, even system administration of the project machines IS something which contributes to the progress of Debian. So as long as a Debian member somehow contributes to Debian the term Debian Developer is actually the right term.

  4. anon wrote on 08/3/10 at 2:18 pm :

    +1, as Giovanni wrote, a dormant DD affects decisional processes.

  5. Lucas wrote on 08/3/10 at 3:47 pm :

    @Giovanni & @anon: I don’t think that dormant DDs are a problem for the decision process. We have enough active DDs to prevent the result of votes to be affected by inactive DDs who would choose to vote. Also, voting is not mandatory in Debian, and I think that people who are inactive or do not feel well informed about a particular vote are likely to choose not to vote.

  6. Tshepang Lekhonkhobe wrote on 08/4/10 at 12:37 pm :

    @Patrick: great comment!

  7. K.S. Bhaskar wrote on 08/4/10 at 6:36 pm :

    Spot on, Lucas.

  8. Martin-√Čric wrote on 08/6/10 at 1:45 pm :

    Personally, I have problems with the NM process per-se, because it gives too big of a voice to anyone who might have a personal issue with someone’s application, without even demanding that those detractors explain themselves. In my case, most people who opposed my application did it with a very abstract “I don’t like his attitude. If anyone wants to know why, ask me on debian-private” and very few of the others had anything substantial to support their position. IMHO, people who act so childishly that they put personal issues in the way of Debian’s better good ought to lose their DD status, but few people seem to agree.

  9. Saint DanBert wrote on 08/16/10 at 6:18 pm :

    Folks,
    The most important non-coder contributors create documentation for end-users and application administrators. Projects need to encourage these people to participate and contribute and “membership” is one good way to recognize them.

    I cannot report how many times I have read that documentation is woefully behind compared to the state of code development and deployment. As someone who would eagerly contribute writing skills to projects, I have heard the same story from several project teams. I paraphrase saying, “… we are too busy getting code to work to explain things for documentation … and we know it will likely change before we are finished …” After 30 years as a developer I understand this sentiment. However, this approach seems perilously close to a tinker-til-working method instead of create-and-build-to-design.

    We are out here. Use us.
    ~~~ 0;-Dan