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> 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 T +61 3 9545 2365 <(03)%209545%202365> M +61 403 302
> 672 <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
> orcid.org/0000-0002-3884-3420
> researchgate.net/profile/Simon_Cox3
> 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.
>
>
>
>

Received on Monday, 31 July 2017 22:16:32 UTC