Pages Structure

The following rules should be observed by each confluence user in RS project space:

• Most of the writing should be organized by topic, i.e. under the RS Components top page
  Pages that are not related to a specific business functionality go under another top page, eg [RS Architecture] or [0 Project Management]
• RS Components is split by component: [01 Core], 02 UI and Navigation, 03 Security, etc
• For each component page "<NN> <Component>" you can have subpages such as:
  • <Component> Req Items: subset of initial business requirements, created BM in the ResearchSpace Business Requirements & Specification (see RS Docs, restricted to Stage3 requirements. All text about a component is gathered in one page and duplications are removed. Requirements are extracted based on commitments in RS Technical Offer and Best and Final Offer. Each requirement has these attributes:
    • Requirement ID - unique requirement identificator. It will be used for referencing the requirements, as well as for requirements traceability during the project.
    • Requirement priority - shows the iteration based on the project plan, for which the requirement is planned for development. For example RS3.2 means that a requirement will be implemented during the second iteration of Stage3, RS4 means that a requirement will be implemented during Stage, RS? means that a requirement is not yet prioritized. Requirements could be reordered during the project and their priorities would change then also.
      This list with requirements is not a final one, and could be changed, extended or reduced within project continuance.
      Before each project iteration, based on these initial high level business requirements and their priorities, will be created a detailed functional specification.
  • <Component> Concepts: conceptual ideas and considerations that have not crystallized into a specification yet. Please contribute any idea or new requirement you have. See [Data Annotation Concepts] as an example
  • <Component> Tools: research and notes on existing open source tools/ approaches/ ontologies. See Search Tools as an example
  • <Component> Spec (RS3.1): crystallized and detailed requirements, use cases, state chart diagrams for the current sprint. This is the functional specification addressed to the developers.
  • <Component> <Others>: any other pages if the information cannot be classified in any of the above pages

Version Notation

A "tag" at the end of the page name in parentheses, to indicate its status:

• RS3.1 : the first sprint
• RS3 : in scope, involves several sprints
• RS3.? : in scope, sprint not yet determined
• RS4 : out of scope: functionality and thinking for next stage

Tips and Tricks

Random notes by Vlado re improving certain pages. Others may find these tips useful

To Maria

Re [Data Annotation Spec] (changes)

• Leave blank line before table, else it's indented as per prev bullet
• use || instead of | for table header cells (be that row or col header)

To Hollie

Re [1 Project Admin on multiple projects dashboard]

• instead of comment, just replace my question with the explanation:
  "Blue circles show which items would not be needed by a non admin person."
  The reader shoudln't have to pore through discussions to get the meaning. The page should read as smoothly as possible
• put section heading before each separate shot in the page:

  h1. Project Administrator Overview Dashboard

• add
  • Pages Structure
  • Version Notation
  • Tips and Tricks
  • To Maria
  • To Hollie
  at the top if there's more than 1 section
• add a paragraph of explanation for each shot. Basically what you were describing and I couldn't hear on the phone
  • use bullets liberally: I think they make better structure than running paragraphs
• "admin project dashboard.png attached by Hollie Lubbock"
  Did you know you can easily move attachments between pages?
  Click the paperclip on top, select Properties for the appropriate attachment, Specify the page you want to move the attachment to.