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