UbuntuHelp:Beginners/Development
来自Ubuntu中文
This page is used by the Beginners Team to communicate ideas
目录
Tasks
The documentation should always reflect the latest version, and then if there are release specific differences, then those differences and only those differences will be placed into their own pages under the same category, and linked to. So for example if Dapper's codec installation method is different, it should be under Media/Dapper, or Media/Video/Dapper if Video happens to be subclassed. 1. FAQ should be for questions, not every task under the sun. Things from there will need to be shuttled into their own pages, and linked from the guide, or put into some hardware troubleshooter. 2. CLI should be minimised, tucked. 3. Eliminate all these pages, by either moving the information into the guide or regular wiki, or eliminating it.
Beginners/Guide/Dapper Beginners/Guide/Edgy Beginners/Guide/Feisty Beginners/Guide/Feisty/Gaim Beginners/Guide/Feisty/Multimedia 4. Things to Add
Desktop Guide
- Should probably include how to browse gnome-look/kde-look, save something, and choose it.
- Themes -- Do not include Beryl in this, compiz is default.
- Engines?
- Sounds
- Splashes (DE, and possibly usplash)
- KDE and XFCE
- Carefully chosen list of professional sites to pick customisations from.
Installation of programs, most importantly from Add/Remove Programs. *TODO: Check if any guide exists for this.
- If possible use programs as an abstraction of packages.
Things To Remember
Our Main Job on the wiki is to help improve it, not duplicate efforts
- This means making sure if there are already articles for the things we want, improve and link to those instead.
- Make sure you do thorough searches to see if the subject matter already exists.
- Never cluttering pages, keep things simple, and provide links.
- Keeping as many links internal as possible.
- If possible, link to the work of our wonderful screencasting team: http://doc.ubuntu.com/screencasts/
Unneccessarily complicating things.
- This means staying away from the cli as much as possible.
- The more new things that are introduced, the more confusion.
- Making sure you look over everything you do several times, to simplify.
Screenshots
We want PLENTY of clear and illustrative screenshots for all gui operations.
- Make sure they are cropped properly - you can take a screenshot of the window in focus with <Alt>Print Screen.
- Hopefully use the Human theme/Default Plastik/Glass combo for KDE.
- It would even be nice if we could follow the screencasting guidelines, of using virtual machines, clean boot, to make menus and such identical to default and clean install.
"The reason for using a virtual machine rather than the current desktop is to ensure the screenshots are showing what a user would see. Most developers (or even experienced users) have additional software installed (such as the video recording application), have customised their desktop, or are running a version of Ubuntu (such as the current development version) which users might be less likely to use. It also allows for a "gold" build to be kept in a disk image which can be re-used after the screenshots are. This means each set of screenshots starts from the same basic starting point of a fresh (new) installation of Ubuntu. If screenshots and howtos are made which assume levels of knowledge or that certain software is already installed then it's possible users will get lost or give up when they see that the screenshots doesn't match what they see." - Modified Excerpt from screencasting team article.
Guidelines for Screenshots
Screen shots should be done with a default install ~ This means default background, default menus, default icons, etc. This is best accomplished with a virtual machine with no customization. Options include qemu, vmware, and virtual box.
Wiki Guidelines
To help new users feel at ease we do not want to over-burden them with inaccessible jargon. The glossary, explained below, will take care of some of the problems associated with new terms, but as a team we need to ensure that we keep our language and explanations as lucid as possible. We want clear-cut phrases, avoiding high densities of technical terms.
References
Please look at these pages : Ubuntu Documentation Style Guide WikiGuide HelpOnEditing
Glossary
Please use this Glossary.
