bildr:Definitions

Article:
Generic wiki articles are pages that define or explain something. These pages can be about ideas or generic items; for instance, Capacitor, but not 1.uf Electrolytic capacitor.

The name of the article should almost never be an acronym, but an entry for an acronym can be set up to redirect to the full article name. For example, Amp would redirect to Ampere, Cap to Capacitor, and IC to Integrated Circuit.

The singular term for a generic item is an article, and the plural form is a category. So, Capacitor is an article that contains information about capacitors, including a definition and perhaps a list of the various types. The plural, Capacitors, is a category that contains all the specific capacitor entries, which are components.

When appropriate, one article should be used for the various types of an item. For instance, Capacitor should contain separate sections for each type of capacitor, with information about each type.

Articles will mostly benefit newer users, so the reading/technical level should be kept at or around that of a freshman in college in a non-technical field.

Articles should only be as in-depth as necessary, and they should never include information that is not necessary to gain a working knowledge of the idea or item. All history and theory should be left out, except when completely necessary.

Each article page should be marked as an article by using at the very end of the page code.

Component:
Components are pages about specific parts. These are items that might have an item/part number and can be purchased from a store; for instance, 1.uf Electrolytic capacitor, but not Capacitor.

Because Integrated Circuits and components often come in many package types, but often do not vary in use from package to package, the package information should be left out of the name. For instance, a 555 timer comes in both a surface mount version and a through hole version, but only one page should exist for the both. This page should mention the availability of different versions and their differences, if necessary.

Component pages should be informational, not instructional. These pages should explain the interface and uses of the component, but should fall short of step-by-step instructions on use.

Each component page should be created using the component template.

Project Modules:
Project Modules (modules for short) are pages that take components or generic item articles, often in combination, and extend them into how-to articles. These pages explain in-depth how to create objects that do or accomplish one thing. Modules are the real building blocks of bildr.

Modules should be modular, in that they can be used in the creation of many larger projects, and should never be big or complex enough to be considered finished projects on their own. For instance, a page about creating a variable voltage regulator is considered a module because it could be used in many projects, but a bike powered headlight is not considered a module, because it could still be broken down into separate modules: a headlight and a bike generator.

Modules take the form of small projects and are written in an in-depth, complete, instructional manner. They should be written and presented in a way that is straight-forward and allows almost any user to recreate them, even users who have little previous knowledge. However, repetitive information should be kept at a minimum, and page linking should be used when possible.

Each module should include an abstract section at the top of the page to explain what it does, as well as when and where it could be used. The page should also include information on how it could be combined with other modules or expanded upon.

If a proposed module only has one use, it may be too small, or too specific, to have its own page. In this case, its information should be included on the page for whichever module it is used in conjunction with.

When creating a module, first, make sure it does not already exist in the wiki. It is always best to add information to an existing module, instead of starting a new version, if they both use similar parts or methods. If a similar module already exists, but it uses completely different parts or methods, a new module should be created. It is perfectly acceptable to have many separate modules which accomplish the same thing, as long as they do so in very different ways.

A module’s name should reflect what it accomplishes, and may contain a verb, for example: Sensing Temperature. Because there are many ways of accomplishing one goal, names should be specific and include part names in parentheses when needed. Blinking an LED tells the user what it does, but 'Blinking an LED (Arduino)' tells the user what it does and how it will accomplish this.

Each module should be marked as a module by using at the very end of the page code.

Module Container:
Module containers (containers for short) are pages (not categories) that group modules which all accomplish the same thing but do so in very different ways, such as by using different components. When one task has been documented in many ways, a container should be created to group them together.

A container should be named generically to encompass all its child modules. For example, a container simply named 'Blinking an LED' or 'Sensing Temperature' is perfectly suited, and it would contain a list to all related modules. For example:


 * Blinking an LED
 * Blinking an LED (Arduino)
 * Blinking an LED (555 Timer)
 * Sensing Temperature
 * Sensing Temperature (DS18B20 Arduino)
 * Sensing Temperature (DS18B20 AVR)
 * Sensing Temperature (TMP102 Arduino)
 * Sensing Temperature (TMP102 Wiring)

Each container page should be marked as a container by using at the very end of the page code. Subsequently, each module that is a part of a container grouping should be marked as such at the very top of its page by using. This will automatically add the module to the corresponding container page’s listing, even though a container is not a category page.

Reasoning:
The reasoning behind the separation of pages is to repeat as little information as possible, and to enable modularity. Simple article pages contain information that is the most likely to be repeated throughout the site, as they are most often definition pages. Omitting tutorial information on component pages allows these pages to be short and to the point, and to present the information in a uniform manner, which allows for ease of browsing from page to page.

Modules act as project parts, allow for the creation of more ideas from fewer articles, and help to encourage collaboration by multiple authors on each module, instead of the creation of many individual, but similar, projects.

Container pages help to simplify the user experience by allowing users to see the many ways a module can be completed, as well as having a shorter, more generic name.

Extra:
,,  , and  should only be added to a page that falls under that definition, and no page should contain more than one of these.

The following categories are added automatically, and should never be added manually:
 * Article
 * Component
 * Module
 * Container
 * Has Code
 * Octopart
 * Stub