Minutes for PLC Meeting September 2021
Inkscape Leadership Committee Meeting (9th September 2021)
Thanks everyone for comming to this month's meeting, you can find the video recording here:
https://digimedia1.r2.enst.fr/playback/presentation/2.3/80b082be7c60e7a1fd9b...
Next meeting: https://inkscape.org/cals/event/30/ October 14th 2021
Below are the notes and tasks that we have decided or are deliberating. To keep things organised, if you'd like to reply to this message, please remove the item that you're not talking about from the reply text and change the subject line.
Item 1: Contributor Tshirt [00:01:30] -------------------------------------
Notes:
* These are shirts offered to all 2021 contributors * They will NOT be made for sale in spreadshirt or anywhere else * The design will focus on 2021 and not the release (1.1 or 1.2)
Tasks / Planning:
1. Chris Rogers will design the shirts [current task] 2. Martin Owens will contact active contributors with the design and collect who wants one and their shape/sizes and shipping details. 3. Ryan Gorley will take the counts and basic shipping information (countries) and make a cost estimate. 4. Martin Owens will bring the price estimate back to the leadership committee for a vote. 5. If successfully funded, Ryan will submit the orders to the supplier who will ship directly to contributors.
Item 2: Mechanisms for Membership [00:18:02] --------------------------------------------
Policy discussion:
* Peer Aproval, major consensus for this over multiple meetings. * Number of peers required, 3, 1 inviter and 2 other peers to aprove. * Invite only, apply via asking in chat/mailing list * No limits on number of people we can approve. * One-time approval, can not be revoked. * Cascade protection: Grace period before peer approval of 3 months * No grace period for any other privilages. * Removal via the PLC; Majority vote.
Technical Implmentation/Tasks
1. Martin Owens will submit this discusson to the leadership committee for sanity checking [current task] 2. After two weeks for discussion, baring any major problems the website will be modified in the following ways: a. Add Invitation-Peer Aproval model to teams b. Add optional grace period field for peer-aproval calculation c. Add file based logging of all activity, (add, removal, anything) d. Add git repository backend to push logs to gitlab for verification. 3. The website functionality will be deployed to test.inkscape.org for review to make sure it's correct. 4. The functionality and policy package will be brought before the PLC for a vote to adopt the system and policies (maybe two seperate votes) 5. If approved, The system will be deployed to inkscape.org and gitlab.com and membership will be open to peers.
Thanks to everyone who's taken part in this discussion. It's been a long one, but I'm excited to move this forwards and get our membership model fighting fit.
Best Regards, Martin Owens Inkscape Leadership Committee
Thanks for the notes, much easier to read and comment on text than to watch videos.
On Sep 9 2021, at 1:48 pm, Martin Owens doctormo@geek-2.com wrote:
Item 1: Contributor Tshirt [00:01:30]
<snip>
- 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." đ 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?
- Number of peers required, 3, 1 inviter and 2 other peers to aprove.
- Invite only, apply via asking in chat/mailing list
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?
- 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.
- Cascade protection: Grace period before peer approval of 3 months
- No grace period for any other privilages.
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.
- Removal via the PLC; Majority vote.
Fine either way. But I'd suggest even 2/3. Make a it a BIG DEAL to remove someone. 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")
- 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.
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.
Best Regards, Martin Owens Inkscape Leadership Committee
You're not the entire committee đ Ted
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
Regarding this:
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
I'd like to see more help from PLC members to plan and attend the PLC meetings. Not only is it a good time to discuss issues in real time with the group, since they are recorded, the more PLC members who are there, make it look less like Martin is shouldering all the work of the PLC.
-C
_______________________________________________
Inkscape Board of Directors mailing list -- inkscape-board@lists.inkscape.org To unsubscribe send an email to inkscape-board-leave@lists.inkscape.org
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
On Fri, 2021-09-10 at 16:39 -0500, Ted Gould wrote:
Heh, yes, I think these are on different time scales đ
The hope is that they're not that out of scale. we shouldn't have items hanging around meeting after meeting for example, tasks should be underway by then. Which is why I've framed the meetings around tasks and not endless discussion.
It's reasonable to have this discussion period for two weeks I think, but then I'll need to redraft it into something we can actually start the technical details rolling.
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.
Our team charter is the FSA and a brief bullet point of the items in it: https://inkscape.org/*leadership-committee/charter/ I wasn't expecting this would be charted out in the FSA but we can pull together the final draft and add it as it's own document if you like. I don't think this policy needs to involve the SFC as it's just internal details (not to say we shouldn't give them a look at it for sanity sake)
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.
Well the inkscape project has always been pretty flat, leadership wise. And your suggestion is more along the lines of top-down control. Which we've never had for the authors list for example.
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.
I'd be happy to have a person who's job it was to review them. Although I'd still like it on principle if people are peer approved. The only effective difference is that they'd be in the system after peer approval and removed by plc on review. So I'm advocating here for "peer-approved-plc-review" as apposed to "peer-and-plc-approved".
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.
Backups are reasonable, improving that would be good in any case. We can probably store the relationships (dates, peers, etc) and basic identifiable information (such as usernames, first/last names) but not emails, addresses, personal information etc. So data loss would allow us to removed some, but not all from the public record. A full and complete backup would recover private information too.
I guess the difference is that as a "recoverable log" we'd be entering a manual process to restore them. As apposed to a canonical data store, which would be expected to honour changes pushed into it.
Best Regards, Martin Owens
On Sep 10 2021, at 5:34 pm, Martin Owens doctormo@geek-2.com wrote:
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.
Our team charter is the FSA and a brief bullet point of the items in it: https://inkscape.org/*leadership-committee/charter/ I wasn't expecting this would be charted out in the FSA but we can pull together the final draft and add it as it's own document if you like. I don't think this policy needs to involve the SFC as it's just internal details (not to say we shouldn't give them a look at it for sanity sake)
I don't think that's a "team charter", it's just a description. By charter I mean FSA with the SFC. And I'm not sure if we're disagreeing (the threads has moved through a few things) but I do thing the base requirements and characterization of who can vote should be in the FSA, but we don't need to have the "press here, do this" part there. We've kept policies like that
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.
Well the inkscape project has always been pretty flat, leadership wise. And your suggestion is more along the lines of top-down control. Which we've never had for the authors list for example.
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.
I'd be happy to have a person who's job it was to review them. Although I'd still like it on principle if people are peer approved. The only effective difference is that they'd be in the system after peer approval and removed by plc on review. So I'm advocating here for "peer-approved-plc-review" as apposed to "peer-and-plc-approved".
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.
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.
Backups are reasonable, improving that would be good in any case. We can probably store the relationships (dates, peers, etc) and basic identifiable information (such as usernames, first/last names) but not emails, addresses, personal information etc. So data loss would allow us to removed some, but not all from the public record. A full and complete backup would recover private information too. I guess the difference is that as a "recoverable log" we'd be entering a manual process to restore them. As apposed to a canonical data store, which would be expected to honour changes pushed into it.
I'm for it being the canonical data store. But fine if performance-wise there's a DB that's used most of the time. I think it would be fine if there is an issue if we shut it down for a day type of thing. Besides the initial rush I don't think it'll be used more than a few times a year (hope for more, but realistically). Also, I don't think it has to be a public Git repo, I think as long as all the members of the PLC can see and review it that's good enough. I really (really really) doubt there'll be a need to review it but with membership and voting want to ensure everything is triple checked and double verified. Ted
On Sun, 2021-09-12 at 13:49 -0500, Ted Gould wrote:
On Sep 10 2021, at 5:34 pm, Martin Owens doctormo@geek-2.com wrote:
I don't think that's a "team charter", it's just a description. By charter I mean FSA with the SFC. And I'm not sure if we're disagreeing (the threads has moved through a few things) but I do thing the base requirements and characterization of who can vote should be in the FSA, but we don't need to have the "press here, do this" part there. We've kept policies like that
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. 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).
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.
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'm for it being the canonical data store. But fine if performance-
wise there's a DB that's used most of the time. I think it would be fine if there is an issue if we shut it down for a day type of thing. Besides the initial rush I don't think it'll be used more than a few times a year (hope for more, but realistically). Also, I don't think it has to be a public Git repo, I think as long as all the members of the PLC can see and review it that's good enough. I really (really really) doubt there'll be a need to review it but with membership and voting want to ensure everything is triple checked and double verified.
It absolutely shouldn't be private. No more private repositories, they are disjointed and have done little but cause burden to us.
The degree to which verification is being requested here is way more than the degree of risk. A lot of this is unnecessary.
If you're concerned about what the policy says is the canonical source of data (I presume for if there's a dispute) we can state that. Where there is a dispute between the database, the git log, the git log should be taken as the primary source of membership (not the primary source of contact information though) and the website database corrected as needed to match it.
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
participants (3)
-
C R -
Martin Owens -
Ted Gould