Skip to content

Latest commit

 

History

History
166 lines (139 loc) · 16 KB

annual-report-2020.md

File metadata and controls

166 lines (139 loc) · 16 KB

Kubernetes SIG Storage Community Group Annual Reports 2020

This report reflects back on CY 2020 and was written in Feb-Mar. 2021.

Operational

Membership

  • Are all listed SIG leaders (chairs, tech leads, and subproject owners) active?

    • Yes
  • How do you measure membership? By mailing list members, OWNERs, or something else?

    • Mailing list members, participants of SIG meetings, and folks working on SIG-Storage projects.
  • How does the group measure reviewer and approver bandwidth? Do you need help in any area now? What are you doing about it?

    • At the SIG-Storage bi-weekly meetings, we track the progress of each feature the SIG is working on. Each feature has dev leads and reviewers assigned to it. If a developer/reviewer does not have time to do the design/development/reviews, we’ll try to find someone else who has the bandwidth.
    • For features that are GA, we still continue to maintain and fix bugs and make enhancements. For example, dynamic provisioning has been a GA feature for quite a while now. We still fix bugs and continue to enhance it if needed. Another example is volume snapshot which just moved to GA in 1.20. We are still working on small enhancements, adding tests, fixing bugs, etc. The work is still being tracked in weekly standup meetings.
    • We also have this new sub-project COSI which has been very active. It has a weekly standup meeting and a weekly design meeting. A few contributors have been actively working on design and development there.
  • Is there a healthy onboarding and growth path for contributors in your SIG? What are some activities that the group does to encourage this? What programs are you participating in to grow contributors throughout the contributor ladder?

    • For each feature the SIG is working on, the SIG lead or dev lead will be looking for contributors by adding the “Help wanted” tag on an issue and/or asking for helpers in SIG-Storage bi-weekly meetings. This is a great opportunity for new contributors to step up to contribute and become members of kubernetes and eventually owners of a project.
    • In the beginning of each kubernetes release, we have a planning meeting to go over all features targeted for that release. We encourage everyone to add features they want to work on in the planning spreadsheet. This is a good time for new contributors to learn our planning process, and volunteer to be involved in some of the feature development work.
  • What programs do you participate in for new contributors?

    • At the Contributor Summit at KubeCon, we usually have a Meet & Greet for new contributors.
    • At the bi-weekly SIG-Storage meetings, we also call out to any new contributors who are willing to help on some projects that we are looking for developers or reviewers.
  • Does the group have contributors from multiple companies/affiliations? Can end users/companies contribute in some way that they currently are not?

Current initiatives and project health

[ ] Please include links to KEPs and other supporting information that will be beneficial to multiple types of community members.

What are initiatives that should be highlighted, lauded, shout out, that your group is proud of? Currently underway? What are some of the longer tail projects that your group is working on?

Year to date KEP work review: What’s now stable? Beta? Alpha? Road to alpha?

What areas and/or subprojects does the group need the most help with?

  • There are features that we co-owned with sig-node, sig-apps, etc. We would need help from other SIGs to move things forward.

  • There are also areas where we need sig-architecture’s help. For example, VolumeSnapshot is already GA and it is a core feature in sig-storage developed using CRDs. We have documented and blogged that components such as the snapshot CRDs and snapshot controller need to be deployed by Kubernetes distros, however, not every distro is installing them. This is a problem with any feature developed using CRD. We hope sig-architecture can help us resolve this problem.

What's the average open days of a PR and Issue in your group? / what metrics does your group care about and/or measure?

According to the following stats on 1/25/2021, it shows the 7 day MA for a PR Time to Approve and Merge in sig-storage repository group is:

Age of 7 day MA of issues by sig-storage repository group on 1/25/2021:

Suggestions on how to improve the PR/Issue velocity:

  • Increase the reviewer pool
  • Regular issue triage meetings