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