Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: loosen TC activity rules #5510

Merged
merged 1 commit into from Mar 14, 2024
Merged

docs: loosen TC activity rules #5510

merged 1 commit into from Mar 14, 2024

Conversation

wesleytodd
Copy link
Member

As mentioned in expressjs/discussions#195 (comment), maybe we should start much more loose than this wording. We don't want to use this to push folks out, the goal is more active participants. This was mainly to protect against the previous issues with inactivity causing stagnation, but I think maybe we started a bit too strong.

@jonchurch
Copy link
Member

jonchurch commented Feb 28, 2024

I am still partial to clearly lining out the hours of meetings a Tc member can expect to be committing to. (In terms of, how many TC meetings/month, how many are considered necessary to attend if N > 1)

Loosening the expectations does not achieve stating a known level of meetings someone must make room for in their life to fulfill the commitment they are making to Express. With the current rekindling of effort and getting the band back together, maybe the level of commitment expected isn't known at this time. That is fine.

I see two issues at hand, the new one I brought up just now about known commitment, and that the way the inactivity section is written rn makes it difficult to up the cadence as is being suggested in expressjs/discussions#195 (comment).

As a stopgap to the latter issue, this change is acceptable to me. But churn on these items means we have work to do to iron some things out.

@jonchurch
Copy link
Member

jonchurch commented Feb 28, 2024

The reality of timezones makes a hard attendance number challenging. So not for now, but maybe we can define a clear way to "officially attend" a meeting async such as submitting your comments ahead of time based on the proposed agenda. With a 24 hr period after any vote occurred to allow a timezone opposite member to watch the recording and register their vote.

@jonchurch jonchurch requested a review from a team February 28, 2024 21:12
@@ -118,8 +118,8 @@ nominate someone to take their place.
TC members will be added as admin's on the Github orgs, npm orgs, and other resources as
necessary to be effective in the role.

To remain "active" a TC member should have participation within the last 6 months and miss
no more than three consecutive TC meetings. Members who do not meet this are expected to step down.
To remain "active" a TC member should have participation within the last 12 months and miss
Copy link
Member

@jonchurch jonchurch Feb 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can hold off for now, with a fast follow in Season 0 to firm this up.

The penalty for inactivity requires a PR to be opened to remove someone who has not met the attendance criteria, and does not choose to resign. (it is also not spelled out WHO can open or approve that PR hehe)

I am confident that the current TC will not inactive someone if they miss the next couple meetings.

Churn in these policies need to be avoided lest we hinder their gravity. Let's make sure that the next change we make to this clause is one that balances our goals here of encouraging activity/showing up, and accomodating people's lives as this is a volunteer position. As well as choosing language we won't have to touch again for a long time unless something drastic changes.

Copy link
Member

@jonchurch jonchurch Feb 28, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A first stab from me:

"To promote active participation, TC members must attend a minimum of 75% of official monthly meetings annually. To account for time zone challenges, members may 'officially attend' by submitting detailed comments on the meeting agenda at least 12 hours before the meeting. This will count as attendance for maintaining active status.

Ad hoc working sessions are vital for progress but are not mandatory and do not count towards the monthly meeting attendance requirement. Official decisions requiring consensus or vote are reserved for monthly meetings, except under urgent circumstances, where a predefined exception process will be followed."

The bolded part here is something that we can omit, but should definitely be broached and put into writing. Im guessing we could strike that rule, and would have to depending on how "official decisions" are defined. Is merging a PR an official decision? No. Accepting a new TC member? Yes. Emptying the (nonexistent) bank account? Yes. Merging a PR to drop Node version support outside of agreed to timelines? Yes

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I like this more detailed version!

@jonchurch
Copy link
Member

jonchurch commented Feb 28, 2024

btw I pinged Jory and Robin at OpenJSF to see if they can give guidance on attendance policy based on other projects

Edit: heard back, Robin pointed to Nativescript's Governance doc, and said that Nativescript and many other projects have used the Node.js docs as their starting place.

Here is the Nativescript doc's relevant section:

A TSC member may be removed from the TSC by voluntary resignation, by a standard TSC motion, or by attending less than 3 TSC meetings annually. In all cases, the TSC member will revert to Reviewer status unless they prefer Alumni status.

and just after that they define a cadence for official meetings, which is the attendance they are counting:

The TSC meets every month via Zoom on Thursday at 1 pm PDT. The meeting is run by a designated moderator approved by the TSC. TSC members are not required to attend every single TSC Meeting, only that they attend at least 8 a year to maintain status.

@sheplu
Copy link
Member

sheplu commented Feb 29, 2024

For me 12 months is way to much. I prefer to codify that the meetings need to be called out at least a week in advance (if we have recurring meeting this can be done easily) but participation should be expected.

With the current wording, if we do one meeting a week, it is 1.5 months of no-show, if we are doing 1 meeting per week it is 3 months or a quarter of a year.
I guess for now we will start with a weekly meeting to have all the things started, and then move to one every two weeks.

But i would be in favour of adding "if a TC member cannot attend for personal / health causes, and notify a TC member, then we do not apply the rule for X months" and "if a TC member was removed previously but wasn't able to attend for personal / health causes, then this person can be reinstated as his/her request"

That way, we can keep an active TC but still taking into account the things of life

@wesleytodd
Copy link
Member Author

But i would be in favour of adding "if a TC member cannot attend for personal / health causes, and notify a TC member, then we do not apply the rule for X months" and "if a TC member was removed previously but wasn't able to attend for personal / health causes, then this person can be reinstated as his/her request"

This is also a great addition!! We should for sure add wording like this.

@jonchurch
Copy link
Member

jonchurch commented Feb 29, 2024

Im not partial to the wording around exceptions. If someone is inactive they are inactive. The major events and incidentals of life are covered by the fraction in "expected to attend X% of meetings" part of this kind of policy. The elephant in the room is deciding how many TC meetings there are a month, and if all of those are required.

Being inactive shouldn't be a big deal if it's not a death sentence for your chair on the TC.

I've seen language in some project (but cannot recall now where) about inactive members being able to be reinstated with preference over others when there is a vacancy and the inactive member is ready to return to a welcoming group.

We could make it easier for folks to contribute meaningfully to the TC while being unable to be present for meetings, with the understanding that such an avenue is an affordance for folks if/when it is the only way they'd be able to contribute to a given meeting. (due to timezone, life events, poor internet connection, etc etc)

If people are going to ghost bc of whatever is happening in their lives, they will regardless (boy do I know). Let's not punish them further for their conduct on the way out in vulnerable moments. Meaning, let's not mandate that you must give a heads up lest you get a strike. You're either available to participate in a meeting or you aren't.

the vibe of record for volunteer work should be: Show up if you are enthusiastic to, don't if you can't be for whatever reason. Please let us know if we can expect to miss you, not because it is mandated in the bylaws. But because it is polite and you respect your colleagues' time.

@wesleytodd
Copy link
Member Author

Hm, so I think the goal of this clause is to prevent blocking decisions on not being able to make quorum. So while I don't disagree with anything you said, I think there is still value in making crystal clear some level of expectations. If we decide "inactive" means something different than what someone expected that is a problem.

Maybe we can add the agenda label to this and discuss on one of the upcoming meetings?

@joeyguerra
Copy link

Multiple perspectives on this is a good idea.

I'm trying to understand this topic better. If we were writing code, what would be some of the test cases or scenarios and expected assertions? i.e. given we have a decision, when we don't have quorum, then ??? (e.g. we schedule a meeting 2 weeks from now and if still no quorum, we make the decision without quorum)

Copy link
Member

@crandmck crandmck left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with these changes: max missing 6 meetings in a row and active in last 12 mo.

@wesleytodd
Copy link
Member Author

wesleytodd commented Mar 5, 2024

After yesterdays discussion on it, I was thinking maybe we can say this :

Our goal is to increase participation, not punish people for any lack of participation, and that this guideline should be only be used as such (replace an inactive member with a new active one, for example).

@wesleytodd
Copy link
Member Author

Ok, I updated it to include that new wording. I will leave this open for another day or so to make sure any folks who previously approved are ok with the new addition.

@UlisesGascon
Copy link
Member

Seems like this is currently consolidated and we have a good consensus, so I will merge it

github-actions bot pushed a commit to brafdlog/caspion that referenced this pull request Apr 2, 2024
# [1.26.0](v1.25.2...v1.26.0) (2024-04-02)

### Upgrade

* Bump express from 4.18.2 to 4.19.2 (#552) ([bd280ba](bd280ba)), closes [#552](#552) [expressjs/express#5552](expressjs/express#5552) [expressjs/express#5556](expressjs/express#5556) [expressjs/express#5527](expressjs/express#5527) [expressjs/express#5511](expressjs/express#5511) [expressjs/express#5510](expressjs/express#5510) [expressjs/express#5541](expressjs/express#5541) [expressjs/express#5551](expressjs/express#5551) [expressjs/express#5541](expressjs/express#5541) [expressjs/express#5032](expressjs/express#5032) [expressjs/express#5034](expressjs/express#5034) [expressjs/express#5027](expressjs/express#5027) [expressjs/express#5124](expressjs/express#5124) [expressjs/express#5119](expressjs/express#5119) [expressjs/express#5117](expressjs/express#5117) [expressjs/express#5113](expressjs/express#5113) [expressjs/express#5130](expressjs/express#5130) [expressjs/express#5131](expressjs/express#5131) [expressjs/express#5028](expressjs/express#5028) [expressjs/express#5137](expressjs/express#5137) [#5541](https://github.com/brafdlog/caspion/issues/5541)
* Bump express from 4.19.2 in /ui-react (#551) ([8d6032d](8d6032d)), closes [#551](#551) [expressjs/express#5552](expressjs/express#5552) [expressjs/express#5556](expressjs/express#5556) [expressjs/express#5527](expressjs/express#5527) [expressjs/express#5511](expressjs/express#5511) [expressjs/express#5510](expressjs/express#5510) [expressjs/express#5541](expressjs/express#5541) [expressjs/express#5551](expressjs/express#5551) [expressjs/express#5541](expressjs/express#5541) [expressjs/express#5032](expressjs/express#5032) [expressjs/express#5034](expressjs/express#5034) [expressjs/express#5027](expressjs/express#5027) [expressjs/express#5124](expressjs/express#5124) [expressjs/express#5119](expressjs/express#5119) [expressjs/express#5117](expressjs/express#5117) [expressjs/express#5113](expressjs/express#5113) [expressjs/express#5130](expressjs/express#5130) [expressjs/express#5131](expressjs/express#5131) [expressjs/express#5028](expressjs/express#5028) [expressjs/express#5137](expressjs/express#5137) [#5541](https://github.com/brafdlog/caspion/issues/5541)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants