wiki:admin/metaforRules

These are the working procedures for the METAFOR website

  • All development and documentation should derive from a ticket
  • Tickets should provide links to related SVN branches and wiki pages
  • Development (ie: writing code) should be done via SVN
  • Discussion (ie: talking about code) should be done via email, phone, and wikis
  • Documentation (ie: recording issues & decisions) should be done via wikis and tickets
    • The distinction between "discussion" and "documentation" is intentionally fuzzy; In general, the wiki should be used for notes and interactive discussions while the ticket comments should be used for summaries/conclusions/decisions.
  • Ideally, each ticket should relate to a specific set of requirements and use-cases

How to use tickets:

  1. An issue/task is identified for a particular component and recorded as a ticket.
  2. An owner for the ticket is identified and they agree to deal with it.
  3. The owner may populate the ticket with the following initial information (see here for an example):
    1. a link to the wiki page where discussion/documentation will exist
    2. a link to the SVN branch where development will exist
    3. a link to the related METAFOR requirement(s)
    4. a link to the related METAFOR use-case(s)
  4. ...work continues...
  5. Eventually the ticket should be closed; No editing of the wiki pages is allowed while a ticket is closed.

How to use wikis:

  1. Wiki pages used for documenting tickets should use the ticket number as their name, and they should provide a link back to the ticket. Other wiki pages should have descriptive names.
  2. Each wiki should have a descriptive title in the header
    ("integrate the controlled vocabulary into the CIM" is a good title, "document ticket 230" is a bad title). This title is what will be seen in the table-of-contents used throughout the Trac site.
  3. Each wiki should be located appropriately; The following directory structure exists:
wiki/requirements
wiki/use-cases
wiki/tickets
wiki/<top-level-component>

Where the <top-level-components> are: WP1-7 and CMIP5. Additional sub-directories can be added as needed for specific components.

  1. Where it is not apparent, text on the wiki should be tagged with the author's name like this [Allyn]
  2. Each wiki should include an index of wiki pages at its end. This can be added by using the following syntax: [[WikiInclude(admin/metaforIndex)]]

The index page for each top-level-component should include links to all relevant requirements, use-cases, and tickets. Here is a particularly good example. (Note that embedded macros should automatically insert links to all relevant tickets, but it's worth double-checking this.)

How to use SVN:

Some guidelines on what to store in SVN when developing the CIM exist here.

basic usage

  1. Create a branch: svn copy http://metaforclimate.eu/svn/CIM/trunk http://metaforclimate.eu/svn/CIM/branches/testBranch -m "a sample branch" --username allyn
  2. Checkout that branch to a working copy: svn checkout http://metaforclimate.eu/svn/CIM/branches/testBranch testBranch
  3. Modify the working copy... Wheee!
  4. Discuss and document the modifications on wikis/tickets/email/telcos as appropriate
  5. Commit the working copy back to the branch: svn commit -m "added testFile"
  6. Notify an administrator that the branch is ready to be merged into the trunk.

merging changes

  1. Assume that  Statler and  Waldorf each creates a working copy based on the same branch (as above).
  2. Statler makes some changes to his working copy and commits them to the branch (as above)
  3. Waldorf notices a new SVN revision; He diligently incorporates those changes into his working copy: svn update -r <revision>
  4. Waldorf makes some further changes to his working copy and commits them to the branch (as above).
  5. Statler ignores those changes and carries on developing his working copy. When he tries to commit his changes SVN checks to see if there is a conflict first. If there isn't then everything proceeds as before. If there is, then Statler has to (with Waldor's help) resolve those conflicts. ( xxdiff works well for this).
  1. Assume Statler and Waldorf are both working on different branches.
  2. Waldorf wants to merge the changes in Statler's branch ito his working copy: svn merge http://metaforclimate.eu/svn/CIM/branches/statlers
  3. He deals with any conflicts (as above)
  4. He commits his newly-changed working copy back to his branch

backing out changes

  1. Waldorf does some work and commits his change to a branch
  2. He realises he made a mistake and wants to undo the change before other people notice
  3. So he merges it with the previous revision: svn merge -c <older revision> http://metaforclimate.eu/svn/CIM/branches/waldorfsBranch and then commits it to the branch: svn commit -m "backing out changes from revision x" --username waldorf

advanced usage (merging to the trunk)

  1. Check out the trunk to a working copy (as above) / or make sure an existing working copy reflected the current state of the trunk (using svn switch / svn update)
  2. Work out which set of revisions to merge into the trunk: svn log --verbose --stop-on-copy http://metaforclimate.eu/svn/CIM/branches/testBranch, this will print out a list of each prior commit of testBranch
  3. Merge testBranch into the trunk working copy: svn merge -r <start revision>:<end revision> http://metaforclimate.eu/svn/CIM/branches/testBranch (typically, the end revision will be "HEAD" and the start revision will be the last number printed out in the previous step)
  4. Check the status and deal with any conflicts (as above)
    1. odds are that when dealing w/ the CIM I will want to just overwrite my working copy with the merged branch, so when a conflict is encountered I can select the option "tf" to accept "theirs-full"
  5. Commit the working copy back to the trunk: svn commit -m "merged testBranch@<current revision> into trunk" --username allyn
  6. Once commited, tagging is trivially easy: svn copy http://metaforclimate.eu/svn/CIM/trunk http://metaforclimate.eu/svn/CIM/tags/<my_tag> -m "tagging the CIM for some reason" --username allyn
    (the first argument to copy could just as easily be a branch or a working copy if I were tagging for some reason other than a formal release)


Wiki Index

  1. WP1: the starting point for WP1: Project Management
  2. WP1/Amendment3: Amendment 3: Metafor project extension
  3. WP1/SoftwareManagement: Live Deliverables
  4. WP1/TelcoMinutes: Teleconference minutes
  5. WP1/TelcoMinutes/20Sept2011
  6. WP1/TelcoMinutes/Telco138_27Sept2011: Telco 138 - 27th September 2011
  7. WP1/TelcoMinutes/Telco139_4Oct2011: Telco 139 - 4th Oct 2011
  8. WP1/TelcoMinutes/Telco140_11Oct2011: Telco 140 11th October 2011
  9. WP1/TelcoMinutes/Telco141_1Nov2011: Telco 141 1st November 2011
  10. WP1/TelcoMinutes/Telco142_6Dec2011
  11. WP1/TelcoMinutes/Telco143_5Jan2012: Telco 143 5th January 2012
  12. WP1/TelcoMinutes/Telco144_2Feb2012: Telco 144 2nd February 2012
  13. WP1/TelcoMinutes/Telco145_6Mar2012: Telco 145 6th March 2012
  14. WP1/TelcoMinutes/Telco146_2Apr2012: Telco 146 2nd April 2012
  15. WP1/TelcoMinutes/Telco147_10May2012: Telco 147 10th May 2012
  16. WP2: the starting point for WP2: The CIM
  17. WP2/ControlledVocabulariesList: A flat list of controlled vocabulary terms for the CIM
  18. WP2/DevelopingTheCIM: some guidelines for developing the CIM
  19. WP3: the starting point for WP3: testing/populating
  20. WP3/Agile: Metafor WP3 Group - Agile Management
  21. WP3/Agile/Sprints/01: Metafor WP3 Group - Sprint 01
  22. WP3/docs
  23. WP3/telcos
  24. WP3/telcos/03/agenda
  25. WP3/telcos/04
  26. WP3/telcos/05: Agenda
  27. WP4: the starting point for WP4: Services
  28. WP4/Agile: Services Group - Agile Management
  29. WP4/Agile/Sprints/01: Services Group - Development Sprint 01
  30. WP4/Agile/Sprints/02: Services Group - Development Sprint 02
  31. WP4/Agile/Sprints/03: Services Group - Development Sprint 03
  32. WP4/Agile/Sprints/03/url-design: Initial Thoughts on Metafor URL design to supplement attached note
  33. WP4/Agile/Sprints/04: Services Group - Development Sprint 04
  34. WP4/Agile/Sprints/05: Services Group - Development Sprint 05
  35. WP4/Agile/Sprints/06: Services Group - Development Sprint 06
  36. WP4/Agile/Sprints/07: Services Group - Development Sprint 07
  37. WP4/Agile/Sprints/08: Services Group - Development Sprint 08
  38. WP4/Agile/Sprints/08/Agenda
  39. WP4/Agile/Sprints/09: Services Group - Development Sprint 09
  40. WP4/Agile/Sprints/11
  41. WP4/Agile/Sprints/12: Services Group - Development Sprint 12
  42. WP4/Agile/Sprints/19
  43. WP4/Deliverables
  44. WP4/MF-ISENES-Timeline
  45. WP4/NumSim: WP4/NumSim
  46. WP4/PortalDeployment: pre-requisites
  47. WP4/QDeployment: Deploying the questionnaire
  48. WP4/QSandbox: Notes on building questionnaire sandboxes
  49. WP4/ServicesPlanningDocument: Metafor Services (WP4, WP5, & WP6): Deliverables, Dependencies, and …
  50. WP4/URIstructure: WP4/URIstructure - The Metafor URI structure(s)
  51. WP5: the starting point for WP5: Tools
  52. WP6: the starting point for WP6: CIM Creation
  53. WP7: the starting point for WP7: Dissemination
  54. CMIP5: the starting point for CMIP5
  55. CMIP5/FileMetadata: CMIP5 Internal File Metadata
  56. CMIP5/QuestionaireBetaTesting: Comments, queries and issues raised by our beta testers
  57. CMIP5/QuestionaireIssues: Alpha 5 release of the CMIP5 questionnaire: …
  58. CMIP5/QuestionaireRequirements: CMIP5 questionnaire requirements
  59. CMIP5/QuestionaireTimeline
  60. CMIP5/QuestionnaireAccess: Instructions for Access to the CMIP5 Questionnaire …
  61. CMIP5/QuestionnaireCentres
  62. CMIP5/QuestionnaireOpenLetter: Open letter to our users
  63. CMIP5/QuestionnaireTimeline
  64. CMIP5/Storyline
  65. CMIP5/VarURIStructure: CMIP5/Variable Structures
  66. CMIP5_CVSoft
  67. requirements: METAFOR requirements
  68. requirements/testRequirement: requirement: make sure that thingies contain widgets (sample requirement)
  69. use-cases: METAFOR use-cases
  70. use-cases/AnnotateCIMRecord: Use-Case: Annotate a CIM Record
  71. use-cases/BrowseCIMRepository: Use-Case: Browse a CIM Repository
  72. use-cases/CaptureGridDefinition: Use-Case: Capture a Grid Definition
  73. use-cases/FindCIMRepository
  74. use-cases/FindExperimentsForModel: Use-Case: Find Experiments Based On Model X
  75. use-cases/FindModelsForExperiment: Use-Case: Find Models Used In Experiment X
  76. use-cases/FindModelsToCouple: Use-Case: Find Models To Couple
  77. use-cases/FindRelatedCIMRecords: Use-Case: Find Related CIM Records
  78. use-cases/FindRelatedCitations: Use-Case: Find Related Citations
  79. use-cases/KeywordSearchCIMRepository: Use-Case: Keyword Search a CIM Repository
  80. use-cases/QueryCIMRepository: Use-Case: Query a CIM Repository
  81. use-cases/ViewCIMRecord: Use-Case: View a CIM Record
  82. use-cases/ViewDatasetQualityReport: Use-Case: Find Related Citations
  83. use-cases/create-qc-record: Use-Case: Modify or Create a quality control record
  84. use-cases/template: Use-Case: <name>
  85. use-cases/testUseCase: Use-Case: a sample use-case
  86. tickets/1008: QC for CMIP5 Questionnaire Records
  87. tickets/167: CIM sequence document & diagrams
  88. tickets/180: notes for  ticket 180
  89. tickets/181: notes for  ticket 181
  90. tickets/182: The Wiki page for documenting progress on the ConCIM activity package: …
  91. tickets/184: Existing Controlled Vocabulary lists
  92. tickets/185: notes for  ticket 185
  93. tickets/189: Use Cases for interacting with the UMUI Minutes from a meeting that …
  94. tickets/191: Experiment relationships for CMIP5
  95. tickets/192: CMIP5 Questionnaire
  96. tickets/193: Extracting CIM metadata from code and verifying CIM metadata and code are …
  97. tickets/214: Figure out how the Controlled Vocabulary should integrate with the CIM
  98. tickets/215: tidy the CIM (as per the Y1 meeting)
  99. tickets/226: restructure the wiki
  100. tickets/232: create a widget for the thingie (sample ticket)
  101. tickets/236: tidy the CIM (to make it less XML specific)
  102. tickets/237: include sequencing info in the CIM
  103. tickets/239: Outstanding CIM Issues
  104. tickets/241: Implement Tree Navigation for the CMIP5 Questionnaire
  105. tickets/244: Processing the mindmaps (bundled version) to create XML suitable for …
  106. tickets/245: Work in progress
  107. tickets/247: Ingest ESG metadata into mindmaps
  108. tickets/248: CMIP5 Questionnaire Timeline
  109. tickets/249: Questionnaire to CIM Conversion
  110. tickets/250: CMIP5 Conformance wiki for ticket #250
  111. tickets/253: Questionnaire Metadata Validation
  112. tickets/254: Table 1: CMIP5 constraints not enforced by the Questionnaire
  113. tickets/277: Proposed updates to the CIM Grid logical data model
  114. tickets/280: add / revise definitions of terms used in the CIM
  115. tickets/281: when should references use XPath and when should they embed documents …
  116. tickets/31
  117. tickets/326/aerosols
  118. tickets/326/atmos
  119. tickets/326/atmos_chem
  120. tickets/326/land_ice
  121. tickets/326/land_surf
  122. tickets/326/ocean: Herafter is the previous version of definitions tables for Ocean, included …
  123. tickets/326/ocean_biochem
  124. tickets/326/sea_ice: Herafter is the previous version of definitions tables for Ocean, included …
  125. tickets/485: CMIP5 Questionnaire
  126. tickets/509: What Deployment/Hardware/Configuration? Information Should Be Recorded?
  127. tickets/519
  128. tickets/55: Metafor Governance
  129. tickets/636: Wiki Page for Ticket #636 (Review of Grid Properties in MindMaps)
  130. tickets/684: Discussion of Ensemble Handling Issues
  131. tickets/707: THREDDS to CIM instances tool
  132. tickets/709: CIM v1.5
  133. tickets/715: METAFOR Success Criteria
  134. tickets/778: Integrate Controlled Vocabularies with the CIM
  135. tickets/78
  136. tickets/79: CIM Differencing Tool Design Document
  137. tickets/810
  138. tickets/862: Required CIM Software Component Properties
  139. tickets/868: Some Documentation of Issues associated with ticket:868
  140. tickets/870: Moving towards CIM2.0
  141. tickets/888: Definition of unconfigured vs configured model
  142. tickets/92: Outstanding CIM Prototype Human GUI Issues
  143. tickets/920: O&M
  144. tickets/920/options4om1: Initial Step
  145. tickets/920/sidl: Scientific Interface Definition Language (SIDL)
  146. tickets/921
  147. tickets/925: A Common Information Model paired with scientific Controlled Vocabularies …
  148. tickets/926: EGU abstract - The CMIP5 questionnnaire: web-based metadata collection for …
  149. tickets/927
  150. tickets/986: CIM v1.7