Publish contributing guidelines

[klebba]

Developers have found their way to this project organically (cool!). Some folks have graciously offered pull requests, however we still have not published any guidance regarding what is expected of contributors.

We'll need to spell out a few basics in doc/CONTRIBUTING.md:

• collaboration discourse must remain respectful and on topic in order to be reviewed or considered by project maintainers
• changes must be proposed, discussed, and accepted by project maintainers in an issue thread before expecting pull requests to be reviewed by project maintainers (this aims to mitigate frustration and squandered developer time)
• diff proposals must come in the form of a pull request
• diff proposals that resemble comprehensive GenAI refactors will be rejected outright
• maintainers can not offer any guarantees of timely responses or deep engagement at this time

Look to other projects for examples, e.g.:

• https://github.com/Netflix/vmaf/blob/master/CONTRIBUTING.md
• https://github.com/lit/lit/blob/main/CONTRIBUTING.md

[klebba]

FYI @theengineear

[Kelketek]

Thanks for putting this forward, @klebba . It definitely will be helpful for folks such as myself stopping by to contribute :)

changes must be proposed, discussed, and accepted by project maintainers in an issue thread before expecting pull requests to be reviewed by project maintainers (this aims to mitigate frustration and squandered developer time)

Would this include bugfixes or documentation updates? I think it would be good to specify that this longer process is for refactors and new features, but I think something like smaller bugfixes and documentation updates should have as low a barrier as possible, so long as the change is small/straightfoward and doesn't change any APIs.

Another thing that would be good while we're at it is to define templates for issues, pull request templates, etc. Since the project is relatively low volume/visibility still, these could be much simpler than the ones in lit/lit. My favorite issue template for bugs was something like:

##  Briefly describe the issue

Enter a overview of the issue here.

## What do you do to trigger the issue?

1. Describe a step by step process
2. To reproduce the bug
3. If possible, link to a sandbox, such as a [jsfiddle](https://jsfiddle.net/) or similar

## What unexpected thing happens when following the directions above?

Describe the behavior triggered by the steps in the previous section.

## What should happen instead?

Describe the behavior you expected to encounter after following the above steps.

GitHub allows templates for multiple issue types as well, so we could do them based on features/bugs/documentation requests (such as requests for cookbook examples)

This could be a separate issue if you prefer, though. If you like, I could create a PR to include these items, as well as some contributor text including the rules you mentioned above. I actually kind of like writing documentation :)