Formalize community standards

[g5t]

GitHub has documentation for healthy contributions to an open source project, and suggests defining a code of conduct and
contributions guidelines.

Should McCode add this sort of documentation in order to formalize our expectations of and from contributors?

I think much of the information in the pull request template could be moved or duplicated in one or both of a Code of Conduct and Contributions guide.
I'm sure there are more expectations within the McCode developer community which could be collected there as well.

[g5t]

One idea I think would be worth formalizing: rules for changing the code generator.

A non-exhaustive list of what I think we could define:

1. What types of code generator changes are generally supported

• grammar changes are
  • good
  • bad
• bug fixes are
  • good
  • bad
• other changes are
  • good
  • bad

2. Who is responsible, accountable, consulted, or informed for changes
3. How changes are proposed, decided, and implemented

[willend]

@g5t thanks for bringing up the point / raising the discussion. I think we should initially have a round of this together at DMSC.

[willend]

But yes I agree that it is probably time for a little more rigour in handling the (rare but not so rare) cogen changes... Immediate thoughts:

• Let such a PR stay in DRAFT as long as discussion is ongoing
• Require a review on such proposals / changes - maybe even set a minimum of 2 other peer McCode++ devs?

(And yes one person that might have an initial difficulty with this is myself, had many rounds of 'I'll just fix that in the code generator' in the past...)

[mads-bertelsen]

I think it's a good idea to avoid unwritten rules by writing them down. There are a lot of balancing acts trying to take different considerations when making decisions, and those kinds of values would be good to state. For example that we avoid doing things that could never work on GPU as it's a goal to port things, and that is not immediately obvious to contributors. The meaning of DRAFT in our little corner is also a good thing to specify.

In relation to the code generator, that is a central part of the code that has changed a lot over the years, often it has improved performance or offered new features. I think it is sensible we document whats done there in the ADR's as it's important, but in my opinion it would inhibit the project necessarily to put red tape around it.