Community Roles

What are the roles held by individuals in the Layer5 community?

A leader is someone who can contribute to the Layer5 Community's growth by being accountable, participating in decision-making, and feeling responsible.

What does it take to be a leader?

Community Manager

Roles/Responsibilities:
A Community Manager is a person who has an innate drive to contribute to the community's prosperity. A community manager serves as a link between the organisation and its community, overcoming obstacles as they arise—or even before they arise!—by collaborating with other departments and the community to find solutions that benefit the entire community.

  • Moderating, engaging, and supporting community members on platforms like Slack, GitHub etc.
  • Building healthy relationships among community members.
  • Celebrating community successes, sending swag, and recognizing top contributors.
  • Regularly updating the community on the metrics performance.
  • Creating and managing new community programs.
  • Organizing meetups, events, and other engagements.
  • Coordinating with other departments—such as product, engineering, and content marketing—to support community initiatives.

Checklist before becoming a Community Manager


MeshMate

Roles and Responsibilities:
Layer5 MeshMates are committed to helping community members be successful contributors. MeshMates aid in identifying areas of projects to engage within, working groups to join, and helping community members grow in their open-source and cloud-native knowledge. By connecting one-on-one, MeshMates will share tips on how to have the best community experience possible.

  • Increasing awareness of the community to others
  • Helping newbies in the community get familiar with all of the projects
  • Providing necessary resources to contributors
  • Mentoring members of the community
  • Facilitate newcomers call

Maintainer

Roles/Responsibilities:
Maintainers are those who are responsible for managing the growth and performance of the project. They are incharge of the project's wellbeing, reviewing and merging the PR, updating the libraries and dependencies in that project, monitoring the codebase and so much more.

  • Send a reminder about meetings
  • Prepare meetings
  • Lead meetings
  • Make sure meeting minutes are kept
  • Facilitate the creation and advancement of metrics/software
  • Answer questions about the progress of Layer5 projects
  • Report on weekly community call progress on a project
  • Review issues on the repository
  • Review and merge pull requests
  • Regularly check the repository for stale content
  • Monitor issue tracker and pull requests

Checklist before becoming a Maintainer

Release Manager Role

The role of release manager for a release lasts a total of about 6 months. This is divided up among activities before the initial release comes out and activities after the initial release while the release is within active maintenance. The majority of the time is spent in the month before the first release. After that, there is 6 months of time during which point releases come out on approximately a 3 week cycle. During three of these months, the release manager is working on the latest release. This 6 month time period is divided into two sections. In the first three months, this is the primary release and all fixes get cherry-picked from master here. After 3 months, the next release of the Meshery project comes out and there are three more months of support before this release goes to the end of life.

Responsibilities

Before Release

  • Cutting branches -- 8 to 16 hours divided between all release managers. Working on automating. Will still take a while with automation, probably around half a day. With automation, a lot of the time will be waiting for automated steps to complete as opposed to being directly involved.
  • Testing days -- 8 to 16 hours divided between all release managers spread over two weeks in order to orchestrate the testing events. This does not include any time that the release managers additionally devote to picking up and testing individual tests.
  • Spreadsheets
  • Prioritization
  • Chasing people to get things done
  • Prioritization of issues in step with workgroups
  • Release management meetings -- 45 minutes to 1 hour every week for each release manager. Increases as the release gets closer.
  • Release notes/upgrade notes for point release -- 1 week for of the release managers as well as reviewing from other release managers
  • Code reviews from docs team as well as workgroup leads
  • Generation of release notes using automated tooling
  • Updating release notes to make them more readable
  • Announcement of release on Twitter/Discuss/Slack -- 5 minutes for one release manager for Discuss/Slack. For Twitter, reach out to someone with access.

Ongoing for all releases

  • Watching for release blockers - part of the code review process. Wouldn't say it needs additional time
  • Code reviews/deciding whether to accept cherry picks -- about an hour per day for each release manager. Ramps up just before the initial release. Ramps down to an hour per week towards the EOL for a release
  • Minor release every 3 weeks.
  • Release notes - 1 hour for a single release manager
  • Creating releases - 8 hours spread across all release managers. Most of this is automated (i.e. update proxy and then wait for tests to complete, trigger a build and wait for tests to complete)
  • 48 hour testing -- this involves requesting those who run the tests to trigger the tests and waiting for 48 hours. There is very little needed from a release manager other than checking in to make sure everything is working well
  • Handle vulnerability fix integration in step with product security workgroup -- approximately 3 patch releases -- for private security releases, release managers are responsible for coordinating a flush release to get all fixes before the security fix out as well as ensuring they don't accept patches until the release is out. Most of the additional release related work is taken care of by the security fix lead although the release managers are expected to review release notes, build PRs, and other related content. The flush release takes about the same amount of time as a regular release.
  • Meshery build and release meetings -- one hour per release manager per week
  • End Of Life for release -- 8 hours

Qualifications for Release Manager

  • A member of the Layer5 community and active for the last 3 months
  • Approved by a majority vote of current maintainers.
  • At least one release manager for each version needs to meet requirements for access info in case of vulnerabilities

Process for volunteering for release management

Contact a current maintainer to volunteer or nominate yourself.

Layer5, the cloud native management company

An empowerer of engineers, Layer5 helps you extract more value from your infrastructure. Creator and maintainer of cloud native standards. Maker of Meshery, the cloud native manager.