Add notes about email addresses and groups

This adds a new section to our working conventions, describing how we use HF email addresses. There are a few policy prescriptions here, but nothing that would seem to require an official vote. I would love feedback on this, regardless.

working-conventions.md

 # Working Conventions
 
-This document describes the working conventions of the Haskell Foundation Board.
-No text here is binding, in any way. This simply serves to document standard practices
+This document describes the working conventions of the Haskell Foundation.
+This simply serves to document standard practices
 and ways of working that we have found beneficial.
 
+While principally maintained by the Board, this document concerns both Board
+activity and employee activity. As such it is something like an HF handbook.
+Anyone (Board member, HF employee, general public) is invited to suggest
+changes to these working conventions if a better way exists.
+
 ## Making decisions
 
 We want the Board to work together to make decisions; this requires building
@@ -115,6 +120,7 @@ leaves or joins the HF Board, all of these places will need to be updated:
 1. The [website](https://github.com/haskellfoundation/haskellfoundation.github.io).
 1. Any HF Board calendar items, such as the invite list for our regular meetings.
 1. Any admin privileges in the Google Workspace.
+1. Various Google Groups hosted at `haskell.foundation`.
 
 ## Technical credentials
 
@@ -125,4 +131,112 @@ leaves or joins the HF Board, all of these places will need to be updated:
 list is where the public can submit (self-)nominations for Board seats, a process managed
 by our Secretaries. Other HF people may also be included in the distribution list if helpful.
 1. The Chair, Vice Chair, Secretary, Vice Secretary, and Executive Director are Owners of the `hf` group on [Haskell's GitLab instance](https://gitlab.haskell.org/hf). All other board members are Developers in this group.
-1. The membership of the [GitHub `haskellfoundation` group](https://github.com/haskellfoundation/) is flexible; members of the public can be added when it is convenient to do so. The Chair, Vice Chair, and Executive Director are Owners, and there may be other Owners outside the HF.
\ No newline at end of file
+1. The membership of the [GitHub `haskellfoundation` group](https://github.com/haskellfoundation/) is flexible; members of the public can be added when it is convenient to do so. The Chair, Vice Chair, and Executive Director are Owners, and there may be other Owners outside the HF.
+1. The Executive Director, Chair, and Vice Chair are all Super Admins of our Google Workspace.
+   The ED (with the agreement of the Chair) may also delegate Super Admin status to others.
+   Accordingly, the Chair and Vice Chair must have accounts in the Google Workspace; these
+   are `chair@haskell.foundation` and `vice.chair@haskell.foundation`.
+
+## Email accounts
+
+This section is mostly informational and lays out how we make use of `@haskell.foundation`
+email addresses. There are a few policy decisions, however; these are in **bold**.
+
+### Users vs. Groups
+
+Our Google Workspace instance supports two different kinds of email address: a *user* address
+and a *group* address.
+
+1. A workspace Super Admin (among lesser, currently unused admin roles) can create users and
+   groups. Should we find it helpful, the Google Workspace interface allows us to designate
+   a new admin role that is not a Super Admin but can create and/or remove users and groups.
+
+1. User addresses:
+
+    1. A user address comes with an entire Google account, with all the features one expects
+       with an account: separate email inbox, calendaring, contact databases, user credentials, etc.
+    1. User addresses cost money: the current rate is $6/user/month. Once we get our official non-profit
+       status from the US government, this charge may disappear.
+    1. User addresses can be configured to forward mail to another address, just like any other
+       Google account.
+    1. A user address is required for an email address to appear in the "From:" field in an email
+       message.
+    1. User addresses can receive mail from any email address.
+    1. User addresses support an auto-reply feature, where incoming email messages are greeted
+       with an immediate response. (This is often used for a holiday alert, for example.)
+    1. User email is private: no one else at the organization can access a user's email.
+       (This can potentially change, if we upgrade our Google Workspace to allow
+       [investigations](https://apps.google.com/supportwidget/articlehome?hl=en&article_url=https%3A%2F%2Fsupport.google.com%2Fa%2Fanswer%2F9300435%3Fhl%3Den&product_context=9300435&product_name=UnuFlow&trigger_context=a).)
+
+1. Group addresses:
+
+    1. A group address is just an email address; it is not associated with an account.
+    1. A group has a list of members. Each member generally receives a copy of each email sent to
+       the group address. Members can configure their email delivery, and can choose to
+       receive messages in digest form or not at all.
+    1. Groups optionally have an archive feature. This archive supports various custom settings,
+       including the ability for it to be fully public.
+    1. It is possible to moderate a group address, where messages from outside the group (or
+       outside the `@haskell.foundation` email address space) are held for moderation.
+    1. It is not possible to send email from a group address.
+    1. It is possible to add one group to another, creating a hierarchical structure. This is
+       useful to declare, for example, that all messages about invoices should be delivered to
+       the Treasurers; by making the Treasurers a group, we can update the list of Treasurers
+       in one place, instead of updating them in every group where they appear.
+    1. Groups addresses support an auto-reply feature, where incoming email messages are greeted
+       with an immediate response.
+    1. Group email content can be viewed by certain users with admin privileges.
+
+1. Each user address comes with a reputational risk to the Haskell Foundation: because these
+   addresses can send email, users with a `@haskell.foundation` email address can be seen to
+   represent the HF. Misuse of this email address thus poses a potential risk.
+
+1. Each user address also comes with a monetary and organizational cost. The monetary cost
+   is noted above, but the organizational cost also comes in the form of credentialing and
+   access management.
+
+1. Accordingly, we prefer *group* addresses over *user* addresses. More specifically, a *user*
+   address should be created only when one of the following holds:
+
+    1. The email address will need to send email.
+    1. The owner of the address needs special access to Google Workspace resources.
+
+### Longevity
+
+1. Individual affiliates (employees, Board members, committed volunteers) of the HF may request an
+   `@haskell.foundation` email address. **The ED is responsible for granting these requests and managing
+   our email namespace.**
+
+1. All email addresses come with an additional risk of being ignored.
+   If someone reaches out to the HF with email to a `@haskell.foundation` address, they reasonably
+   expect their email to be read and responded to in a timely fashion. Each address we support
+   thus increases our risk for lost communication.
+
+1. Accordingly, it is good practice to review our email addresses periodically and retire
+   users and groups that are no longer active, once we are sure that the address will no longer
+   be used.
+
+1. When an individual affiliated with the HF ends
+   their affiliation, they must decide what to do with their email address. As a courtesy,
+   **this address can remain active beyond the end of their affiliation, up to a maximum of 6 months.
+   The lifetime of an address can be extended by decision by the ED or Chair/Vice Chair of the Board.**
+
+1. When retiring an email address, if we expect that lingering references to the address exist,
+   it can be converted into a group containing the special member `deprecated@haskell.foundation`
+   (described more fully below). The group is then set up with an auto-reply that directs the sender
+   where they should address their email in the future.
+
+1. The group `deprecated@haskell.foundation` is a catch-all to receive email sent to deleted
+   email addresses. It can be monitored periodically to see if we are missing any important
+   communication. In addition, it is a useful search term in the Groups control panel for filtering
+   groups that are deprecated.
+
+### Group Membership
+
+1. The groups `chairship@haskell.foundation`, `treasury@haskell.foundation`, and `secretariat@haskell.foundation` exist. Each group contains the appropriate Officer and Vice Officer or the Board.
+
+1. Various important functions of the HF are expressed as groups. (Examples: receiving job applications,
+   offers to volunteer, offers of sponsorship.) **Each such group must have a minimum of at least two
+   members.** If only one employee of the HF is a suitable member, then typically a Board member
+   will join the group, possibly using the Officer groups introduced above. Each such group should
+   generally have one designated member who is responsible for responding (e.g. the ED).