Git Workflow

Initial suggestion for guiding principles as posted to issue #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 guide https://style.tidyverse.org/. Most of the existing code vaguely follows this style with the exception of the object names, which are a mess. The styler::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 then devtools::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

Releases

CRAN releases of r4ss should follow (at least approximately) this checklist https://github.com/ss3sim/ss3sim/wiki/cran-checklist (which could be pasted into the GitHub Project https://github.com/r4ss/r4ss/projects/1 or a new issue)

Provide feedback