[ << ] [ < ] [ 手册主页 ] [ > ] [ >> ]

2. Etiquette的策略

• Introduction and some simple suggestions
• What you should try not to do
• Tips

2.a. Introduction and some simple suggestions

       These suggestions are designed to be an easy-to-follow guide to what Developer 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 behaviour with our community - whether to other developers or users. However, you may be subject to sanctions or a suspension if a resonable standard is not.

       By reasonable standards we don't require you to act in the most formal manner ever heard of, or speak like a CEO. 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 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.

2.b. 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.

2.c. Tips

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 if you need to. 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

• Try to not bump ebuilds continuously unless there really is a benefit or a security fix which is important. Unnecessary examples of bumping include situations where a patch for the support of a new kernel version is added, for example; unless the ebuild is out of date from the date of the bug report.
• Try to not make ebuilds do unnecessary steps or do things outside of the package which may be un-needed: packaging unsupported patches as an "addition" is a bad idea unless they are either tested well by both you and your target audience and that they are code-checked for security.
• Ebuilds should be well commented if non-standard code or large chunks of code are used. Such ebuilds should also keep the user well informed: don't make the user wait for a long time during a long silent operation unless notification is given. At the same time, don't shower the user with a stream of information.
• Respect developers' coding preferences and don't change the ebuild syntax to remove stress on the CVS server, and to make things simpler for everybody unless you feel there is a real benefit in adding syntax cleanups - for example, faster compilation or a better more verbose output to the end-user.

IRC

• Be nice and respectful of everybody - even if they are bombarding you with messages.
• Do not abuse or discriminate users - 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 screwups. 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.
• #gentoo and #gentoo-dev are clean-language channels; other #gentoo- channels have policies set by their respective channel owners. Because the majority of traffic on #gentoo-dev 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 #gentoo-dev a 'clean-language' channel.

Forums

• Be nice and respectful of everybody - even if they are asking the most unimaginable questions. Either voice your opinion courteously, or voice no opinion.
• Follow the forum rules and try keeping to the discussion rather than veering off course.
• 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

• 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 correspondance problems.
• If you use spam-filtering software, check your collection of spam every so often just in case a developer's or a user's mail gets tagged as spam.
• 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 <insert name here> as <person> is now the maintainer of the package. Any further issues should be addressed to <person>. Sorry for any inconvenience."

[ << ] [ < ] [ 手册主页 ] [ > ] [ >> ]