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