Drafting+Guidelines

The following **Wiki guidelines** outline a number of suggestions which should ideally be followed when writing wiki pages to help create a useful and easy to use wiki for this project 1. Description of the domain and scope (include visual/graphic) (CEFACT BSP diagram if applicable ) 2. Short description and links to green pages 1. Broad scope. Conceptual description of the area (categories) (paragraph) 2. Short description and links to the yellow pages 1. Definition/description (paragraph) - Scope of the guide (What is covered / what is not covered? ) ( include visuals/graphics, cf. picture, chart, document process) (if available) ) 2. Problem statement? TF Issues addressed (//source for frequently asked questions//) Benefits of resolving problem 3. How to solve it? (available instruments) How to use it? 4. Prerequisites and sub-topics/follow on - (upstream - downstream), further reading - Examples and further readings throughout the text (where applicable)
 * STRUCTURE**
 * Pink pages**
 * Green pages**
 * Yellow pages**

Other writing suggestions:

When writing think as much as possible about the final user. [|Click here for a description of the final user.] Other tips from the meeting: - KISS principle: keep it simple and structured - Keep it practical - link it to what people are really interested in (link to the target audience) - No jargon (in case too technical always refer to the glossary)
 * 1. Understandability**

The wiki should be arranged to allow people to easily find the content they are looking for starting from the main page. Some key content is linked directly from the Main Page, but other main page links take you to 'start pages' on a particular topic. They are the next level in a kind of navigation hierarchy
 * 2. Structure**


 * 3. Duplication**

Duplication is often bad because there is a likelihood that the alternative explanations may vary slightly or significantly in the advice given. Where there is duplication, it should normally be rationalised to ensure that there is a single clear source of information on each subject. This may require tact and discussion on the relevant discussion pages! There may be a conscious decision to duplicate some information, where it is being presented in a different style / page structure. In these cases it is important to be clear about the reasoning for this, and cross-link to avoid confusion. If there is no good reason for duplication, then the pages should be merged somehow.

- single window (where do we put it ? ) - different angles / how do we keep the TF perspective ? - transit

try to avoid too much scrolling
 * 4. Size of a page ?**


 * 3. Titles. Page naming convention**

We'd like to move towards following [|Wikipedia capitalising naming conventions]: //For page titles, use lowercase after the first word, and do not capitalise second and subsequent words, unless the title is a proper noun. For multiword page titles, leave the second and subsequent words in lowercase unless the title phrase is a proper noun that would always occur capitalized, even in the middle of a sentence.// Multi-word (less than 5 words) In general wiki pages should be well linked to help people find the information they are looking for. Important related concepts are usually linked within the top description sentences. If you can't think of a related wiki page to link from here, then you're probably not describing the page in broad enough terms. Obviously throughout the page, you're also encouraged to link related concepts. You can work and edit on different pages together. You just open the different pages in different tabs and this will allow you to work simultaneously without having to save and close all the time
 * 4. Linking**
 * 5. Working on different pages together**

When creating a new page, be sure to give it different tags. Tags are knowledge labels related to the content of the page. Based on a consistent naming of the tags the usability of the site will be increased in a significant way.
 * 7. Each page should be described by tags**

Do we adopt a standard mechanism to refer to existing material? How do we refer in a meaningful way to some of the material that is not public?
 * 8. How do we refer to existing material ?**

- Summarize in a few words what the documents is about (meaningful connection) ? + make a link to the main source - If the document is not public you should mention the constraints -

Dates should be formatted in one of these ways depending on the precision required: For preference don't use the following formats: The following phrases which are unclear or go out of date should be avoided:
 * 9. Date formatting**
 * 12 August 2009 (the normal format, unless there is uncertainty or where the day is highly relevant)
 * Wednesday 12 August 2009 (for when the day of the week matters)
 * 1 August 2009 (no need for the leading zero in the day value)
 * August 2006 (day of month is not known nor relevant)
 * 2009
 * 'Soon' (August 2009) (when a prediction was made at a particular time)
 * 12th August 2009 (ordinal suffixes are not necessary)
 * August 12 2009 (keep a consistent order)
 * 12 Aug 2009 (Ok, but better to spell month in full?)
 * Wed 12 August 2009 (Ok, but possibly better to spell day in full?)
 * 12 August (Which year is that, 2007? 2008? 2009?)
 * 12.08.2009 (Is that 12 August 2009 or 08 December 2009?)
 * 01 August 2009 (don't include leading zero for day)
 * Soon/yesterday/tomorrow etc (replace with a full date or qualify with the date when the phrase was written to 'Soon (as of August 2009)'
 * Friday (which Friday?)
 * Summer 2009 (summer in the northern hemisphere is winter down south, and winter 2009 in the northern hemisphere can be either December 2009 or January to February 2009)