Skip to content

Conversation

@brendt
Copy link
Member

@brendt brendt commented Jan 26, 2026

Still WIP and up for discussion

@brendt brendt requested a review from innocenzi as a code owner January 26, 2026 09:46
@brendt brendt marked this pull request as draft January 26, 2026 09:46
@brendt
Copy link
Member Author

brendt commented Jan 27, 2026

Slept on it for another night:

  • I think the 90 days inactive should be 180 days; at least for as long as Tempest is a hobby project
  • I think the same time limit should also be set for both Council Members and and Core Contributors
  • We need to define what it means to be "inactive". It shouldn't be just code contributions, but then what?

@innocenzi
Copy link
Member

innocenzi commented Jan 27, 2026

We need to define what it means to be "inactive". It shouldn't be just code contributions, but then what?

Tough to properly define it. I'd say "activity" should be:

  • committing code
  • opening/reviewing/commenting on PRs
  • opening issues/commenting/triaging
  • sending messages in Discord

With those criteria, it would effectively be pretty hard to be "inactive"

@iamdadmin
Copy link
Contributor

We need to define what it means to be "inactive". It shouldn't be just code contributions, but then what?

Tough to properly define it. I'd say "activity" should be:

* committing code

* opening/reviewing/commenting on PRs

* opening issues/commenting/triaging

* sending messages in Discord

With those criteria, it would effectively be pretty hard to be "inactive"

It may be hard to have a single criteria; you might have a team member whose sole commitment is to triaging and progressing issues and doing code reviews. They'd not need to submit their own code in thise role. So people could be asked to commit to a level of activity based on what they are bringing to the project, and then moderately hold them to it, for 'inactivity' to then be considered on a case-by-case-basis. If there are multiple people covering the duties, then it could be a 60 or 90 days "no activity on the repo" with a removal of access, with a swift path for them to return.

I think it's important to define something, for the times you NEED to invoke it, even if overall you don't invoke it often.

@aidan-casey
Copy link
Member

@brendt - a few things...

First, the easy one. Inactivity is the failure to perform any of their responsibilities defined under the roles section. My assumption, though I feel it necessary to leave provision for other scenarios, is that most of the time this will be without any communication to us as well - total disappearance.

Second, I pretty strongly disagree with your 180 days comments. On a few fronts:

Part of the BDFL's responsibilities include signing off on releases and setting the vision for the next release cycle. Remember, the governance document is intended to ensure a healthy project. Are you really comfortable with that not happening for half a year? I'm not. I think it'd kill Tempest and is very unhealthy.

The intention, also, is that the BDFL could come back within 180 days and resume their duties. Beyond that (181 days) the officer is permanently made BDFL.

Regarding community members roles, my intention was that they may be removed after 90 days. It's not an automatic removal, but suggested and ratified by the council.

This feels fair, because we don't want to introduce a situation where a member is inactive for 179 days, makes a contribution, and then goes inactive for 179 days again. That's not consistent with the privilege of this role.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants