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:
> > > 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