Guidelines for Debian internal teams

This document tries to summarize good behaviours that will make a team more effective within Debian in the long run.

Communication

If you have a private email alias as point of contact, you should make sure to answer most of the mails within reasonable delays (1 week).
- Don't fear to say "no, we won't do that because...". It's far better than no response at all.
- Don't fear to say that you don't have the time to implement the request. Seek for help in that case, try to tell the requestor how he could help you. Register the request in your request tracker at the same time.
- Tip: Don't delete the email from your inbox until someone has replied. Have a discussion within the team to make sure that one person does this at least. Periodically review the messages without answers and take the time to reply, if someone else should have replied, ping him/her at the same time.
A public dedicated IRC channel is almost always a good idea. It's particularly interesting when you face many small support requests. You'll have permanent members that will gain knowledge from your answers and answer for you when you're not available. It's time saved for you, because those people would have mailed you otherwise.
If you find out requests concerning your team in debian-devel@lists.debian.org or debian-private@lists.debian.org, reply and indicate where they should have directed their request.

Create a FAQ with answers to most common requests. Point people to the FAQ whenever you have an occasion. If the FAQ is in the wiki, ask people to update it with the information that you provided them.
- Include in the FAQ information on how people can help you. Point them to the VCS that you use.
Try to create some internal documentation documenting your processes, your past choices, and any complicated setup.
- An internal changelog file is a good start.
A team that works is able to assimilate new members quickly. It means that non-members have access to enough information to get their hands dirty and start helping. It also means that you should reply to people who are trying to help out. Ideally, once a new member is integrated he gets access to the remaining of (private) documentation and can be quickly effective.

Document your team in http://wiki.debian.org/Teams
- Use this space as your official web page if you don't have another dedicated presence on the web.
Make sure that the information on http://www.debian.org/intro/organization is up to date.
Setup a public request tracker. You can use a pseudo-package on bugs.debian.org, a dedicated request-tracker queue on rt.debian.org, or a tracker on an Alioth project.

It's best when someone is leading the team. Usually this happens naturally, the one that does most is usually the leader. The leader doesn't dictate everything however, he merely pushes forward the agenda of the team. He creates the consensus and nudges kindly the other members to do their share of the work in that direction.
If you're the de-facto leader and decide to change your priorites in such a way that you can't continue to assume the lead, inform the other members and get them to take over your responsibilities.
Be honest and recognize when you're too busy to assume your responsibilities. Pick your favorite in the list of people who recently helped and ask her if she would like to join the team. Propose more rights/responsibilites to any "assistant" that you might have already recruited in the past.