docs: add contributing guide (resolves #182)

[greatislander]

• This pull request has been linted by running npm run lint without errors
• This pull request has been tested by running npm run dev and reviewing affected routes
• This pull request has been built by running npm run generate without errors
• This isn't a duplicate of an existing pull request

Description

Expands README to include contributing instructions.

Related issues

• Resolves Add contributor guide #182.

[cindyli]

@jobara's input on this pull request would be valuable. He's experienced dealing with with licensing, readme languages etc.

[jobara]

I'm struggling a bit with the dev content in the README vs the CONTRIBUTING file, but can't quite put my finger on it. I get the feeling like I need to go back and forth between the two documents. Maybe that's okay, but not sure. If you can think of any further ways to improve this, please add them otherwise I guess we can leave it for later.

Regarding the "release" tool. I believe it saves the release info straight to GitHub.

1. can we automate this with GitHub Actions. I suppose we might have to do some determining of the type of release if there isn't an API for that.
2. if we don't use GitHub actions, do we want to include this info in the readme or a change log that's stored in the repo and included in the tag

[greatislander]

I'm struggling a bit with the dev content in the README vs the CONTRIBUTING file, but can't quite put my finger on it. I get the feeling like I need to go back and forth between the two documents. Maybe that's okay, but not sure. If you can think of any further ways to improve this, please add them otherwise I guess we can leave it for later.

My differentiation strategy is: technical guide in README, process guide in CONTRIBUTING. We can always adjust/improve later though, as you say.

Regarding the "release" tool. I believe it saves the release info straight to GitHub.

When you run release, it:

• bumps the version based on the semantic versioning strategy (patch, minor, or major)
• provides an interactive prompt which walks you through each commit since the last tag to build a changelog
• commits, tags, and pushes the new version to GitHub
• opens a draft GitHub release with the generated changelog (example)

1. can we automate this with GitHub Actions. I suppose we might have to do some determining of the type of release if there isn't an API for that.

Yes, this is definitely something we can explore but feels low priority at the moment.

2. if we don't use GitHub actions, do we want to include this info in the readme or a change log that's stored in the repo and included in the tag

I think the GitHub release notes are sufficient but we can look into storing them in a changelog as well, but I'm happy with the approach that is in place right now.

[jobara]

I think the GitHub release notes are sufficient but we can look into storing them in a changelog as well, but I'm happy with the approach that is in place right now.

There's an issue related to this filed against release. Adding here for reference.

[jobara]

I couldn't figure out a way to test the release scripts, but they looked correct. On the bright side, if they don't work, I guess it won't publish the release. So the risk seems minimal.

Resolved.