On Tue, Jun 10, 2025 at 12:58:10PM +0200, Simon Chopin wrote: > For the sake of clarity: appointments should still have clearly defined > durations and existing members should explicitly reapply.
+1 > A common risk in FOSS communities is one of volunteers burning out. > Having periodic checkpoints where one must explicitly assess whether > they still have the time and energy to serve is fairly healthy. +1 On Wed, Jun 11, 2025 at 12:16:34PM +0530, Utkarsh Gupta wrote: > So something like a 2-year term a volunteer commits to. Perfectly fine > (not ideal) to step down at any point in time. And should ask TB to > run again when their membership is about to expire (like T-30 days or > something). To save on admin, would you consider it sufficient to use Launchpad's team membership expiry feature? We could set the term to two years in Launchpad, and allow members to self-renew with the usual explicit affirming action. If a member doesn't want to make a further two year commitment, they could then allow their Launchpad team membership to lapse with no further action. It'd be nice to communicate with the DMB and TB at the time, of course, but we don't have to make that a requirement. I'd be happy to document what the TB and DMB take the team membership term, expiry and self-renewal to *mean* in a policy document - that would be a straightforward, bounded and one-off task. This would save a bunch of chasing round, especially at asynchronous times as terms lose alignment. Otherwise, we'd be creating an asynchronous administrative task for the TB, which the TB has never had a good process to handle, and in practice I think will just lapse all the time. Robie
signature.asc
Description: PGP signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
