On Sep 9 2021, at 5:41 pm, Martin Owens doctormo@geek-2.com wrote:
- Martin Owens will contact active contributors with the design
and collect who wants one and their shape/sizes and shipping details.
This seems like a cool idea, I'm a little concerned with how we're gonna define "contributor" here. Do we have a set of criteria on who is in and out? No issue being generous, but we should have something other than "Martin likes them." đ
Well if we get item 2 sorted out, we'll have a ready made list of people to ask. đ But you are right that there's a lot of people who will have contributed in the past and not in 2021.
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