I became a Debian Developer towards the end of 2018. I started the process in August 2017 at DebConf in Montreal. Over the course of 17 months I wrote emails, searched the Debian wiki, and learned a lot about the project.
What’s a non-uploading Debian Developer (DD)?
A non-uploading DD is one who does not upload packages to the Debian code base. A non-uploading DD:
- is member of the Debian project;
- is allowed to vote about issues regarding the whole project;
- can log in on most systems that keep Debian running; and
- has access to the debian-private mailing list.
Why become a DD?
I had two main reasons for becoming a DD: I was told debian-private was mostly vacation notices and baby pictures. I also wanted to vote in the DPL elections.
It turns out -private contains ZERO baby pictures, and choosing who to vote for in DPL elections is hard work.
There are other reasons to become a non-uploading DD. I found that the most compelling one, from my perspective, was the authority and respect that comes along with it. When representing the project, which I have done on several occasions, it’s easier to get things done when you have a title or formal affiliation attached to your name.
I joined the A-H team with the understanding that I would become a DD — they preferred someone with official status in the project be on that team. In addition to empty promises of baby pictures, I became a DD because I wanted to take on more responsibility in the project.
There’s also a certain amount of the feeling of belonging that goes along with becoming a formal member of a project. There’s a lot to say about the value of the recognition of your peers — that they consider you a part of the team.
What do you do for Debian?
I’m on the Outreach and Anti-harassment teams.
The Outreach team coordinates Debian participation in internship programs, specifically, and currently, Google Summer of Code and Outreachy. We participate in Outreachy twice a year, and GSoC during the Northern Hemisphere summer. This mostly includes a lot of paperwork, emailing people to make sure they’re on task, and talking with the home organizations of Google and Outreachy.
Since I do not mentor any projects, this work is fairly condensed, though very demanding. It’s time sensitive, with externally imposed deadlines not of our own creation.
During a period of several weeks — and application periods overlap in March — we:
- confirm with the Debian Project Leader funding for Outreachy;
- put our calls for mentors;
- assist mentors in finding co-mentors when appropriate;
- evaluate projects, separating them into “approved” and “unapproved” categories, based on whether they meet the Debian participation criteria;
- fill out the application forms for GSoC and Outreachy;
- make announcements, calls for mentors, calls for projects, and calls for applicants;
- field questions and requests from applicants;
- keep up with mentors during the application period;
- make formal decisions about the number of interns and who they are based on requests from mentors, available funding, and an amorphous process of reading mentor reports and trying best to judge who will not only be a successful intern, but who will be a successful mentor for a project;
- keep up with mentors and interns during the period of the internship;
- make sure everyone gets invoiced and paid appropriately;
- make sure everyone has a good time; and
- general other things as they come up.
As a total process, it’s quite consuming at times, but relaxed at other times. I would say that administering for Outreachy is an “easier” process, as the mentors are (generally, overall, usually) more experienced and self-managing. GSoC is also a much bigger program.
I could, and likely will, write a much longer post about this. I gave a talk at FOSDEM on the activities and operating procedures of the team. The quick summary is that we meet every fortnight, discuss reported incidents, and either: make recommendations to other teams about how to proceed or send personal emails to the individuals involved, pointing out inappropriate behaviors, and asking people to be more professional in their project participation.
What did your process include?
Mostly emails. A lot of emails, and back and forth with my AM (application manager). I’m sure many people say this, but my AM was great.
I went through the initial steps — deciding to apply after many, many people convinced me of the validity of my contributions to the project; getting my keysigned by an appropriate number of DDs; recruiting advocates for my application; etc.
Then came the questions and the tests. A big chunk of questions were around philosophy, policy, and procedures of the project. We covered licensing questions, the DFSG, the philosophy of user freedom, how different things within the Debian project are decided, and a bunch of other sections.
There where a technical section of my application, which covered more policy and procedure around how things are done within the Debian project. I worked on a bug (one on a piece of web site content) and submitted the edit on salsa, Debian’s instance of git. I collaborated in documents on storm.debian.org, logged into servers using ssh, and encrypted and decrypted a number of files over the course of the procedure.
Why did it take so long?
I started my application in August of 2017, and got my welcome email December 26, 2018. I joked that I was going for the longest application period.
It took so long largely because my AM and I were both very, very busy. When faced with free time, we both frequently agreed to make the decision to instead work on our respective Debian work, rather than the application process. I think I speak for both of us when I say we agreed a lot of the other projects we were working on were more timely than my application.
At DC18, I did a personal sprint on my application, and my AM kindly did a personal sprint reviewing it. We met over IRC to handle final steps later that fall. I finished in November, days before the November keyring update, and my application was reviewed in December.