FAVE development pattern

[JoFrhwld]

Related to the issue I opened in the .github repo, I thought I should outline the development pattern I've been trying to follow, and get any thoughts or feedback, so that we can have a clear structure for anyone new wanting to contribute.

Repo Setup

Not a concern for new contributors, but a pattern I would like to follow for new repos is

• The default branch is dev. Makes managing pull requests easier, and keeps the released version cleaner.
• We release from main, including
  • gh releases
  • publishing to pypi or cran
  • docs (either readthedocs or gh pages)
• We should set up the testing and continuous integration framework early (the templates @chrisbrickhouse put together should really help)

General Dev

• No commits directly to the dev or main branches. They get updated by pull requests alone (this can be semi-enforced by github)
• Any incoming PR should have an issue associated with it. Even if it's a post-hoc issue written after all of the development has been done, just as a system of signaling what's happening and why.
• Ideally, development will be done in branches associated specifically with an issue, or a set of issues.
• Substantial addition of code should also be associated with addition of tests. Perhaps example tests should be included in a Contributing.md.

Scope of branches and PRs

Ideally, to make reviewing contributions manageable, the scope of branches and PRs should be as narrow as possible. Admittedly, I didn't follow this at all when implementing Points into aligned_textgrid. Some beefier updates and features may require a more specialized approach? Perhaps:

flowchart LR
main --> dev --> bf[big feature]
bf --> component1
bf --> component2
bf --> etc[...]

Loading

Each component gets PRs back into bf. We may need to update the continuous integration to run on pull requests to big feature branches. Once the big feature is finished, we can have a big PR back into dev.

Managing Pull Requests

• Needless to say, all tests should pass!
• Some regression in testing coverage isn't the end of the world, but if it's significant, tests should be added before accepting the PR.