Repository updates for github workflow

[drsteve]

This pull request adds a few things to make life on github a little easier for contributors and maintainers alike.

I've added:

• A draft code of conduct, which is strongly encouraged across the open-source world.
• A markdown file with basic instructions on maintaining a clean workflow when using forks in git.
• A .github directory where the magic markdown goes for:
  • A template that auto-populates new issues to give hints on how to write a helpful issue/bug report.
  • A template that auto-populates new pull requests to ask the requestor for details that will help maintainers with reviewing and merging the PR.

Some suggestions for merging this and future PRs:

• I'd suggest that the main branch on this repo is protected, so that all updates come through pull requests. I believe the permission for that only belongs to repo owners.
• Similarly, I'd suggest having someone who isn't the code author merge the pull request. That'll mean making sure an adequate number of developers have permissions to merge.
• Finally, unless there's already a plan on the PRBEM side for the merge strategy I'd suggest setting the repository to only allow merge via rebase. This provides a linear history. The downside is that when multiple PRs are waiting to be merged they can get out of sync - so occasionally the PR will have to be updated (by updating main, rebasing the PR branch against main, and then force-pushing the PR branch). On other projects I've not found this to cause any problems... especially since maintainers can do this for the PR submitter if required.

[AntoineBrunet]

@mshumko I had not merged the PR after the review, it should be closed now.

[drsteve]

Thanks @AntoineBrunet and @mshumko for the feedback and questions. Updating the README is a good idea, but I was hesitant to do that in this PR. I really just wanted to add the new templates, etc. Since @AntoineBrunet had a question about that, and it's easy to add commits to a PR, I'd assume that's why he didn't merge.

IIRC (I'm on mobile so it's harder to check) the repo has README.install and not a markdown document. It's probably more of a discussion for an issue than for this (now merged) PR, but since it's really install instructions and not a general readme it'd be useful to expand with, e.g., a brief description of library capabilities, notes to point folks to the issues and discussions on the GitHub page if they have problems (should be first port of call rather than direct contact), point folks to files with more info on workflow, etc.

Also, I note that this was done as a merge commit. Is that going to be the preferred method for merging going forward? Or is it a function of still getting familiar with the options, setup, and how the different strategies manifest? Either way, it's good to document and I'd suggest adding the repo's merge strategy to the WORKFLOW.md once it's agreed on (as a reference for developers and as info for contributors.

[AntoineBrunet]

@drsteve Sorry for the mixup, I agree with you that rebasing is better, I did not notice the option when merging the PR, but from now on I suggest we use the rebase strategy.