RE: GIthub workflow for DXWG group

When a pull-request is accepted, the branch should be deleted.
Don’t worry -

-          It is still in the history, it just doesn’t appear in the list for the head

-          You can create another branch with the same label later if you do more changes with a similar scope – it will not clash (the label is not the identifier)

Simon

From: Rob Atkinson [mailto:rob@metalinkage.com.au]
Sent: Tuesday, 1 August, 2017 08:16
To: Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>; public-dxwg-wg@w3.org
Subject: Re: GIthub workflow for DXWG group


in #4,   s/directory/gh-pages branch/   ??

What is the policy for pruning branches - I've seen some projects with hundreds of branches left lying around and they do get in the way sometimes.

In addition, there are mechanisms for creating forks - and co-editors might find it useful to work on a fork, merge, and finally create a single PR for big changes.  My feeling is that the wider team ought to be able to follow PR granularity grouped commits on the main repos to see significant changes.

Rob




On Tue, 1 Aug 2017 at 01:32 <Simon.Cox@csiro.au<mailto:Simon.Cox@csiro.au>> wrote:
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 https://github.com/w3c/dxwg such that

1. there is a _directory_ for each deliverable, so far
- https://github.com/w3c/dxwg/tree/gh-pages/AP

- https://github.com/w3c/dxwg/tree/gh-pages/dcat

- https://github.com/w3c/dxwg/tree/gh-pages/ucr


2. Note that the default branch is gh-pages https://github.com/w3c/dxwg/tree/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. https://github.com/w3c/dxwg/tree/simon-dcat-type-vocabulary

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 https://github.com/w3c/dxwg/issues


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 - https://git-scm.com/downloads/guis



[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 simon.cox@csiro.au<mailto:simon.cox@csiro.au> T +61 3 9545 2365<tel:(03)%209545%202365> M +61 403 302 672<tel:0403%20302%20672>
   Mail: Private Bag 10, Clayton South, Vic 3169
   Visit: Central Reception, Research Way, Clayton, Vic 3168
   Deliver: Gate 3, Normanby Road, Clayton, Vic 3168
people.csiro.au/Simon-Cox<http://people.csiro.au/Simon-Cox>
orcid.org/0000-0002-3884-3420<http://orcid.org/0000-0002-3884-3420>
researchgate.net/profile/Simon_Cox3<http://researchgate.net/profile/Simon_Cox3>
github.com/dr-shorthair<http://github.com/dr-shorthair>

PLEASE NOTE
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.