Skip to content

Latest commit

 

History

History
234 lines (189 loc) · 15.1 KB

annual-report-2021.md

File metadata and controls

234 lines (189 loc) · 15.1 KB
Raw

2021 Annual Report: SIG API Machinery

Current initiatives

  1. What work did the SIG do this year that should be highlighted?

    • Server Side Apply promoted to GA
    • Deprecated v1beta1 of Custom Resources and Webhooks (in favor of GA version)
    • API Priority and Fairness introduced v1beta2
    • A massive amount of improvements in the API Expression WG

  2. What initiatives are you working on that aren't being tracked in KEPs?

    • We are evaluating long term the potential benefits that generics in go1.19 could provide.

  3. KEP work in 2021 (1.x, 1.y, 1.z):

Need to pull from https://github.com/kubernetes/enhancements/issues?q=is%3Aissue+label%3Asig%2Fapi-machinery+updated%3A%3E%3D2021-01-01+is%3Aclosed

Project health

  1. What areas and/or subprojects does your group need the most help with? Any areas with 2 or fewer OWNERs? (link to more details)

    The SIG sponsors some working groups that are largely independent.

    There are several areas where regularly the SIG becomes under pressure, especially closer to code freezes and the vast amount of code owned by API Machinery.

    The ecosystem of the different Kubernetes Clients that we own grows more or less organically. Client-go and Python-client are probably the bigger ones.

    There are some packages that API Machinery owns and come out usually in our triage meetings, and that we most likely don't know much about: this happens often when Kubernetes is upgrading libraries for example.

    Technical support for triages could have improvements, for example sometimes we remove API Machinery in PRs, and every update to the issue / pr get's us re- tagged again.

  2. What metrics/community health stats does your group care about and/or measure?

On the technical health of the SIG, we look at

  • the ratio of open/close PRs
  • the ratio of open/close Issues
  • overall age of open Issues
  • Number of active contributors to the sig

On the inclusion health of the SIG, we look at:

  • representation of diversity and of multiple companies in the sig participants

  1. Does your CONTRIBUTING.md help new contributors engage with your group specifically by pointing to activities or programs that provide useful context or allow easy participation?

    • No, it can be improved. Usually we find many contributors via slack, PRs, and issues.

  2. If your group has special training, requirements for reviewers/approvers, or processes beyond the general contributor guide, does your CONTRIBUTING.md document those to help existing contributors grow throughout the contributor ladder?

    • No, it can be improved. The main concern has always been the large amount of investment that is required to ramp up new contributors

  3. Does the group have contributors from multiple companies/affiliations?

    Yes, there are contributors from multiple companies. We see all sorts of contributions, varying from issues, to comments, to PRs, to designs, to sig meeting participation, and user-survey data.

  4. Are there ways end users/companies can contribute that they currently are not? If one of those ways is more full time support, what would they work on and why?

    • This is a topic that appears frequently. API Machinery owns ~40% of the Kubernetes code base. In the past, we had some newcomers show up in SIG meetings with very concrete support questions. This is not the right forum, and that is not what we want to turn those meetings into.
    • There is plenty of areas were the SIG could use help in reviewing and maintaining the code, but it's a complicated code base to ramp up. If people don't stick around long enough, the effort does not make sense.

Membership

  • Primary slack channel member count: 3,384
  • Primary mailing list member count: 689
  • Primary meeting attendee count (estimated, if needed): 30
  • Primary meeting participant count (estimated, if needed): 10
  • Unique reviewers for SIG-owned packages:
  • Unique approvers for SIG-owned packages:

Include any other ways you measure group membership

Subprojects

Continuing: The following [subprojects][subproject-definition] are owned by sig-api-machinery:

component-base

control-plane-features

idl-schema-client-pipeline

json

kubernetes-clients

server-api-aggregation

server-binaries

server-crd

server-frameworks

server-sdk

universal-machinery

yaml

Working groups

Continuing: The following working groups are sponsored by sig-api-machinery:

Operational

Operational tasks in sig-governance.md:

  • README.md reviewed for accuracy and updated if needed
  • CONTRIBUTING.md reviewed for accuracy and updated if needed (or created if missing and your contributor steps and experience are different or more in-depth than the documentation listed in the general contributor guide and devel folder.)
  • Subprojects list and linked OWNERS files in sigs.yaml reviewed for accuracy and updated if needed
  • SIG leaders (chairs, tech leads, and subproject owners) in sigs.yaml are accurate and active, and updated if needed
  • Meeting notes and recordings for 2021 are linked from README.md and updated/uploaded if needed
  • Did you have community-wide updates in 2021 (e.g. community meetings, kubecon, or kubernetes-dev@ emails)? Links to email, slides, or recordings: - Kubecon NA 2021 - Community update