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
