Project:ComRel/Developer Handbook/Etiquette policy

This section outlines the etiquette policy for Gentoo developers.

Introduction and some simple suggestions
These suggestions are designed to be an easy-to-follow guide to what Community Relations would expect to be good developer etiquette. They should cover most areas and should be employed wherever they can be.

That doesn't mean that we expect you to follow this guide to the bullet point; nor do we expect you even agree with it - we do expect, however that all developers maintain reasonable standards of behavior with our community - whether to other developers or users. However, you may be subject to sanctions or a suspension if a reasonable standard is not met.

By reasonable standards we don't want you to feel that we are not allowing you to say anything, rather, we believe that how you say it, and the method and professionalism in how you express your opinion defines whether you meet the reasonable standards or not, since, as a developer, what you say and do reflects upon Gentoo and the project as a whole. We just require you to be equally respectful to developers and users alike, and to value the opinion of everybody - even if you think it's totally wrong.

You should try to use good spelling and grammar everywhere: whether in a CVS commit message, a ChangeLog, or even on IRC if you want to be really nice and make somebody's day. But don't worry; we won't really mind if you don't. You might not notice it, but by taking some effort to clean things up, the amount of time it takes to read your sentences is greatly lowered. However, it is also important not to lose the rope at the same time and make something too eloquent that takes too long to parse.

What you should try not to do
One should try to not be rude, abusive or impolite under any circumstances. Sometimes, just one sarcastic comment can change the tone to the reader. If you think you might give somebody a bad as a result of your comment, and if you really need to say it, make sure people understand that you are not trying to be offensive.

Please remember that you are an official representative of Gentoo. In this capacity, you are expected to maintain a certain level of professionalism and courtesy in your day-to-day interactions with users and other developers.

ChangeLogs

 * Make your ChangeLogs readable to the average end-user: try to keep things simple and short if you can, but provide any critical information as needed. Remember that ChangeLogs need to be written in good, "correct" English even if they are short. Punctuation is essential.
 * Please don't use "Gentooified" language, except for accepted terms such as "ebuild" and "version bump". If you are being verbose, please use the correct punctuation and quote marks.
 * Any function names should be encapsulated in quotation marks or speech marks.
 * Be verbose: "Version bump." is good, however "Version bump; see bug #..." is even better. This not only helps users, but it also helps other developers as well.
 * Don't use phrases such as "Tested for months, should work." or "I think this should fix the problems." as something either does its job or it doesn't. It is much better to inform users to test your package thoroughly and to report any bugs to you.
 * When referring to ebuild sections such as the homepage variable, use "HOMEPAGE" remembering to add the quotes and to use the correct case. This makes things a bit more precise, namely telling the reader that you changed the variable; rather than the homepage your package might go to when it starts up, for example.
 * When using acronyms, please use the proper cases. For example, "ALSA", not "alsa", "Win4Lin" not "win4lin".

Ebuilds

 * Respect developers' coding preferences. Unnecessarily changing the syntax of an ebuild increases the load on the CVS server and can cause complications for others. Syntax changes should only be done if there is a real benefit, such as faster compilation, improved information for the end user, or compliance to Gentoo policies.

IRC

 * Be nice and respectful of everybody - even if they are bombarding you with messages.
 * Do not abuse or discriminate users or developers - whether as a joke or as sarcasm.
 * Answer any questions to the best of your knowledge - it is best that you do not answer what you don't know to avoid confusion. There is no policy on any collateral damage caused by developers to users however: if the developer did any contact such as SSHing into a users' box, the developer would be held accountable for any issues arising out of the same. As a result, we don't really recommend it.
 * If you are a developer with operator powers, you must not abuse them - if you have a disagreement with a user resolve the issue peacefully and do not resort to kicking them or even kickbanning them unless the situation is really severe and other developers approve of critical measures.
 * and are clean-language channels; other #gentoo- channels have policies set by their respective channel owners. Because the majority of traffic on  is from Gentoo developers, people perceive this channel as officially representing Gentoo. In order for us to present Gentoo in a professional manner, we request that developers keep  a 'clean-language' channel.

Forums
Follow the forum rules and try keeping to the discussion rather than veering off course.
 * Be nice and respectful of everybody - even if they are asking the most unimaginable questions. Either voice your opinion courteously, or voice no opinion.
 * Try to be active in development. If users are asking why something was added, please explain it. If users are asking why something is missing, explain that. Use your knowledge and help out if you can. At the same time, if you don't know, don't confuse people.

Mail

 * Be nice and respectful of everybody. Don't respond to personal attacks with more attacks. Either voice your opinion courteously, or voice no opinion.
 * Don't use HTML mail - it can cause annoyances - and it is recommended that you use a word-wrapping mail client if sending out plain text messages. Some people also block HTML mail which may cause correspondence problems.
 * When replying to user or developer mail, be both courteous and don't simply refer the user along to another developer - try to explain why things are as they are if you can. An example of good, well thought reply goes along the lines of: "I am referring you to  as   is now the maintainer of the package. Any further issues should be addressed to  . Sorry for any inconvenience."