This is a small tweak to our bylaws to allow retiring members to vote on the new board makeup, as long as they are not seeking another term.
Because this is a change to the bylaws, it requires a 2/3 majority vote (currently 9 members). Please click the blue Approve button to vote in support of this change.
According to our rules for Merge-Request-based voting, this vote will conclude two weeks from today, on Monday Feb 13. This comes after we put out the call for new applications, but I think that's fine. If we want to rush this vote, 2/3 of us can vote for early cloture, but I really don't think it's necessary here.
process a *departing* member. This includes both members whose terms are ending
We have officially settled on Slack as our informal, asynchronous and unofficial chat application. There are new points of difference decided on a recent call between myself, Michael, and Tom:
Anyone is allowed in. We'll have to determine a moderation policy as a result, but we feel an open forum is better in this case.
We will announce this officially, and provide an open invite link, which will be posted on social media and be given its own entry on the HF website.
The existing rules written in communications.md
are already sound with respect these changes, and need only a small update with the relevant info.
This updates the Executive Committee (né Executive Oversight Committee) charter.
Due to the important nature of this committee, I would like to use normal voting rules here, not our MR rules. Accordingly:
We should, of course, hold ourselves accountable, but the conventions described in this section never took root and seem unlikely to.
An alternative to accepting this MR is to commit to using the structure written here.
I will merge after spotting a few approvals. This does not require an official Board Vote.
Add publicity committee
As part of the Ways of Working Project Plan, we have to form a plan to deal with donations/sponsorships of a questionable nature. @copton and I, at a recent meeting, decided that the best way forward was to form a standing committee which could adjudicate individual cases.
The idea is that the ED would flag specific donations as worthy of deliberation, and then the Donations Committee would meet on an ad-hoc basis to decide whether to accept or reject the donation.
The document ends with a number of specific considerations we felt would be helpful in making these decisions, but these are not definitive.
@copton and I together planned out the general shape of this approach, including the specific guidelines at the bottom. I worked alone to craft the text in this MR.
Refreshing the nominations@hf list for the 2022 board member nominations process.
@Kleidukos @dreixel are our secretaries and have been added to the list.
This does not need full board approval.
After some negative feedback on !33, I am trying again. This particular design came out of a discussion that arose at the end of today's quite-successful social event (thanks, @trac-Niki!). It requires a 2/3 majority to close off debate and is designed to work well in an asynchronous vote.
For clarity: though the general design came from a discussion, this text is by me alone.
This will require a 2/3 majority vote to pass, which translates to 9 Approvals.
Deadline: 1 week from today (10 Feb). This deadline means that this rule will not be adopted before 10 Feb.
I think this is a good way of allowing the board to take decisions on simple, non-controversial, or time-bound issues during a single meeting, for example. I'm happy with it.
Yes, I think that's part of the point. On the other hand, we also have discussions that are quickly concluded during a board meeting, yet currently will need to sit for a week to be passed. Do you have any suggestions how to address that problem in another way?
I think it's good for us to have a stated policy around who gets access to what. In thinking about this today, I realized, for example, that the internal mailing lists had only one owner: me. This is potentially problematic, and so I added Tom, as Vice Chair.
There are other bits of credentialing that should be detailed here. Please feel free to add to the list, or suggest changes to policy. My goal here is to document the status quo, not necessarily to say this is how it should be (though I don't see any need for changes).
This is not an Official Board Policy, per se, and does not need Approval for merging. But I'd still be happy for eyes on this.
"Owners in" vs " Owners of" in the previous line.
dreixel (a985ca16) at 15 Jan 09:03
Minor change to improve rendering
Our draft, proposed bylaws (!25) include a clause saying that if a board member misses 25% or more of the meetings in the previous 12 months, they are liable to be dismissed from the board. This MR echoes this clause in the vastly more approachable board.md document.
Please consider this one carefully -- the policy described here has more bite than many.
The text in this MR was drafted by me (Richard) alone, but the idea comes from the Ways of Working committee.
Arising out of a conversation on the mailing list, this change to our voting rules will allow more MRs to be merged with less fuss.
(My editor has stripped trailing whitespace here. The payload is just at the very bottom of board.md.)
Yet more material from our still-busy Ways of Working committee, on our commitment to transparency. Please review!
Do we have a donation policy? Can we link to it from here?
Beyond our formal rules of engagement, we as a body are picking up various working conventions. These are not rules, but rather ways in which we routinely conduct our business, and it's helpful to write them down -- both as a way of inducting new people into the fold and reminding ourselves how we operate. I've tried to capture some existing conventions and introduce a few new ones in this MR.
Highlights:
internal
(actually already in existence, but unused, at https://gitlab.haskell.org/hf/internal) where we would create lightweight Issues to track a task to be done. We can then perhaps make a deliberate choice to abort a task deemed unnecessary, but it seems less likely we will simply forget.I'm hoping this document grows over time as we establish further working conventions.
Please provide feedback! This was not drafted by a committee and so may contain all manner of errors, both in design and in execution. :)