Last month, we agreed on email to introduce a habit of reserving the final 15 minutes of board meetings for a private session, for Board members only. This MR codifies this decision (though does not mandate this new habit), and also states that we keep minutes of private sessions (as we have also agreed to do).
I do not see this as a policy change, just some institutional memory. Accordingly, I do not see a need for a formal vote. This post is merely for review, and I will merge after an Approval or two.
This seems like a good compromise to me.
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've been following the back and forth, and these last comments really crystalized it for me. I agree with @rae here: I don't see a reason to set up a structure where a 1-week period of delay is always required. If a majority of the board has come to a conclusion, delaying does not improve the decision making process. And even though we haven't yet needed to make urgent decisions, that seems like a reasonable thing to occur in the future.
I'll admit I'm not following all the nuances of different quorums and majority rules because I haven't spent the time to read this thoroughly enough yet, but some kind of "immediate decision" possibility seems prudent to me.
I had some concerns about this policy based on the title and description. After reading the text I think it's imminently reasonable. Nicely worded and well balanced!
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.)
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. :)
There had previously been discussion of simple changes that did not require approval, such as typo corrections. Advantage was to reduce burden of requiring a quorum for "obviously" (for some value of obviously) acceptable changes. Is that something worth pursuing?
Yet more material from our still-busy Ways of Working committee, on our commitment to transparency. Please review!
The previous language was ambiguous about whether one person can hold two "vice" positions. This is meant to clarify.
Please click the blue Approve if you are fine with this.
Note: My text editor made a bunch of whitespace trims in this commit, but the only textual change is about the vice positions.
Process wise: I'm totally in favor. Tooling wise: that would mean opening up more people to have override-merge rights. People seemed hesitant about that previously, which is why I was thinking of the just-one-merger approach. I'm honestly fine with whatever solution comes out of this.
I think giving someone authority to decide "this is so trivial that it doesn't require approval" is a good thing. I would think that would be better handled by the Secretary, not the Chair. (Personally, I'd rather it was the Chair who had that power so I had less responsibilities
Great addition, thank you! I've added a few minor wording tweaks.
As a follow-up from our discussion on board-internal@haskell.foundation about the subject "Unified installer/tech track", we are capturing our emerging agreement on communication guidelines.
peer has failed to validate an assumption with you this most probably was a simple oversight without ill intent. In such a
Now we all make a lot of assumptions very naturally so that we can operate at all. Still, it's advisable to pause for a second,
This MR includes a mention of the private mailing list we recently established for more sensitive topics.
Hand over WoW Chair and clarify the process of doing so.
In the meantime some clean-up has been done as well, which is inconsequential from a decision-making point of view.