| title | weight | description |
|---|---|---|
Monthly Community Meeting |
1 |
The Gorgonia community meeting is intended to provide a holistic overview of
community activities, critical release information, and governance updates. It
also provides a forum for discussion of project-level concerns that might need
a wider audience than a single special interest group (Working Group).
|
We have a PUBLIC and RECORDED monthly meeting the first Friday of the month at 9am London, 9am Tokyo or 9am San Francisco.
See it on the web at [calendar.google.com], or paste this [iCal url] into any [iCal client]. Do NOT copy the meetings over to your personal calendar, you will miss meeting updates. Instead use your client's calendaring feature to say you are attending the meeting so that any changes made to meetings will be reflected on your personal calendar.
Quick links:
The Gorgonia community meeting is intended to provide a holistic overview of community activities, critical release information, and governance updates. It also provides a forum for discussion of project-level concerns that might need a wider audience than a single contributor or working group.
Notes from the meeting are published to [this forum thread] for wider distribution. A good notetaker is important to help get the information out to people who cannot attend. Volunteers are always welcome to either add their notes directly to the document, or inform the host that they would like to help take notes at the beginning of the call.
If you have a topic you'd like to present or would like to see discussed, please propose a specific date on the [Gorgonia Community Meeting Agenda][agenda].
General speaking the meeting is structured as follows:
- Introduction by Host (~3 minutes)
- Community Demo (~10 minutes, Optional)
- Release Updates (~10 minutes, Optional, release manager's discretion)
- Development Release
- Stable Release and point releases
- Older stable releases and point releases
- Contributor Tip of the Week (~2 minutes, Optional)
- These can be a variety of topics, including [devstats graphs]
- Community Group Updates
- Three presentations per meeting, 10 minutes per presentation. Either individual contributors or working group presentations.
- Announcements (~5 minutes)
- Any other community announcements should go here
- Shoutouts, an aggregation of thanks from community members to other contributors.
The first 10 minutes of a meeting is dedicated to demonstrations from the community. These demos are noted at the top of the community document. There is a hard stop of the demo at 10 minutes, with up to 5 more minutes for questions. Feel free to add your demo request to the bottom of the list, then one of the organizers will get back to you to schedule an exact date. Demo submissions MUST follow the requirements listed below:
This meeting has a large number of attendees. Out of respect for their time, we ask that you be fully prepared for your demo. Make sure slides are clear if applicable, and the link to them is posted in the meeting agenda. Also, if you are doing a live coding demo, please make sure it has a reasonable chance of completing within the allotted time box.
- Demos must be about a core component of Gorgonia or a related project that is owned by a special interest group utilizing Gorgonia.
- You are required to show up 10 minutes before the meeting to verify your audio and screensharing capabilities with the hosts. If you cannot make and keep this commitment, you will not be allowed to proceed with your demo until such time you can.
- You are also required to commit to being available the week before your demo date in case there is an issue with that week's demo.
- The use of a headset or other high-quality audio equipment is strongly encouraged. Typing on a laptop while using the system microphone is distracting, so please insulate your microphone from key noises.
- Ensure you are presenting from a quiet environment.
- If you run out of time while performing your demo, you may ask the audience if they would like a follow-up at a subsequent meeting. If there is enthusiastic support, the community team will help schedule a continuation.
Working Groups should give an update at least once a year. The update should mention:
- Topics where input is being sought from other contributors/groups.
- Topics that could affect other working groups.
- Currently active themes and goals in the working group
- Broad description of future themes and goals if possible
- Status of any notable features that are transitioning across the spectrum of incubation, alpha, beta, stable/GA, or are being deprecated
- New or deprecated subprojects
- Leadership position changes or updates
- Charter status and updates, if any
- How people can contribute, areas where help is needed
- Any pending Gorgonia Enhancement Proposals (GEPs) or general big ideas that might warrant outside input
- Prior 1.X.Y release patches in flight status
- Current 1.X release targeted feature status
- Rescheduling an update can happen, but is strongly discouraged as the schedule
is done with as much lead time as possible to allow working groups time to plan ahead
- Working groups should consider asking someone who is not a chair or lead to give this update as a mentorship/growth opportunity to newer members
- There is a [pregenerated slide template] that you can use for your status
- The update belongs entirely to the Working Group, there will be periods when "boring" work happens and the Working Group might want to not give a status update, instead consider a shorter update that at least lets the community know if you're in a quiet period. Informing the community that you've been clearing out the backlog in a 1 minute status is much better than not having a status report because you're concerned about not filling out the template in full. Just cut out what doesn't apply to you.
Since you only usually have ~10 minutes generally speaking if something is internal only to your Working Group and doesn't affect others it doesn't need to be mentioned, people can always attend your Working Group meeting for the details.
The document gets slow as we add notes, so it is archived regularly into the [Meeting Notes Archive].