Difference between revisions of "User:Dzonatas Sol/AWG Design Document Template"

From Second Life Wiki
Jump to navigation Jump to search
(→‎Guidelines: added rationale for design document titles)
Line 4: Line 4:


* Review [[Design Document Template]] for insight of needed content.
* Review [[Design Document Template]] for insight of needed content.
* Design Documents are to describe aspects of the given model. Terminology that is out of scope to describe a specific aspect of the given model belongs in the [[Architecture Working Group Glossary|Glossary]] and does not need its own design document. Rationale: the design documents under this category are specific to the given model. If the title of a design document has the same name of a term that confuses the view, it is best to find a new name for the title of the design document; however, the previous model and the given model both already provide names for aspects of that model, which are commonly used by default for design titles and may confuse the view more if changed. Icons also help to avoid confusion such the icon plus a title can be recognized distinctly from general terminology.


* Title each page with "AWG ''NAMEOFDOC''" where ''NAMEOFDOC'' is the actual name. If possible, upper case only the first letter of each word in ''NAMEOFDOC'', as it is typically done for a title, like "AWG Document Title." The first four characters "AWG " are significant to the macros.
* Title each page with "AWG ''NAMEOFDOC''" where ''NAMEOFDOC'' is the actual name. If possible, upper case only the first letter of each word in ''NAMEOFDOC'', as it is typically done for a title, like "AWG Document Title." The first four characters "AWG " are significant to the macros.

Revision as of 12:52, 21 October 2007

Slarch.jpg

 Description:

Dzonatas Sol/AWG Design Document Template

Guidelines

  • Design Documents are to describe aspects of the given model. Terminology that is out of scope to describe a specific aspect of the given model belongs in the Glossary and does not need its own design document. Rationale: the design documents under this category are specific to the given model. If the title of a design document has the same name of a term that confuses the view, it is best to find a new name for the title of the design document; however, the previous model and the given model both already provide names for aspects of that model, which are commonly used by default for design titles and may confuse the view more if changed. Icons also help to avoid confusion such the icon plus a title can be recognized distinctly from general terminology.
  • Title each page with "AWG NAMEOFDOC" where NAMEOFDOC is the actual name. If possible, upper case only the first letter of each word in NAMEOFDOC, as it is typically done for a title, like "AWG Document Title." The first four characters "AWG " are significant to the macros.
  • Start each page with {{:AWG/PageHeader}} in order to transclude the header layout (as shown above) and its macros.
  • Avoid generalizations in the Description field. As much as possible, write statements in terms of the now, which means there is an actual model to describe. Also, the use of grammatic infinitives is a bold indication of a generalization (some usage in nouns is unavoidable). Remember, any generalization in design is a bottleneck in implementation.
  • Keep the Description field concise but mappable. Use {{AWG|NAMEOFDOC}} to map to other AWG design documents. Any specifics beyond basic purpose, terminology, or mappable usage goes in another section (and refer to Design Document Template for possible sections). The description being mappable to other design documents is a power of the wiki -- use it! (especially to map back to the article itself, for example "A {{AWG|NAMEOFDOC}} is ...")
  • Upload an icon for the page under the name AWG_NAMEOFDOC.png where NAMEOFDOC must have underlines instead of spaces. A macro in the pageheader detects the image and inserts it automatically. For now, the icons are sized to 100x100px. Icons are a good means to graphically map the model or indicate states of the model, so it is good to keep them distinct from each other (or redo them to make them more distinct). Don't make icons too complex where it cannot be easily drawn by hand as a conversation piece.
  • Use regular wiki sections below the pageheader. For example if there are specifications to list, create a "Specification" section for them.
  • Any talk in the main article is subject to be rewritten to make a formal statement about the design or can be moved to a more appropriate (discussion) page.