GIthub workflow for DXWG group

In response to the request from today's meeting, here is a possible GitHub workflow for managing changes to the various deliverables. 

Phila already set up the github repository such that 

1. there is a _directory_ for each deliverable, so far 	

2. Note that the default branch is gh-pages (as the main working group deliverables are documents)

Now we need the current repository owner (Dave Raggett?) to check that 

3. All members of the WG have permissions set so they can push (i.e. have write permission) to the whole repository

Rules of engagement when working on multiple deliverables, with designated editors for each one: 

4. By convention, while everyone can work on a branch other than gh-pages,*only an editor will merge* (accept changes) into the directory for their deliverable [1]. Since this is *not* enforced by the GitHub permissions, it relies on everyone behaving themselves, by following this workflow. 

The recommended workflow to make a change (edit) to a deliverable 

5. a WG member creates a Git branch for their change/set of related changes in their local clone, and gives it a half-sensible name
- e.g. 'simon-dcat-type-vocabulary' 
and then only works on *one set of related changes* to *only one deliverable* in this branch

6. the WG member should push this _branch_ to the repository
- e.g. 
and also merge any subsequent changes that have been accepted in the gh-pages branch into the branch

7. When the change is ready for review, and has no conflicts with gh-pages (because you've done all the necessary merging from gh-pages) then the WG members should create a pull request to merge the branch into the head (i.e. gh-pages), and assign it to one of the editors for the deliverable (e.g. AP, dcat, ucr). Also link it to all related issues from 

Then in response: 

8. The editor(s) assigned to the pull-request reviews the pull request (proposed change), and either accepts the request and merges the proposed change into the deliverable, or opens a discussion, by adding comments to the pull request, until resolved.  

Sorry - I use a graphical Git client (SourceTree) so I don't have the cmd line scripts for all this to hand. 
There are many other graphical clients available if you don't like SourceTree - 

[1] It might be acceptable to bend the rules for 'typos' but the boundary can be a bit grey, so it may be simpler to apply the rule to all changes and just ask contributors to mention when they think the change is just a typo so that the editor can process it quickly. 

Simon J D Cox 
Research Scientist
Environmental Informatics
CSIRO Land and Water 
E T +61 3 9545 2365 M +61 403 302 672
   Mail: Private Bag 10, Clayton South, Vic 3169
   Visit: Central Reception, Research Way, Clayton, Vic 3168
   Deliver: Gate 3, Normanby Road, Clayton, Vic 3168
The information contained in this email may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this email in error, please delete it immediately and notify the sender by return email. Thank you. To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. 
Please consider the environment before printing this email.

Received on Monday, 31 July 2017 15:32:44 UTC