MPS repository is not set up for public contributors

[rptb1]

The MPS is in transition from being an open source project with private commercial management to being a public open source project curated on GitHub (and possibly elsewhere). Many of Ravenbrook's internal quality practices may not be compatible with this change, and need to be reviewed. I am raising this issue to track progress on modifying the repo with docs and settings that make it more suitable.

The GitHub docs contain a lot of useful guidance, and in particular “Setting up your project for healthy contributions”. I would like to ensure that we have dealt with every point in that section in some way, and record that here.

[rptb1]

GitHub's Open Source Guides are another excellent source of checklists, and I think we should also work through them, but I intend this issue to be closed when the setting up guide is completed.

[rptb1]

In the section “About community profiles for public repositories” GitHub recommends using the Community Profile checker. Here is a snapshot of how it looks now:

This indicates:

1. We are missing a README. We aren't, but we should fix whatever is causing GitHub to miss it. It probably has to do with it being a symbolic link.
2. We do not have a code of conduct.
3. We do not have an issue template. We should adapt our Perforce “jobspec” for this purpose.
4. We do not have a pull request template.
5. We do not have repository admin content reports.

In addition, our contribution guidelines do not cover the points in “Setting guidelines for repository contributors”, nor are all the review rules visible to the public.

[UNAA008]

Brief additional notes:

1. Ravenbrook has a set of internal rules that we could publish as background reference material illustrating the origin of some of the practises in the development of the MPS.
2. Some of that material might be merged with documents already in the MPS such as https://github.com/Ravenbrook/mps/blob/master/design/guide.impl.c.format.txt
3. Promote practises that smooth the path for accepting pull requests without imposing demoralising overheads and delays on contributors.
4. Helpful to address (3) is to raise minor difficulties as issues (possibly with explicit cross-referencing source code commentary) rather than imposing actions on contributors.

[rptb1]

1. We are missing a README. We aren't, but we should fix whatever is causing GitHub to miss it. It probably has to do with it being a symbolic link.

GitHub has become smarter and now credits us with a README.

However, it now says we should have a security policy.

Other results unchanged.