Commit 07c204a4 authored by Richard Eisenberg's avatar Richard Eisenberg
Browse files

Merge branch 'communication-guidelines' into 'main'

Capturing our communication guidelines

See merge request hf/meta!23
parents cb6dec48 9d979f8b
......@@ -11,6 +11,50 @@ In thinking about communication, it is helpful to identify (at least) four diffe
This document refers back to these scenarios by number.
## Guidelines
The Board needs to be a functioning, cohesive group that collectively drives the Foundation's mission.
To that end, we have recognised that the communication guidelines below are helpful for avoiding accidental
miscommunication for when Board members communicate with one another.
These guidelines are not a list of requirements, nor a procedural mechanism that guarantees to avoid
miscommunication. But they serve as a mental checklist for things to consider when communicating. Use your
best judgement.
* **Avoid assumptions**: We all come from different backgrounds, have different knowledge, and have had different experiences.
When making assumptions about the others' state of mind, there is a risk of misunderstanding and miscommunication.
We all make assumptions very naturally in order to operate at all. Still, it's advisable to pause for a second,
and if in doubt, double check with your peer whether your assumption holds or not. On the flipside, recognise that if your
peer has failed to validate an assumption with you, this most probably was a simple oversight without ill intent. In such a
situation, it is best to approach them and sort it out in good faith.
* **Reach out early**: If you see situations you are concerned about -- or you don't understand but think you should -- do
not hesitate to reach out to your peers early. Maybe there is a hidden assumption. Maybe others haven't noticed yet.
Or maybe others disagree. Either way, we can only make progress as a group if we aling on these things, in particularly
if they have the potential to escalate.
* **Choose the right level of detail**: When addressing the group as a whole, avoid too-much-information but summarise the
key points instead. Focus on providing relevant context, calling out assumptions, an providing an overview of what is going
on and/or what you expect from your peers. In contrast, when interacting within a more tactical environemnt, e.g., a
committee or one-to-one, do work out the details required to make progress.
As a concrete example, here is a practical template for whenever you address the board for decision
making. Bolding text can be useful here for the part that is most important for individuals to read.
Also, we suggest to highlight the beginning of each section.
1. Concise statement of the problem being solved
1. Concise statement of the proposed solution (or multiple options, if the author is asking for
a decision rather than approval)
1. Discussion (details, analysis, and motivation)
1. Call to action (please vote, specific deadline, etc.)
* **Keep the group informed**: Our effectiveness to steer the Foundation and manage all activities
around it depends on our respective ability to develop fully-informed opinions and have situational
awareness. To this end, it is advisable that we keep this group informed about relevant topics.
The most relevant topics are those that may come up as a request for vote to the board. General
what-is-going-on updates are welcome as well.
## Asynchronous communication
1. Internal communication within the HF (Scenario 1) and from members of the community specifically addressing the Board
......@@ -129,6 +173,9 @@ The GitLab group currently hosts these repositories:
* `minutes`: Ratified minutes of official meetings. World-readable.
The GitHub organization currently hosts these repositories:
* `haskell.foundation-redux`: This is the repo for the newly designed website. World-readable.
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment