- Why should you contribute to Debian?
- What do you want to do?
Contributing to Debian isn't as hard as it looks. There are many ways to make a difference, but it's sometimes difficult to find your way. This page tries to give directions.
Why should you contribute to Debian?
If you are reading this page, you are probably already using Debian, so you already know part of the answer. For a developer, Debian is really a fantastic project to work on. Debian gathers more than 500 active developers and many more contributors from all over the world (see this map), all dedicated to building a high-quality, free and universal operating system. Debian Developers are volunteers (the project is totally controlled by the Developers) and form a friendly and welcoming community (pictures from the past annual DebConfs are a good proof of that).
Inside Debian, it is possible to work on very different aspects (and to work on several of those at the same time). You could work on low-level stuff while helping porting Debian to exotic architectures (Debian supports more than 10 architectures), or package the next cool scripting language. You can work on server stuff, or desktop stuff. You can also work on things that are not stricto sensu programming, like translations (Debian's installer supports more than 60 languages). In short: join Debian, you can always find an interesting project inside it!
Is the Debian Project a home for my programming skills?
You should ask yourself this, while reading Why Debian for Developers?
I am not a programmer. How could I help?
What do you want to do?
You want to work on a specific package (or some specific packages) already in Debian
Many packages are maintained by teams. There are teams for games, GNOME, KDE, Python, Ruby, fonts, ... Most teams are listed on the Teams wiki page. If the packages you are interested in are already maintained by a team, it's easy: just contact the team members and see how you can help. Teams usually welcome new contributors, and are very responsive.
Some packages can have a RFH (Request For Help) bug report open, you can see a list of them here and contact the maintainer or team in charge for that to verify current status.
If the package you are interested in is not maintained by a team, it might be harder. While many maintainers are very responsive, and will welcome your help, some maintainers might be too busy or inactive, and might ignore your help. Don't allow this to discourage you!
You want to package new software for Debian
You can maintain packages in Debian, even without being a Debian Developer (your uploads will be sponsored by a Debian Developer). You have to read the documentation (start with the Debian New Maintainers' Guide and the Debian Developers Reference), then prepare your package, and finally, to find a sponsor. Be aware that finding a sponsor is a very difficult step: this is a big bottleneck in Debian currently. So it is important to make your sponsor's task as easy as possible, by preparing a perfect package
If your package could be maintained by a team (list of teams on the Teams page), it is a very good idea to contact it. They could help you with specific problems, and it will probably be easier to find a sponsor inside the team.
You want to improve Debian in general, not focus on a specific package
There are many ways to help Debian without focusing on a specific package, like Quality Assurance (-> how to help the QA team), translations, documentation, ... but the easiest one is to help with bugs. Most newcomers in Debian don't understand how central the Bug Tracking System is. Actually, it's where most of the interesting stuff happens.
When looking for a bug to fix, there are several things to consider:
- The bug shouldn't be too hard to fix. Debian has some very difficult bugs, and it's probably a bad idea to start with those! The only way to avoid those is to not discourage yourself if you don't manage to fix a bug. Just send a mail to the bug summarize your progress (if you made some), and move to the next bug.
- The bug should be in a package that is actively maintained, or serious enough to get someone else interested in fixing it. If the maintainer is inactive, your patch might sleep on the Bug Tracking System for months, which is not very interesting for you. However, Release Critical bugs have a relaxed NMU policy (the rules for someone else to make an upload are less strict) so, if you fix one of those, it will be reasonably easy to find a sponsor for your upload.
To help you, some lists of bugs are available:
You want to work on the Debian infrastructures and/or improve a Debian-specific program
This is a quite different task and requires advanced skills: it is generally intended for mature developers and possibly people with a long experience in Debian and development. Consider that contributing on those sub-projects is generally for brave hearts and there is not a defined roadmap for entering some teams and/or contributing on some projects. The general rule is coding before talking. Show us the code and you have some chance that your contribute could be considered. In many cases the starting point to contribute to some key software is fixing long due existing bugs of that software, for instance. The same rule applies to maintenance of infrastructures: admission to some managing teams is governed by rules established by the team themselves and you should contribute with very basic and annoying tasks before being officially admitted to contribute. That is the way it works.
We used to have a general TODO page on the main website, but including here interesting tasks by our teams should now be considered best practice. What follows is a list of possible contributing areas with references to starting points for working on them. It is neither exhaustive nor complete.
Please, list here tasks and programs that need contributes or help, along with how contacting the relevant team. Possibly add a RFH bug issued by the team which is in charge for the task. If the team is listed in the Team general page use that reference, else consider to add/update that page.
The Debian developers can enter geographic coordinates on the developers' database, but right now they are not used for much, and this should change. They should be able to get a list of distances to other developers, but more accurate and with names and details. The goal is to obtain a tool to easily exchange OpenPGP keys between developers when going on vacation, or to sign new developers' keys. Coupling the tool with the new maintainers database, with a map generation tool, or (non-exclusive or) with time-domain location (to put in contact journeying developers) would be interesting improvements.
A lot of the Debian Documentation Project manuals seems to be dead. Some of them are not maintained any more, never finished, never started etc. When not dropping the whole thing it would be a good idea to work on these manuals since they have the power to help people working with our software distribution.
Debian News is missing frequent updates due to lack of contributors. They need some people who keep in touch with mailing lists and news websites to help in the weekly redaction of what's happening in the Debian world.
The Debian website is maintained by a few people basically. For such a large project (entire source: 64MB, plus documentation) this is not enough normally. The website could be improved in several ways, some of them are written down in our todo list, some are not. It would be a good idea if somebody would see how the entire website could be turned into a single layout instead of three or more different layouts. Reviewing, updating and creating of new documentation would also be helpful. Have a look to the webmasters team page.
The Debian Description Translation Project aims at translating every single package description in the distribution, to help in package selection by non-English speakers. The DDTP is always in need of translators and reviewers.
Dpkg and Apt are two core programs for Debian, but very few people are in charge to manage and improve them. Dpkg has more than 400 bugs open, Apt has more than 700 bugs pending: even if many think that both those programs are good enough for use, there is clearly space for improve their status. Good C/C++ knowledge is required.