Skip to content

Latest commit

 

History

History
169 lines (149 loc) · 8.76 KB

charter.md

File metadata and controls

169 lines (149 loc) · 8.76 KB
Raw

SIG Service Catalog Charter

This charter adheres to the conventions described in the Kubernetes Charter README.

Scope

Service Catalog is a Kubernetes extension project that implements the Open Service Broker API (OSBAPI). It enables application developers to provision cloud services from within Kubernetes and integrates configuration and discovery of those services into Kubernetes resources.

In scope

See the service-catalog SIG entry.

This SIG’s main goals are:

  • Support, and adhere to, the Platform requirements of the OSBAPI specification.
  • Provide a UX for Kubernetes users that is consistent with both the OSB API specification and traditional Kubernetes user interactions.
  • Align with the OSBAPI specification as changes are made.
  • Provide feedback (bugs or feature requests) to the [OSBAPI WG]](https://www.openservicebrokerapi.org/).

Code, Binaries and services

  • Source Repository
    • See OWNERS for who has access.
  • Image Repository
    • Canary builds are published on pushes to master.
    • Release builds (and latest) are published on tags.
    • Chairs have access to manage this repository.
  • Helm Repository
    • Charts are automatically published as part of the release process.
  • svc-cat.io
    • Published on pushes to master.
    • Site hosted with Netlify.
    • Chairs and interested maintainers have access to manage this site.
  • CLI Binary Hosting
    • Canary builds are published on pushes to master.
    • Release builds (and latest) are published on tags.
    • Files hosted on Azure blob storage.
    • Azure account managed by Carolyn Van Slyck (Microsoft) and Aaron Schlesinger (Microsoft).
  • Travis
    • Runs the CI builds.
    • Maintainers have access.
  • Jenkins
    • Runs end-to-end tests on a live cluster.
    • Server managed by Michael Kibbe (Google).

Out of scope

The following, non-exhaustive, items are out of scope:

  • Operation of OSBAPI Service Brokers.

Roles

This SIG's charter deviates from the sig-governance roles. We do not have the Tech Lead role, and have a honorary Emeritus Chair role.

  • Maintainers

    • Maintainer is equivalent to the standard Kubernetes definition of Approver.
    • Responsible for reviewing pull requests, and approving pull requests for merge.
    • Responsible for technical planning and stewardship of the project.
    • New maintainers may be nominated by another maintainer, and accepted via lazy two-thirds resolution amongst the chairs.
    • Maintainers may be nominated for removal from their position by a chair, and accepted via lazy two-thirds resolution amongst the chairs.
    • Maintainers may propose changes to this charter at any time, by submitting a pull request and then notifying the SIG mailing list, to be accepted via lazy two-thirds resolution amongst the chairs.

  • Chairs

    • Chairs are expected to perform the role of maintainer, in addition to their chair responsibilities.
    • Chairs are listed in our SIG definition.
    • Responsible for project administration activities within the SIG and are non-technical in nature, such as organizing the weekly meetings.
    • A chair does not have more rights, or votes, than a maintainer.
    • Responsible for reporting the SIG’s status to the appropriate Kubernetes leadership teams.
    • All decisions amongst chairs are made using lazy consensus with a fallback to a 2/3 majority vote (lazy two-thirds resolution). This process is used for all decisions, such as changing chairs/maintainers or modifying this charter.
    • Chairs may nominate a new chair at any time, to be accepted via lazy two-thirds resolution amongst the chairs.
    • Chairs may decide to step down at any time.
    • Chairs must remain active in the role and may be removed from the position via lazy two-thirds resolution amongst the chairs, if they are unresponsive for > 3 months or are not proactively working with other chairs to fulfill responsibilities.
    • There is no set number of Chairs.

  • Emeritus Chairs (Inspired by the Helm Project)

    • A chair who steps down may choose to take an Emeritus Chair title. This confers honor on the recipient and allows them to remain associated with the SIG in acknowledgement of their significant contributions.
    • Those who attain this title are no longer expected to attend the weekly meetings, share in the issue queue triage rotation, vote on policy or architectural issues, or review pull requests.
    • They are listed in our documentation as Emeritus Chairs, and we will continue to invite them to participate in related events, such as KubeCon.

  • Security Contacts

    • Are a contact point for the Product Security Committee to reach out to for triaging and handling of incoming issues.
    • Must be a maintainer.
    • Must accept and adhere to the Kubernetes Embargo Policy.
    • Defined in SECURITY_CONTACTS file.

Organizational management

  • SIG meets every week on Zoom at 1 PM PST on Mondays
    • Agenda here.
    • Anyone is free to add new agenda items to the doc.
    • Recordings of the calls are made available here.
  • SIG members explicitly representing the group at conferences (SIG progress reports, deep dives, etc.) should make their slides available for perusal and feedback at least 2 week in advance.
  • Working groups can be initiated by any member. To create a new one, add the topic to the weekly call’s agenda for discussion.
    • These are not the same as cross-SIG working groups.
    • Working groups exist for an unspecified period of time, so that interested members can meet to discuss and solve problems for our SIG.

Project management

  • Milestones are defined by SIG maintainers.
  • Anyone is free to request a discussion of the milestones/plans during a weekly call.
  • Weekly releases are typically done on Thursdays, and any member who has maintainer rights is free to initiate it. Friday releases are strongly discouraged.
  • Major releases are planned and discussed among the SIG members during regular weekly calls.
  • The release process is defined here.
  • Anyone can request to work on an issue by commenting on it with #dibs.

Technical processes

  • All technical decisions are made either through issues, pull requests or discussions during the weekly SIG meeting. Major decisions should be documented in an issue or pull request.
  • There is no requirement that all pull requests have an associated issue. However, if the PR represents a significant design decision then it is recommended that it be discussed among the group to avoid unnecessary coding that might not be accepted.
  • While everyone is encouraged to contribute to the discussion of any topic, ultimately any changes made to the codebase must be approved by the maintainers.
  • Pull requests are required to have at least 2 maintainers approve them.
  • Pull requests that are labeled with do-not-merge/hold or have an on-going discussion must not be merged until all concerns are addressed.
  • Disagreements are resolved via lazy consensus. In the event that a common decision cannot be made, then a vote among the maintainers will be taken. Simple majority of votes cast (>50%) wins.