Skip to content

Latest commit

 

History

History
160 lines (117 loc) · 10.7 KB

annual-report-2020.md

File metadata and controls

160 lines (117 loc) · 10.7 KB

Kubernetes SIG API Machinery - 2020 Annual report

David Eads, Daniel Smith, Federico Bongiovanni

Source

Checklist

  • Read about the process here
  • Copy this template into a new document and share with your mailing list/slack channel/meeting on whatever platform (gdocs, hackmd, etc.) that the team prefers.
  • Remove sections that are not applicable (example: if you are a working group, delete the special interest group questions)
  • Pick graphs from Devstats to pull supporting data for your responses.
  • Schedule a time with your Steering liaison and other Chairs, TLs, and Organizers of your group to check-in on your roles as Chair or Working Group Organizer. If anyone would rather meet 1:1, please have them reach out to the liaison directly, we are happy to. We’d like to talk about: challenges, wins, things you didn’t know before but wish you did, want to continue in the role or help finding a replacement; and lastly any feedback you have for us as a body and how we can help you succeed and feel comfortable in these leadership roles.
  • PR this document into your community group directory in kubernetes/community (example: sig-architecture/)
    • by March 8th, 2021
    • titled: annual-report-YEAR.md
  • are there any responses that you’d like to share privately first? [email protected] or tag your liaison in for discussion.

Operational

  1. How are you doing with operational tasks in SIG-governance.md?

    1. Is your README accurate? have a CONTRIBUTING.md file?

      Yes, the README is accurate.

    2. All subprojects correctly mapped and listed in sigs.yaml?

      Yes, our subprojects are current.

    3. What’s your meeting culture? Large/small, active/quiet, learnings? Meeting notes up to date?

      Are you keeping recordings up to date/trends in community members watching recordings?

      We have two main meetings, both fairly small, with notes and agenda up to date. Our recordings are usually uploaded within two weeks.

      There are bug scrub meetings every Tuesday and Thursday.

  2. How does the group get updates, reports, or feedback from subprojects? Are there any springing up or being retired? Are OWNERS.md files up to date in these areas?

    We get updates on an ad-hoc basis. We have approved a prototyping project (apiserver-runtime) and have no plans to retire any at this time. We have not actively pruned OWNERS, some people have been added to various subprojects.

  3. Same question as above but for working groups. wg-api-expression has its own regular meeting cadence and did its own annual report.

    wg-component-standard has its own regular meeting cadence. The working group is not as active as it once was, see the mailing list thread.

    wg-multitenancy has its own regular meeting cadence and did its own annual report.

  4. When was your last public community-wide update? (provide link to deck and/or recording) May 2020

Membership

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

    Yes.

  2. How do you measure membership? By mailing list members, OWNERs, or something else?

    We don’t measure membership.

  3. How does the group measure reviewer and approver bandwidth? Do you need help in any area now? What are you doing about it?

    Our predicted rate of feature delivery and stability roughly matches the achieved rate. While we would be happy to see developers move up the ladder, we don’t see a pressing need to adjust the current rate.

    We perform twice a week triage and our issue open/close rates are holding steady.

  4. 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?

    We see patches from first time contributors, we regularly accept agenda items from contributors from other sigs and first time contributors.

  5. What programs do you participate in for new contributors?

    We don’t participate in any particular programs. We find many contributors via slack, PRs, and issues.

  6. Does the group have contributors from multiple companies/affiliations? Can end users/companies contribute in some way that they currently are not?

    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.

Current initiatives and project health

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

    Currently underway:

    1. server-side-apply to GA
    2. server-side-apply client
    3. optionally skip backend TLS verifiction
    4. namespace labels
    5. Getting ready for CRD and admission webhook v1beta1 API removal: reminder on kubernetes-dev.
    6. Immutable fields API
    7. API unions
    8. warnings to GA
    9. apiserver network proxy to beta
    10. priority and fairness to GA

  2. Year to date KEP work: What's now stable? Beta? Alpha? Road to alpha?

    1. Stable
      1. Selector index - 1.20
      2. Permabeta machinery (sig-arch policy) - 1.19
      3. Client-go context - 1.18
      4. Client-go options - 1.18
      5. Dry run - 1.18
      6. Standardize conditions - 1.19
    2. Beta
      1. Priority and fairness - 1.20
      2. Selector index - 1.19
      3. Self-link removal - 1.20
      4. Warning headers - 1.19
      5. Server-side apply evolution while in beta - 1.18, 1.19, 1.20
    3. Alpha
      1. Selector index - 1.18
      2. API server identity - 1.20
      3. Efficient watch resumption - 1.20
    4. Pre-alpha
      1. Manifest-based admission webhook

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

    We are working on mitigating the impact of removing beta APIs in 1.22.

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

    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.

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

    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
    • diverse representation of companies in the sig participants