Contributing to the project

If you would like to contribute to the Debian project, you will not have a difficult time finding areas in need of help. Since the Debian system is continuously work in progress, it is almost impossible to identify the areas in most need of help. In general, the rule applies that if something is broken, you can contribute by fixing it, and if something is not perfect, you can contribute by improving it.

Always keep in mind that Debian is a meritocracy (see chapter 2.4.3): you step up the ladder and gain authority through work and reputation. Therefore, the road ahead may be a little rough. It is probably a good idea to start small and to make sure that people know you as someone who does what they promise to do and in a timely manner, and as someone skillful enough to produce quality work. With that said, do not forget that Debian is about volunteer work, and that whatever you do should be done because you enjoy it. Nobody will tell you what to do, so you are completely on your own as to how spend your time.

Feedback

Probably the most significant form of contributing to the project is through con-structive feedback. If you run into a problem and you have the time and means to investigate further, please do. If you think you have found a problem, do not hesitate to put your findings into a bug report (see chapter 10.6.5). You may be the first to stumble across a problem; by helping to fix it, you are helping others to avoid the pitfalls. Alerting the maintainer to a problem and offering to help with narrowing it down goes a long way towards fixing it. The free software community depends on the continuous flow of feedback to maintain its progressive bearing.

Alternatively, do not hesitate to participate in discussions on mailing lists and in discussion forums (see chapter 10.4). When developers need to make decisions, your input can help to improve a product.

User support

On the topic of mailing lists, an equally important domain for contribution to the project is the support of users in these forums. If you can spare the time, listen in to the problems of other users and provide advice if you can. Any constructive

59http://www.debian.org/devel/join

help on mailing lists such asdebian-userwill be greatly appreciated. Moreover, fielding questions on such a list can produce incredible learning effects: while you will have little to contribute in the beginning, your expertise will grow as you read what other people have to say. Over time, you will be able to provide valuable information on an ever increasing number of problems. At the same time, you are becoming more and more a master of your own system.

Quality assurance

A large part of Debian’s reputation is quality. Maintaining the high quality of the operating system is a never-ending task. The quality assurance team is therefore grateful for any help it receives. Quality assurance mainly entails working on exist-ing bugs, but extends to package adoptions and testexist-ing of software and filexist-ing bugs accordingly.

If you choose to contribute in this field, you choose to improve free software as a whole. Perhaps the best way to start is to pick a few packages of software that you use often and which you know fairly well. For each of these packages, pull up the corresponding page on the Package Tracking System (PTS)⁶⁰(see chapter 10.6.9) and check the to-do and bug lists. You may want to let the maintainer know what you are doing, but otherwise there is nothing to keep you from taking a stab at addressing to-do items and producing patches for the open bugs. Please make sure you read chapter 10.6 and in particular chapter 10.6.10. If a package’s maintainer appreciates your work and you manage to build up trust, this is your chance to become a co-maintainer of a package that you use often.

Rather than concentrating on single packages, you may also wish to simply attack the show-stoppers of the nextstablerelease: the release-critical (Release-Critical (RC)) bugs. The coordination page for release-critical bugs is available online⁶¹, as is a general overview of the current situation⁶².

Another way to help out is by selecting older bugs and reproducing them; maybe certain problems do not exist anymore in current versions; maybe you can analyse other problems. In all cases, make sure you send your findings to the BTS. If a bug exists in a package’s version instablebut not in itstestingversion, set the appropriate tag. And if a bug has disappeared fromstable, you can close it (see chapter 10.6.7).

As an alternative, you may want to help with maintenance of a package. On its web page, Debian maintains a list of packages in need of help⁶³. Packages that are in need of a new maintainer (up for adoption, or orphaned) may be worth the effort. On the other hand, if you prefer the challenge of a new package, you could

60http://pts.qa.debian.org

61http://bts.turmzimmer.net

62http://bugs.debian.org/release-critical

63http://www.debian.org/devel/wnpp

consider attacking one of the requested packages, or prepare a software that you would like to see in the Debian archive for its inclusion (see chapter 9). Another kind of challenge are packages marked as needing help. In these cases, the current maintainer intends to continue as maintainer but seeks additional people to assist.

Documentation and localisation

If you are less technically versed but enjoy writing, then maybe you can help to im-prove documentation, both of packages as well as the documents available as part of the Debian Documentation Project (DDP) (see chapter 10.2.1). While changes to the documentation of single packages are best coordinated with the individual maintainers, the DDP documents are available via CVS⁶⁴.

Another domain in continuous need for help is localisation⁶⁵; in the interest of non-English-speaking users, software, documentation, and web pages should be available in as many other languages as possible, and each localisation should be of acceptable quality and up-to-date. Translations are coordinated via the Debian international pages⁶⁶. The procedures (which should be followed) are specific to each language group. Interesting references related to localisation include chapter 8 of the Developer’s Reference⁶⁷and the “Mini survey of localization in Debian”⁶⁸.

Testing

By running the Debian system, you are also testing it to make sure that it works and meets up to its quality standards. However, chances are that normal use will not find obscure bugs or uncover problems that taint the quality of the operating system. Thus, if you have some time to spare and ideally possess a system to experiment, you could try hard to break things on the Debian system which should normally stand up to the stress testing. In addition, if you have special hardware (such as a system with a less-common architecture) or infrastructure, concentrate on related areas. Ideally, you should be runningtestingorunstablesystems for the experiments. If you find a problem, make sure to check the BTS for whether a corresponding bug has already been filed. If not, read chapter 10.6.5 and submit a problem report.

64http://cvs.debian.org/?cvsroot=debian-doc

65Localisation is often abbreviatedl10nas there are 10 letters between theland then(a convention started in the mid-eighties at DEC). Internationalisation (i18n) is a related term, and often the two are confused. Internationalisation involves enabling a software to deal with different regional settings (“locales”) and provides hooks for translations. Localisation is then the actual process of adding support for a specific region and/or language to the software.

66http://www.debian.org/international

67http://www.debian.org/doc/manuals/developers-reference/ch-l10n.en.html

68http://graal.ens-lyon.fr/˜mquinson/debian/l10n-survey

Some of the most important areas in need of testing are the Debian installer and the upgrade process. While problems with the former may put off new (or exist-ing) users, failures during the upgrade process can be fatal on production systems.

Therefore it is of utmost significance to walk through the processes multiple times, ideally not following the paved path at all times; experiment, try something new, try to make it fail. And if you succeed, analyse the problem and write a bug report (see chapter 10.6.5).

Security updates

When a security problem is found, it is in the interest of the user base at large to have the problem fixed as soon as possible. While the Debian security team works hard to make this possible, it needs help at times to manage the load of work that comes with the task of security support. Principally, you can help in two ways:

First, you can keep your eyes open and make sure that the security team is aware of new problems as they appear. The team reads the common security announcement forums, so it is not necessary to forward every announcement immediately. How-ever, if you are aware of an outstanding issue and waiting for the security team to take action, it does not hurt to inquire about the status. Please make sure you follow the advice given in chapter 7.1 pertaining to the choice of medium for such inquiries as some security issues may need to be handled non-publicly.

The second way to help the security team is by offering your help in finding solu-tions to problems, and backporting fixes to the version currently provided instable.

If you are serious about helping out in this area, please let the team know and make sure you let actions follow.

Development and improvement

Several components of the Debian system are aged, and while they still do their job just fine today, they need to be improved to be able to meet up to tomor-row’s increased requirements. The main examples here aredpkgandAPT, which are both rather slow and lack consistent support for important extensions, such as cryptographic signatures fordpkg(see chapter 7.5.3). Other fields in need of improvement that come to mind include optimisation of the boot initialisation se-quence (by introducing policies and dependencies; see chapter 6.3.1), and a mod-ular rewrite of theifupdownsystem (see chapter 6.8.1; thenetconfproject has been started onalioth.debian.orgwith this goal.). Plenty other possibilities exist, and Debian maintains a list of to-do items online⁶⁹; find your own niche and start working!

69http://www.debian.org/devel/todo

Infrastructure

Several core components of the Debian project are the work of single developers;

the BTS (see chapter 10.6), the PTS (see chapter 10.6.9), and the developer packages overview⁷⁰are just a few examples. These components exist because their authors lacked their functionality at one point in time and decided to change that. If you are looking to provide similar tools but do not know where to start or what to implement, maybe tuning in to thedebian-develmailinglist and reading along for a while will spill a hint.