Group must have some website that makes it clear what the goals and responsibilities of this group are
All technical discussions must be stored in a publicly accessible location, for example:
GitHub issues
GitLab issues
Mailing list archives There is an obvious exception for confidential matters such as financial and security related information
It should be clear what decisions the group has taken, and what are under discussion (if it’s that kind of group). A good example of this are the GHC Steering Committee proposals, but a simple email to a public list can also suffice.
The group must have a voting system in place in case it cannot reach unanimity. Votes must be accompanied by reasoning, and a tie-breaking mechanism should be in place.
The group’s website should list its members (with their affiliations and terms), and the membership rules.
Groups should appoint a chair (or co-chairs) or a contact for Haskell Foundation.
Groups should ensure a turnover of membership, for example by setting terms.
This only makes sense for "decision-making" bodies, not really for groups that just focus on doing work.
The process for appointing new members should be clearly set out:
There should be a “way in” for new members who are not already part of the “in crowd”; for example, a regular opportunity to self-nominate.
Criteria for new members should be written down, so that new members can address them in writing a self-nomination.
A reasonably broad group of people should be involved in making appointment decisions (e.g. not just the chair). Typically the whole group votes on appointing new members.
Groups must adopt the Guidelines for Respectful Communication. Groups may additionally adopt other guidelines & CoCs that are stronger; as long as they do not conflict with the GRC.
Why make a code of conduct as part of HF affiliation?
We want the Haskell community to be welcoming, diverse, and inclusive. Having explicit guidelines for respectful communication signals that desire, and makes it more explicit and concrete.
For all of us, as individuals and as groups, making an explicit commitment to respectful communication encourages us to review our messages to see if they meet the goals set out in the guidelines, and will give others some specifics to point to if we fail.
The project must have a public issue tracker and/or mailing list where discussion about the project takes place
The expectation is that the project has at least one responsive maintainer. If this is not the case, it should be clearly signalled that more resources are required.
The project must be open to community discussion about possible features and contributions.
The project should encourage new contributors and members, i.e. there should be "a way in".
Just like committees, the project must adopt the Guidelines for Respectful Communication as a code of conduct.
