On Sep 12 2021, at 8:52 pm, Martin Owens doctormo@geek-2.com wrote:
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.
I'm unfamiliar with the advice from the SFC. Do you have a link or reference to that so I can get caught up? I'm not saying all policy should be in the FSA, but we should have the definitions of what a contributor is and what can lead to removal. Since it creates the basis for voting for PLC members among other things it needs definition in the FSA.
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).
Sure, one of the reasons the AUTHORS file was chosen is that it's behavior is well specified by the GNU project. And at the time any reasonable OSS project followed their layout standards (things have changed). In retrospect it should have at least referenced that policy.
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.
While I guess you could say that the entire PLC hasn't, half has done policy. For instance, here's our election procedure: https://alpha.inkscape.org/board/referendums/resolutions/election_procedure.... It should be a bit easier to grep than that, but that is being tracked on this issue: https://gitlab.com/inkscape-board/documents/-/issues/1 Would be great to see more work on it.
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 think we're mostly agreeing here? Certainly we'll need to be careful with the wording, but I see PLC as the verifier of the process being followed more than an approver of individual contributions or status.
It absolutely shouldn't be private. No more private repositories, they are disjointed and have done little but cause burden to us.
Saying it is okay for the website database to be private, but a "burden" to have other databases private, is a bit disingenuous. It makes you sound like: "it is okay for me, but not for you." I don't think one is distinctly better than the other. I think that the authoritative database should have at least email addresses in it. Ted