Community: Auditing meeting times and community calendar.

Created on 19 Mar 2019  路  14Comments  路  Source: kubernetes/community

One the key fundamentals to bringing new folks online into the kubernetes project is the general discoverability of when SIGs meet. Today this is supposed to be done via the community calendar. Upon recent switch to Daylight savings time, we discovered a number of oddities with the community calendar and found out it's in a sad state.

  1. A number of meetings did not exist there, including the community meeting
  2. Meeting invites looked correct but did not update properly during the daylight savings switch
  3. Contribex should have co-ownership of the meetings

This is table stakes for the community imo, and we should audit both the instructions and the meetings.

/cc @kubernetes/steering-committee @ncdc
xref - https://github.com/kubernetes/community/issues/3362
/assign @kubernetes/sig-contributor-experience-bugs

arecommunity-management help wanted kinbug prioritimportant-soon sicontributor-experience

Most helpful comment

im also in the middle of creating a calendar-guidelines.md and will replace the current calendar section of the sig-wg-lifecycle doc with that as a canonical source of truth. we can put best practices in here ,too.

All 14 comments

/cc @parispittman @castrojo @mrbobbytables

i found out yesterday that those who are setting gmail calendar invites are not realizing a few things that I'm going to PR into the sig-wg-lifecycle.md doc which is where the calendar instructions are.
1 - gmail has a default visibility setting - this should be set to public which it is not set on default
2 - most of the SIGs have shared calendars and most have them set to leads and sc1/2 has back ups - this means multiple people can change the calendar. this needs to be audited to find out which ones have this and which ones don't. i just don't think that folks understand that they can edit the calendar invites this way.
3 - calendars are disappearing when folks leave their employers and a transfer of the calendar wasn't successful. we need to add this to an off boarding list.

if contribex owns the calendars without doing it the shared calendar method, we would own it and wouldn't be able to have chairs have access which means we will need to reschedule/cancel/modify your meetings. if contribex partial owns the calendars, this means that all sigs and wgs need to create shared calendars from the instructions above and share with [email protected]. this is what half of the folks are currently doing and will raise up the other half. We'll need to recreate meetings in some cases.

im also in the middle of creating a calendar-guidelines.md and will replace the current calendar section of the sig-wg-lifecycle doc with that as a canonical source of truth. we can put best practices in here ,too.

there is the setting that I'll put into the guidelines
Screen Shot 2019-03-19 at 9 40 55 AM

note for later documentation: google.[email protected] was missing from the shared community calendar owners list

deescalating priority now that community meeting is back, but still relatively important.

/area community-management
/lifecycle active

/milestone May

@parispittman please verify if we can have it in this milestone :)

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

/remove-lifecycle stale

still needs to happen

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

this does need to happen still. happy to walk someone through how to do this.

/remove-lifecycle rotten

/unassign @parispittman
/assign @castrojo @mrbobbytables
We've been working on this 馃憤

Was this page helpful?
0 / 5 - 0 ratings