Collaboration Guidelines

Policy and Procedures

• The purpose of this project is to move all the information found in the files area of the database into the wiki. Examples of things typically found in the files area include 10 code lists, fire station locations, maps, Fire Tone Out information and more. Please see the Wiki User Guide (under Important Links to the left) for file extensions that can be uploaded.

• We now have state-level pages built in the Collaboration Gateway as well as several province level pages (for the Canadian entries). Please use these as your starting points. All pages are coded with templates to give them a similar look and feel.

• All templates have 3 items which contains links (click on the text) that will be helpful to those not familiar with using the wiki markup language. There are links to the MediaWiki language reference website, a quick reference guide and a site that allows you to print a PDF-formatted quick reference card.

• All county-level articles must be linked to one state collaboration page. Any page that isn’t linked to something else in the wiki are referred to as ‘orphans’; while this might not mean much from the viewpoint of someone trying to find something from the database, anyone coming in from the wiki main page (or using the pulldown) would never find this article without searching.

• Coding links from one page to another are referred to as interwiki links. They are coded with the desired title enclosed in double square brackets. There is no need to code the URL as MediaWiki will resolve the reference for you. Article titles must be exact; spelling, punctuation, capitals all count. If Mediawiki cannot find the article, the link is shown in red. This fact is very useful when you are ready to move whatever data you have out to a new article; create a title that does not exist. Click on the red text, and you will be placed in the editor mode. Copy the data from wherever you have it, and paste.

• Place the following text at the bottom of every article; [[Category:Collaboration]] Categories are logical groups of articles. The advantage to using them for indexing is that no work needs to be done to maintain them; MediaWiki takes care of all of this automatically

• The standard for naming county pages seems to be the county name followed by the state abbreviation in parenthesis; for example: Anne Arundel County (MD) If you aren't sure about how the collaboration page in the database is named, please take the time to look it up. Note that (CA) has 2 meanings; California and Canada. Be careful here!

• If you have no files or other data to display for a county, you need not create an empty page for it. As mentioned above, it's very easy to create a new article. Empty pages don't serve much purpose, so avoid them when possible. If you are creating a multi page article, and you have pages that aren't quite ready, place some text in the article that indicates it's a stub.

• Never sign your article, or put a tag line at the bottom. MediaWiki keeps track of all articles, who writes/modifies them along with time and date stamps.

• Although it's a wiki standard to do all testing in the sandbox, there's a logical flaw with it; the sandbox can be wiped out by anyone, at any time, for any reason. It's far better to test in your own user area. It can be reached by clicking your ID in the Personal Tools frame to the left.

Coding Hints

• If you find that you have misspelled an article, or forgotten to put the state abbreviation in parenthesis, the easiest way to approach this problem is to use the MOVE function (in the left frame under DELETE). Remember to adjust any links that might need to be changed to point to the new name.

• If you wish to build a page around information found in the database, please don't copy this data verbatim. Instead, use the RR Wiki Extensions to accomplish this. See the indicated link for more information, and take note of the extra code necessary to enable refreshing the entries on the page (mentioned at the bottom of the article). See the Indiana Sports article for an example of how to use the extensions with both conventional and trunked data.

• There are many instances where text lists - such as response codes and 10 codes - that read like one long string when you view them in the database and end up reading the same way in the wiki. This makes such lists very hard to read and should be avoided. There are several ways to fix this;
  • Put a '*' (shift of 8) in front of each item to be listed. This is somewhat like the unordered list command in HTML. The nice thing about this feature is that each item ends with a soft break, so you don't need to code a break after each item; however depending on how you are organizing your lists, you may need a break at the very end of the list to be able to terminate it.
  • You can also put it into a table (wiki markup or HTML if you're more comfortable with it), since it's rather unlikely that things like 10 codes or response codes change very much (which is generally the best kind of data to put into a table, since tables tend to be a bit harder to maintain).
  • If your list represents a logical progression of steps, then creating a numbered list is the way to go. You do that with a '#' (shift of 3) in the first column. See the Excel Copy/Paste Special to Software article for an example.
  • The choice of how you go about it is yours - but please, consider readability when you post straight text lists.

• If you have a number of images to display (several maps, ect.) you may find that displaying them in a thumbnail to the right creates problems with editing individual sections. If this happens, you can use the gallery directive. This allows you to show several images (in thumbnail) in a gallery like layout, usually 4 or 5 on a line. See the Louisiana collaboration article for an example