We invite existing Haskell projects, committees and communities to explicitly affiliate and align themselves with the Haskell Foundation. Affiliation means that the group supports the goals of the Haskell Foundation, and that the Haskell Foundation in turn supports this group. We require affiliated groups to adhere to guidelines around transparency, being open to new members, and follow the Haskell committee guidelines for respectful communication. We believe that this will help us grow towards being a more open and welcoming community.
Who Has Affiliated?
The following groups are affiliated with the Haskell Foundation:
The following groups are in the process of affiliating. This means they endorse the Haskell Foundation but are still in the process of adopting the new guidelines:
This is not a closed list! We very much want the Haskell Foundation to be something by all of us. Please contact us if you are interested in joining us in our quest to make Haskell better for everyone.
What Does Affiliation Entail?
Affiliation means that the group supports the goals of the Haskell Foundation, and, in return, the Haskell Foundation supports this group.
Different groups work in different ways, and it would be counter-productive to impose complete uniformity. However, we expect the groups that want to affiliate with the Haskell Foundation to follow a few ground rules, laid out below.
Affiliation does not mean that the HF is taking over control of that group’s bailiwick. The group’s powers and responsibilities remain unchanged, although it would be reasonable to expect the group to take into account the views of the HF.
We make a distinction between projects and committees.
- 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.
Code of Conduct
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.