On Sun, 2021-09-12 at 13:49 -0500, Ted Gould wrote:
On Sep 10 2021, at 5:34 pm, Martin Owens doctormo@geek-2.com wrote:
I don't think that's a "team charter", it's just a description. By charter I mean FSA with the SFC. And I'm not sure if we're disagreeing (the threads has moved through a few things) but I do thing the base requirements and characterization of who can vote should be in the FSA, but we don't need to have the "press here, do this" part there. We've kept policies like that
That runs counter to the advice we were given from the SFC about what is expected to be in the FSA. If you're unsure, we should go back to the SFC and ask them explicitly if membership policy needs to be in the FSA or if it can be internal policy. This is also counter to the existing FSA which trusts us to populate the AUTHORS file and makes no mention of any mechanism (not the two patch rule for example).
I think what's hard for us is that we've not really done *policy* before as a team. (or written it down well) We're growing, and I'd expect us to accrue a bunch of policy documents which detail everything from our existing code of conduct to future policy on funding. We can start that with this document.
Just semantics, but I was thinking "peer-approved-plc-verified" So
written as the PLC has the obligation to verify the peers and approve if they're valid, but can escalate if things are weird.
Semantics that impact the mechanism are not just semantics. This is important for the code to understand if it should add people to the list prior to plc review or not. I'm very unhappy about the plc being arbiter of who is and is not in the membership list as it creates a conflict of interest. Adding members THEN having that list reviewed (not approved) is distinct and important.
I'm for it being the canonical data store. But fine if performance-
wise there's a DB that's used most of the time. I think it would be fine if there is an issue if we shut it down for a day type of thing. Besides the initial rush I don't think it'll be used more than a few times a year (hope for more, but realistically). Also, I don't think it has to be a public Git repo, I think as long as all the members of the PLC can see and review it that's good enough. I really (really really) doubt there'll be a need to review it but with membership and voting want to ensure everything is triple checked and double verified.
It absolutely shouldn't be private. No more private repositories, they are disjointed and have done little but cause burden to us.
The degree to which verification is being requested here is way more than the degree of risk. A lot of this is unnecessary.
If you're concerned about what the policy says is the canonical source of data (I presume for if there's a dispute) we can state that. Where there is a dispute between the database, the git log, the git log should be taken as the primary source of membership (not the primary source of contact information though) and the website database corrected as needed to match it.