On development process and governance

[torfason]

Development process

Development happens on the dev. Contributions are merged from forked repos to dev through pull requests. Stable changes are then either migrated to the main branch for wider testing before a release, or are migrated upon the next release.

There is a preference for a relatively clean linear commit history in the main branch, so it it great to keep each issue fix to 1-3 commits unless it is that much bigger. No worries though about submitting incremental pull requests, they can be rebased at the end, by either submitter or maintainer, to get back to a few logical commits with an end result for which all tests and checks pass. A recommended default commit structure is:

• Tests first in a single commit, allowing examination of how they fail before a feature/fix is implemented
• The implementation code in a second commit (this should fix the tests)
• Documentation, including updates to NEWS.md and a version bump, in a third commit

The project now includes a build/build_and_release_process.R file. Contributors are kindly asked to run the code in this file prior to pushing any commits, and make sure that it (a) runs with out error and (b) does not result in unexpected modifications of project files. Among other things, the script regenerates autogenerated files, such as the *.Rd and README.md files, to correctly reflect changes in primary source files.

Governance

For anyone interested in getting involved, it might be good to give some background on the governance of this project:

The package was written by @smbache, but the package is currently maintained by @torfason. The philosophy that they share regarding import includes among other things:

We do not have the resources to "move fast and break things" so slow and steady is the way to go

Therefore:

• New features should be backwards compatible unless there is an extremely compelling reason
• New features should generally be documented as well or better than existing features
• New features should generally have as good or better test coverage than existing features
• When it comes to choosing features both demand and supply are important
  • Demand in terms of the number of people who comment on an issue
  • Supply in terms of help with implementation

Within this philosophy, I would very much like to make any decisions on consensus, and would be most interested in hearing from people who have submitted or commented on bugs already, since they clearly care about this project in one way or another.