doc: project -> Zephyr Project

To make the documentation readable from the source I want to get rid of the
substitutions for the project name an code name. This does not add any values
and makes it unreadable when looking at the text files directly. It also causes
some issues when people use those without actually knowing what they represent,
resulting in some weird and redundant language.

Change-Id: Icc70eef90966ed19531c3406fe7a6d1866f7d81d
Signed-off-by: Anas Nashif <anas.nashif@intel.com>

doc/README.rst

@@ -6,10 +6,10 @@ Welcome to Zephyr Kernel
    More information at `<http://sphinx-doc.org/rest.html>`_.
    This is a comment that won't show up in formatted output
 
-Welcome to the |project|.
+Welcome to the Zephyr Project.
 
-Thank you for your interest in the |project|. These instructions are
+Thank you for your interest in the Zephyr Project. These instructions are
-designed to walk you through generating the |project|'s documentation.
+designed to walk you through generating the Zephyr Project's documentation.
 
 
 Documentation Notes
@@ -52,7 +52,7 @@ Install the current version of :program:`Sphinx`, type:
 Running the documentation generators
 ************************************
 
-Assuming that the |project| tree with the doc directory is in
+Assuming that the Zephyr Project tree with the doc directory is in
 :file:`DIRECTORY`, type:
 
 .. code-block:: bash

doc/collaboration/code/doxygen/doxygen.rst

@@ -14,7 +14,7 @@ them together, we can reference the code in the documentation and vice-versa.
 In-Code Documentation Guides
 ****************************
 
-Follow these guides to document your code using comments. The |project|
+Follow these guides to document your code using comments. The Zephyr Project
 follows the Javadoc / Doxygen commenting style. We provide examples on how to
 comment different parts of the code. Files, functions, defines, structures,
 variables and type definitions must be documented.

doc/collaboration/code/gerrit.rst

@@ -4,10 +4,10 @@ Working with Gerrit
 ###################
 
 
-Follow these instructions to collaborate on the |project| using
+Follow these instructions to collaborate on the Zephyr Project using
 the infrastructure within Intel’s Open Source site, ``01.org``. First, let
 us answer a couple of common questions regarding the use of Gerrit
-within the |project|.
+within the Zephyr Project.
 
 #. Who has access to the Gerrit infrastructure?
 
@@ -63,7 +63,7 @@ change be pushed to a special branch. The name of this special branch
 contains a reference to the final branch where the code should reside,
 once accepted.
 
-For the |project|, the special branch is called :literal:`refs/for/master` .
+For the Zephyr Project, the special branch is called :literal:`refs/for/master` .
 
 1. Push the current local development branch to the gerrit server, type:
 

doc/collaboration/communication/communication.rst

@@ -16,7 +16,7 @@ can be used to hold design discussions, remember to submit all changes using
 Gerrit.
 
 The following sections contain information about the communication tools
-used with the |project|.
+used with the Zephyr Project.
 
 .. toctree::
    :maxdepth: 2

doc/collaboration/communication/mailing.rst

@@ -3,7 +3,7 @@
 Open Source Mailing List Collaboration Tips
 ###########################################
 
-Below are some recommended guidelines for using the |project|'s mailing list.
+Below are some recommended guidelines for using the Zephyr Project's mailing list.
 When submitting feedback and contribution ideas to the listserv, please follow
 these guidelines:
 

doc/collaboration/documentation/about.rst

@@ -7,7 +7,7 @@ Purpose
 *******
 
 This style guide provides general information, guidelines, procedures, and
-instructions for the documentation work of the |project|.
+instructions for the documentation work of the Zephyr Project.
 
 Consistent style is important for readers, authors and editors. For readers,
 consistency promotes clarity and confidence. For example, using an
@@ -29,7 +29,7 @@ This style guide has two audiences:
   machine generated content, such as APIs.
 
 * Technical writers that wish to create technical documentation for the
-  |project| (writers).
+  Zephyr Project (writers).
 
 * Secondary audience: Developers that wish to document their code and
   features (authors).

doc/collaboration/documentation/cross.rst

@@ -12,8 +12,8 @@ consistency of the documents.
 Internal Cross References
 =========================
 
-An internal cross reference is a reference to a location within the |project|
+An internal cross reference is a reference to a location within the Zephyr Project's
-'s documentation. Use explicit markup labels and the ``:ref:`` markup to
+documentation. Use explicit markup labels and the ``:ref:`` markup to
 create cross references to headings, figures, and code examples as needed.
 All modules must have a label before their titles in order to be able to
 cross reference them, see :ref:`modular` for more information regarding
@@ -148,4 +148,4 @@ Use this template to add a hyperlink with a separated definition:
 
    The state of `Oregon`_ offers a wide range of recreational activities.
 
-   .. _Oregon: http://traveloregon.com/
+   .. _Oregon: http://traveloregon.com/

doc/collaboration/documentation/detailed.rst

@@ -6,7 +6,7 @@ Detailed Writing Style Guidelines
 Tone and audience
 *****************
 
-The tone of the |project|'s documentation should be clear, concise,
+The tone of the Zephyr Project's documentation should be clear, concise,
 confident, and courteous. We are writing to peers, so we want to be
 familiar. Use you, we and avoid the passive voice, but while remaining
 professional. The writing should carry an undertone of cordiality,

doc/collaboration/documentation/documentation.rst

@@ -4,7 +4,7 @@ Documentation Style Guide
 ##########################
 
 This Documentation Style Guide is produced and maintained
-by the |project|. This section provides overview information about the
+by the Zephyr Project. This section provides overview information about the
 scope and purpose of this manual and links to related resources.
 
 These guidelines help you write in a manner that is clear, concise, and

doc/collaboration/documentation/images.rst

@@ -11,7 +11,7 @@ on graphics than those reading in their primary language because the
 understanding they gain from the graphics helps them understand the
 text.
 
-Follow these guidelines when creating graphics for the |project|:
+Follow these guidelines when creating graphics for the Zephyr Project:
 
 * Captions. Include a caption to explain or describe what the graphic
   illustrates or to use as a navigational tool when referring to the

doc/collaboration/documentation/modular.rst

@@ -13,7 +13,7 @@ rewriting.
 
 Modular writing doesn't include any content format formating. The format
 of the output is handled by a style sheet, which is applied when the
-content is published. The |project| uses Sphinx to build the
+content is published. The Zephyr Project uses Sphinx to build the
 documentation. Sphinx gathers the content from all modules and produces
 HTML output that allows the use of CSS stylesheets for format.
 
@@ -33,7 +33,7 @@ Requirements: Must use these materials.
 
 Guidelines: Specific things to do.
 
-The |project| strives for full modularization of content. The
+The Zephyr Project strives for full modularization of content. The
 modularization is still a work in progress and new content must be
 structured following this guidelines.
 
@@ -62,7 +62,7 @@ the modules that follow:
 * Focus on the overall goal of the information, so the users know why
   it is important for them and what they will accomplish.
 
-The |project|'s documentation uses overview modules as container
+The Zephyr Project's documentation uses overview modules as container
 modules. Container modules include a toctree directive that includes
 either other container modules or concept, task and reference modules.
 For example in a System Requirements overview module:

doc/collaboration/documentation/rest.rst

@@ -3,7 +3,7 @@
 Restructured Text Guidelines
 ############################
 
-The |project| uses Sphinx and Restructured Text as authoring tools for
+The Zephyr Project uses Sphinx and Restructured Text as authoring tools for
 documentation. Here you can find the preferred methods for using
 :abbr:`ReST (Restructured Text)` markup on your documents. Please refer to
 the `Sphinx documentation`_ for the complete list of available markup.

doc/collaboration/documentation/simple.rst

@@ -225,7 +225,7 @@ Pronouns
 First Person
 ============
 
-We recommend using we or the |project|, if you want to sound more
+We recommend using we or the Zephyr Project, if you want to sound more
 formal, to provide an agent, someone who does the action in a sentence,
 and avoid passive constructions such as "It is recommended...." For
 example:

doc/collaboration/documentation/tables.rst

@@ -5,8 +5,8 @@ Tables
 
 Tables must only be used for information that is either too numerous or too
 related for a list to be appropriate. The general rule of thumb is that the
-minimal size of a table is a 2x2 not counting the table header. The |project|
+minimal size of a table is a 2x2 not counting the table header. The
-'s use of ReST makes table size much more important. Tables are difficult to
+use of ReST makes table size much more important. Tables are difficult to
 do properly in ReST following the line length restrictions. If you plan on
 adding content in form of a table consider transforming it into a list
 before you embark on creating a table. Follow these general guidelines:
@@ -93,4 +93,4 @@ This template can help you create grid tables:
 
 The use of '=' in grid tables is used to separate the table header from the
 table body. Do not add emphasis to the contents of the table header using
-\*\*.
+\*\*.

doc/quick_start/application.rst

@@ -9,7 +9,7 @@ Building a Sample Application from Source
 
 To build an example application follow these steps:
 
-#. Go to the root directory of the |project|.
+#. Go to the root directory of the Zephyr Project.
 
 #. Set the paths properly in the :file:`$ZEPHYR_BASE` directory,
    type:

doc/quick_start/quick_start.rst

@@ -6,7 +6,7 @@ Quick Start Guide
 Use this guide to install the Zephyr development environment on your
 development system and to build the Zephyr Kernel on the supported platforms.
 
-Currently, the |project| supports Linux development systems only. This guide
+Currently, the Zephyr Project supports Linux development systems only. This guide
 was tested by compiling and running the Zephyr Kernel's sample applications on
 the following Linux distributions: