Heh, yes, I think these are on different time scales 😉

@Chris @Ryan, tentative rule - Have been active for more than a month

doing one of the jobs of programming, ux/design, outreach, testing,

moderation, docs or translations in 2021. That would include our

outreachy student, GSoC students. Let me know if this sounds like the

right collection of people.

How we collect those names also matters. For instance, probably Ryan should prepare a list of folks who've helped out with Vectors. That way we get the people who folks like you or I wouldn't notice as much.

> Curious what the "invite" step is. It seems like we've got a web form

> below, why have a special role for "inviter" versus just a third

> peer?

In effect the only difference is the inviter would be the first peer

and the user would be notified. They'd have to select the user from the

database (email, username etc) so there's a slight bit more work.

Hmm, okay. I see that from the technical side. I wonder if it needs to be in the charter. If the charter could just say peers and then from a technical perspective you'd need an account to use the initial form. It might keep the charter simpler.

> > * One-time approval, can not be revoked.

>

> This seems to be suggesting no "retirement" provision, which seems

> odd to me. For instance, if I left the project today and wasn't

> involved at all, it seems odd that I'd have a say who is in the PLC

> in say five years. Or for instance if the project loses the ability

> to contact me it seems I should be taken off the list somehow just to

> remove cruft for the organization. While the PLC could technically

> vote to remove folks, I guess I'd rather have that for egregious

> cases like code of conduct violations and the such.

We deferred non-urgent removal for a next step to slim down this

proposal. I suggested peer-removal in the meeting, but the consensus

was that it and revocation would cause issues with people using it as

leverage against fellow team members. Maybe something for the CoC if we

decide on revocation.

Makes sense to defer, I don't think that's the most important part to get right first. We just need to make sure to not say that it can't be revoked, as it can. I imagine as steps after voting we could do a PLC vote to remove the folks we can't get a hold of or have email addresses for. We wouldn't want to do that for everything, but for boot strapping that is probably easier.

> I think it was Marc's idea last time we discussed this that the PLC

> should have a final vote on adding someone. And I think that's a good

> idea. Just a rubber stamp type thing (perhaps even posted to the PLC

> list but approved with no objection after a seven days?). This way we

> can catch people who perhaps were banned, but somehow come back or

> otherwise try something similar ("Oh, your peers are both people who

> didn't really work on that area of the project, that's odd, let me

> ask around")

A second order vote is somewhat against the idea of having it open.

Although I understand the need to check to make sure nothing's going

weird. Notification of new members to the mailing list once a week

could perform this step too, no need to vote or activate people, just

make sure we have visibility. Chris actually thought this would be good

so we could celebrate new members too.

Not sure what you mean by "having it open" -- I don't see this as an open process, it is only for people who've shown they're interested in contributing.

Perhaps another solution would be to have a member of the PLC elected to be "Application Verifier Person" who'd either approve or bring it to the PLC. Don't give them the power to reject, just to request a vote. That way we have a someone looking at it, but only bump up weird cases.

> > d. Add git repository backend to push logs to gitlab for

> > verification.

>

> Requirement that I'd add is that we could update the Git repo and

> have that reflected on the website. Not just a one-way data flow. Not

> sure that's implied, but just making sure.

The logs in this case would be records of action, if you add your own

logs, I'm not sure what the website could do with it. Reverse engineer

the actions and add people to the database? What if you add a username

that doesn't exist? or format it in a way that's broken json. The

website is able to hold data on a user that we wouldn't want made

public, and it allows users some control, to remove themselves for

example.

If you want a git API to peer-approval, inviting, etc. It sounds

exotically eccentric 😉 but it could be done, although I wouldn't have

it be the same thing as the log. Which should be something we can use

to vet that nothing has gone wrong with the database, and non one is

modifying things retrospectively.

Is what you want a command line tool? A REST API?

I guess I figured the Git repo would be a bunch of files, perhaps JSON, that would be the canonical source of the list of members. If for some reason there was an error, the error would need to be fixed there. (and logged, etc.) Then we'd need a way to "reimport" from the backup in that case. I don't think it needs to be the "normal" flow, but I do think for the Git repo to be effective it needs to be considered the core source of the data.

Ted