Thanks Ted,
This is a great first draft. (I hope it’s ok as a non PLC member to comment on this). A few remarks:
- Maybe you can relax the “report” point. For a team whose members are mostly from Australia or Japan, the PLC meeting would not be at a very reasonable time of day. Maybe an email to the board mailing list (like the dev team does at the moment)
would be sufficient, but attendance of the meeting is encouraged?
- A team should probably have a minimum number of members.
- A team should give itself a charter. The charter would be adopted by the PLC vote that endorses the team, and can be changed on the team’s request by a PLC vote. A barebones charter should be attached to the document. The charter should at
least detail the scope of the team and how decisions within the team are made, including how they choose the contact person. Since the charter is adopted by a PLC vote, the charter may already contain a task the PLC delegates to the group permanently (see
example below).
- I’m not convinced yet about how the second and fourth point of the “abilities” section are formulated. Does the second point mean “the PLC can give team x a budget of $y that they can spend in this fiscal year within the team’s scope, as they
see fit”? Not sure that’s a good idea. It could also just mean “the team’s requested budget is listed in the financial statement” which is something completely different. So this should be formulated more clearly. In any case we should work on a “spending
policy” for the project next, and reference that there.
- I’d prefer if the fourth point would contain “The PLC can formally delegate tasks to a team.” For example, delegate the task of speaking for the project to the Vectors team. Delegate the task of identifying issues for the Bug Accelerator Program
to the Testing team (which is an expenditure of the project’s resources). That would make it a bit safer to reference teams in PLC votes (as happened recently without having properly defined teams).
- How to build a team: Maybe add: “your team should not have conflicting or overlapping purpose with another team”. Also add: writing a charter (usually filling out the template)
- IMO we should not specify duties of a team without them being enforceable. What happens when a team does not fulfill its duties?
- Finally, I think “team” is not a good choice of words, mainly because we already have “teams” and not all of them will be able or willing to meet the duties specified, and we really shouldn’t have “teams” and “endorsed teams” at the same time.
Maybe “Working Group”? So an existing team can be promoted to be a working group (but can choose to keep the “team” denomination for brevity).
Again, thanks for your initiative!
Jonathan
Am 07.04.2023 um 19:40 schrieb Ted Gould <ted@gould.cx>:
Howdy,
We discussed at the hackfest that we wanted to have something to make official teams. But we wanted it to be light and mostly a simple process. In that vein I passed around some ideas to a few folks as they were leaving, but we didn't get much a chance
to discuss it. And I realized I hadn't posted to a wider audience. Eventually, I think we should vote on this (or something like it) as an official policy, but right now I'm trying to gather ideas. (unless everyone thinks it is perfect and we should JUST DO
IT)
I can't figure out how in Nextcloud to just enable comments? So I shared read-only and folks just reply here? Not sure the best way to discuss.
Ted
_______________________________________________
Inkscape Board of Directors mailing list -- inkscape-board@lists.inkscape.org
To unsubscribe send an email to inkscape-board-leave@lists.inkscape.org