Thanks for the review ted.
- 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.
@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.
Also, do we have and GDPR/data regs issues with collecting addresses? I'm guessing if we just destroy the data after sending them we're fine?
Destroying data and keeping it offline is a good idea.
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.
- 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.
I guess this aligns with some confusion on why we want two stages. But it seems like if two peers are willing to sign off that you've contributed significantly for at least three months already, not sure why there needs to be another three months.
It only applies to adding more members to the list, not to anything else. And it looks like this is an alternative to the PLC vetting (although different). If the PLC is rubber stamping members then this isn't needed.
Fine either way. But I'd suggest even 2/3. Make a it a BIG DEAL to remove someone.
That's fair. It should be reserved for actual violations, not just house cleaning.
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.
- After two weeks for discussion, baring any major problems the
website will be modified in the following ways:
To be clear, as I think it is implied below, but I'm not sure: "the website" here is the test website, right? I'd not want to modify the full website until the text of the charter is approved at least. I'd be for policies too.
By website, it means the website project, i.e. the code. Not the live system.
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?
Best Regards, Martin Owens Inkscape Leadership Committee
You're not the entire committee 😉
Thank god, there's way too much work for one person.
Best Regards, Martin Owens