Currently, the [Debian](http://www.debian.org) Project consists of two distinct classes of people - Users and Developers. There is a [Quality Assurance](http://qa.debian.org) group that exists to try to help bridge this gap, however it is not as strong as some people would like it to be. In many ways, a DID is another name for what Debian currently classifies as QA.

A Debian Integration Developer (DID) is a middle-person, someone to assist users and developers. From a [user](http://www.debian.org/support) perspective they answer, categorize and enhance bug reports with patches or Policy suggestions and generally help with user-level integration of multiple Debian software packages as installed. From a [developer](http://www.debian.org/devel/) perspective they update Debian specific package defaults and configuration systems. Upon reflection, this is also a group of folks that can be described as containing both Developer status (maintaining one package) and those who do not feel comfortable classifying themselves as developers. These groups share common goals.

Besides these two perspectives, there is also a range of tasks that fall into the domain of "[Quality Assurance](http://qa.debian.org)." Tasks necessary to perform on a range of individual packages such as Policy compliance checking, debconf use, /etc/alternatives and similar debian configuration mechanisms that integrate. The Work Needed and Prospective Packages system is an important function. Questions are sometimes raised regarding the diligence or MIA status of developers, in a way, ensuring the overall quality of the debian operational infrastructure. Gathering feedback from users and developers regarding enhancements and changes to these systems. Helping to Integrate the various infrastructure groups when responding to the environment in which Debian resides in is raising the quality of the organization. Many of the tasks that exist in this grey area can be accomplished by non-packaging maintaining users if they understand how Debian and package maintenance works.

The more I write and think about this area, the more clearly the concept of idealistic leadership is brought to mind. Yet keys to the success of Debian can be directly attributed to the lack of a centralized organizational structure and a strong set of negotiated policies.

Software dependencies can be very complex. There is often a need for a semi-knowledgable developer (DID or QA) to understand how things work best in a coordinated manner, how best to Integrate. This is also a natural path from which to recruit new package maintainers if assistance is provided along the way. Another separate group that subscribe to a [mail list](http://lists.debian.org) and perform this extremely valuable service is [Debian-Mentors](http://lists.debian.org/debian-mentors/).

Recognition for the significance of contribution is one reason to give this group of helpful people more courage and identity in helping the Debian project in a clearly defined and less daunting a way. The [devel](http://www.debian.org/devel) page has a link to a page describing [how you can help](http://www.debian.org/devel/join/). However this page is primarily positioned and recognized as a stepping stone into the [new maintainer process](http://www.debian.org/devel/join/).

Perhaps a little bit of this resides in all members of the Debian community and is an important ingredient to the project's overall success. This may be because the developers are in fact, also the users. This can be extremely demanding for new users of Debian. It does take time to come up to speed with what Debian is about, [who participates](http://www.debian.org/intro/organization) to keep it running as it does and what processes exist. The Bug Tracking System's [pseudo-package list](http://www.debian.org/Bugs/pseudo-packages) may give great insight into some processes.

-- [[Main/GrantBow]] - 25 Feb 2004