Chore(#68): Add development guidelines

[andybeet]

Justification

For better collaboration suite of files added. Pull request templates, workflow formating checks and contributing guidelines. The repo also needed formatting to air standards.

Fixes #68

Types of changes

What types of changes does this pull request introduce? Put an x in the boxes that apply.
This will inform the new release number.

• Fix (non-breaking change which fixes a bug)
• Feature (non-breaking change which adds or changes functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Other change (if none of the other choices apply)

Reviewer instructions

Take a look at the CONTRIBUTING guidelines and the CODE_OF_CONDUCT in case we need to modify them for this repo. The ymls are directly from Rstudio folks as is the advice of toml use. See below for notes on Air and its use

Formatting

This repo contains an air.toml file that automatically formats code to a set of standards.
It is preferred that contributors and reviewers install the Air formatting tool.
Code submitted in this pull request will be automatically checked for correct formatting.

[andybeet]

@jmhatch when you get some time can you review this PR

[jmhatch]

@andybeet Sorry for the delay, I'm going to try and finish this today. I'll be out on the water until the end of the FY, but can pick it back up again in early October.

Ok, I read through the CONTRIBURING and CODE_OF_CONDUCT *.md files. I thought they were great! Comprehensive and well written. I have some very minor thoughts below, but none of that is a sticking point. Happy for this to move forward and be incorporated. Nice additions!

• In CONTRIBUTING.md, under Asking Questions: I'm wondering if we could mention that folks with questions can ask them on the GitHub repos Discussions?
• In CONTRIBUTING.md, under Acceptable Types: I'm wondering if style should be restyle to align with the sentiment of refactor?
• In CONTRIBUTING.md, under Coding Style: What about adding more guidance around naming files. For example, this is primarily a data package but there may be opportunities to include some functions to do certain tasks. To easily distinguish purpose in the R folder it might be helpful for data docs to be named data-[data_name] or whatever. When to use hyphen vs underscore? That kind of thing. What do you think? Looks like we've been doing this, so it would just be formalizing it. Or maybe the air styling covers this?
• In CONTRIBUTING.md: I may have missed it, but what distinguishes a maintainer from a contributor? When someone submits a PR and it gets accepted, they'll be listed as a contributor on the repo. At what point do they start becoming a maintainer (if they want to be or if they are submitting a bunch PRs)? I guess, what would the process be?

[andybeet]

Thanks Josh. Cant take all the credit. Coworker did most of it. To address you points.

1. Yes, i'll edit that
2. These guidelines were taken from converntional commits. Somewhat of a recognized industry standard. We did not make them up, so we felt like it was better to use an already created standard.
3. I like that. The air styling is just a formatter, and uses the tidyverse style guide as a template. But we probably should say something about file names.
4. Maintainer is someone responsible for the general upkeep of the package. Contributor someone who works on bugs/features etc. The maintainer is responsible for deciding the direction of the package, managing the issue boards, point of contact etc. There can be multiple maintainers, but i think CRAN only recognizes/allows one. We should see if we can get both you and I listed as maintainers

[andybeet]

@jmhatch made minor changes as suggested. If you would like to wordsmith, let me know.

[jmhatch]

@andybeet Looks good! No wordsmithing on my end. And to address your point 4, I think you should be the sole maintainer. I was just wondering if we wanted to add some verbiage to the docs about how to become a maintainer if someone were interested. Probably not needed, or could just say somewhere "If interested in becoming a maintainer, please contact Andy Beet"? IDK.

[jmhatch]

Looks good! @andybeet addressed some very minor comments in an earlier comment.