Alih bahasa: English

Pedoman untuk tim internal Debian

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

Komunikasi

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).
- Jangan takut untuk mengatakan "tidak, kami tidak akan melakukan itu karena ...". Ini lebih baik daripada tidak merespon sama sekali.
- Jangan takut untuk mengatakan bahwa anda tidak memiliki waktu untuk melaksanakan permintaan tersebut. 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.
Sebuah channel IRC publik hampir selalu merupakan ide yang baik. 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.
- Masukkan dalam informasi FAQ tentang bagaimana orang dapat membantu Anda. Arahkan mereka menuju VCS yang Anda gunakan.
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.

Dokumen tim Anda dalam http://wiki.debian.org/id/Teams
- Use this space as your official web page if you don't have another dedicated presence on the web.
Pastikan bahwa informasi mengenai http://www.debian.org/intro/organization yang up-to-date.
Setup permintaan pelacak publik. 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.