document EasyBuild governance#374
Conversation
…tructure for governance section of docs
…ady very out-of-date, and is kind of useless without more information
Typo fixes
| - The number of Members working for the same employer should be limited to 1 | ||
| (to avoid that the project becomes dominated by a single company or institution, or a small group thereof); | ||
| - The number of Members with the same country of residence should be limited to 2 | ||
| (to reflect the international nature of the project); |
There was a problem hiding this comment.
| (to reflect the international nature of the project); | |
| (to reflect the international nature of the project); |
| gave prior notice to the Steering Committee about being incommunicado for an extended period of time. | ||
|
|
||
|
|
||
| #### 6.2.2 New Members |
There was a problem hiding this comment.
In many cases, a new member replaces an old one. We currently don't have this explicit, but I would feel it inappropriate if the person leaving votes on their successor. This increases the risk of people or organizations retaining 'power'. It's like trying to rule beyond your grave.
Of course, you may have situations where you just have 'new members', e.g. if you want to grow the steering committee. I'm not sure how we should write it up in a way that is air-tight. But maybe that's not so important, maybe we should just write down the intend, i.e. something like:
- If a new member is a replacement for member that is leaving, the member that leaves cannot vote on the acceptance of the new member.
This makes the intend clear I suppose. Then it's up to the Steering Committee to decide whether this applies - I bet it's obivous in 98% of cases.
There was a problem hiding this comment.
I think that makes sense regarding a member leaving not to vote on the new member.
However, would that also exclude suggesting a new member? After all, the suggested member might provide some continuity which we might want to have, or appreciate. Equally, the suggested new member might not be what the rest of the team has in mind.
| All complaints will be reviewed and investigated promptly and fairly. | ||
|
|
||
| The EasyBuild Steering Committee Members are obligated to respect the privacy and | ||
| security of the reporter of any incident. |
There was a problem hiding this comment.
Is it possible/useful to be a bit more explicit here about the privacy of the reporter.. by adding something like "No information that could identify the reporter, or details of the report, will be communicated outside the Steering Committee without the reporter’s explicit consent, except where disclosure is required by law or necessary to address an immediate risk of harm."
There was a problem hiding this comment.
I agree, something like: 'these reports will be treated with strict confidentiality within the law', might be useful.
The problem with 'the law' could be as different countries have different law.
As EasyBuild originates in Belgium, maybe we explicitly should put down Belgium, or European Law?
| - A member may be voted out. In this case, the vote needs to be unanimous between the other members. | ||
| This procedure is intended to provide a mechanism for addressing extraordinary circumstances where | ||
| a member's behavior or actions are deemed severely detrimental to the committee's function or | ||
| reputation, and/or to the EasyBuild project. |
There was a problem hiding this comment.
Maybe this is thinking too far, but should we make this a bit clearer for cases where more than one Steering Committee member is involved? Right now, the text seems to cover the case where one member is "causing problems", but it is not obvious what happens if two or more members are involved in the same issue. In that situation, they might still be able to vote on each other’s removal, which feels like a conflict of interest.
We could add something like? :
If multiple Steering Committee members are involved in the same incident or pattern of conduct, they must be considered separately where possible, and any directly conflicted member must abstain from voting on the removal of another member.
|
|
||
| **Consequence**: A permanent ban from any sort of public interaction within the | ||
| community. | ||
|
|
There was a problem hiding this comment.
How can we enforce such a ban?
If somebody wants to say use a PR for the ongoing inappropriate behaviour, what can we do here? Or LinkedIn?
LinkedIn might be easy, we just ignore that and don't reply directly. With a PR I would not know how to deal with this. See the example where an AI started off a war of words with the maintainer of a program recently.
There was a problem hiding this comment.
We can only enforce such a ban the best we can. PRs can be closed, users can be blocked from submitting new PRs in github project settings. Of course they could create a new account and use that, but then it would be an untrusted user, and if found out make it even worse.
Let's hope we never get there, it's hard to imagine with the current community doing this in conjunction with their day jobs (as it would look very bad to their employer too), but we need to cover the worst case scenario.
7 participants
This is a draft PR as this documented governance is an initial draft.
Feedback from the entire EasyBuild community is welcome.
The Initial Steering Committee (@SebastianAchilles, @branfosj, @boegel, @verdurin, @smoors, @casparvl) will take the feedback into account to finalize and publish these governance documents in the coming weeks/months.