- Notifications
You must be signed in to change notification settings - Fork38
Git Workflow
Ian Taylor edited this pageJul 9, 2020 ·9 revisions
Initial suggestion for guiding principles as posted toissue #77:
- Have a lead package maintainer but also have other contributors who are willing to step in when things need to get done and the lead person is unavailable. I'm happy to continue in this role but am open to negotiations about that.
- Be welcoming to suggestions and contributions in many forms (including to this list of principles).
- Allow anyone contributing a new function to be lead author of that function and manage future edits and retain some control over the coding style and aesthetics of any figures that are created.
- Encourage contributors to follow the tidyverse style guidehttps://style.tidyverse.org/. Most of the existing code vaguely follows this style with the exception of the object names, which are a mess. Thestyler::style_file() function has been used on a few files to automatically clean up the code.
- Encourage the use of branches, forks, and pull-requests but not let confusion about that process stand in the way of progress especially when a simple change to the trunk is not likely to break anything important.
Revisions based on more recent practices:
- Default to have straightforward changes pushed to the "development" branch where they can be tested and reviewed before merging into the trunk (i.e., master branch).
- Contributors should run
devtools::document()and thendevtools::check()before issuing pull requests. This will ensure that the documentation remains more consistent with the code and will help catch potential issues due to changes by a contributor earlier rather than later. - We should wait until the tests have been completed on Travis-CI before merging any pull requests.
Minor details
- Commit messages should consider following the following format:https://github.com/nwfsc-assess/PacFIN.Utilities/wiki/Convention-for-commit-messages
Releases
- CRAN releases of r4ss should follow (at least approximately) this checklisthttps://github.com/ss3sim/ss3sim/wiki/cran-checklist (which could be pasted into the GitHub Projecthttps://github.com/r4ss/r4ss/projects/1 or a new issue)