SSWG Incubation Process

Overview

As described on the server page, the goal of the Swift Server Work Group (SSWG) is to create a robust, healthy ecosystem for server application development with Swift. One avenue to achieve this goal is to encourage the development of high quality, well maintained libraries and tools that the community can comfortably lean on.

The difference between the SSWG and the Swift Evolution process is that server-oriented libraries and tools that are produced as a result of work group efforts will exist outside of the Swift language project itself, and they will be distributed across different code bases.

The teams at Apple and Vapor have engineers that will actively participate in the development of such libraries and tools, and we would love to see the community joining in this effort. To that end, the work group defined and launches an incubation process where anyone can pitch, propose, develop, and contribute to such libraries and tools.

The incubation process is designed to help nurture and mature projects ensuring standardization, quality, and longevity. It also seeks to increase the visibility of ideas, experiments, or other early work that can add value to the SSWG mission. The following document details this incubation process. The SSWG steering group has a similar role to the Swift Core Team and will make the final decision on moving pitches/proposals through the incubation process based on the feedback of the community. Just like for Swift Evolution, pitches and proposals can be made by anyone, being part of the SSWG steering group is absolutely not a requirement.

Process

Incubation is made of the following stages: Pitch, Proposal, Development, and Recommendation. The Development stage is where the majority of incubation take place. The SSWG will maintain a public “Swift Server Ecosystem” index page that will list all recommended tools and libraries as well as projects that are part of the incubation process and their respective incubation level.

Pitch

Pitches are an introduction to an idea for a new library or tool. They can also introduce ideas for new features or changes to existing tools. Pitches are used to collect feedback from the community and help define the exact scope of a project prior to writing code. They should demonstrate how they align with the SSWG’s goals to improve Swift on the server. Pitches are submitted by creating a new thread in the Swift Server forum area.

Proposal

For a pitch to be moved into the Proposal stage, it must be endorsed by at least two members of the SSWG. The scope of the proposed code needs to closely align with the endorsed Pitch and it is subject to review based on the SSWG graduation criteria defined below.

Proposals are submitted to the SSWG by creating a PR that adds the proposal document to the proposal directory. Proposals follow a template and include the following information:

Once a proposal PR is submitted, the SSWG will assign a review manager during it’s bi-weekly meeting. The review manager responsibilities include:

The SSWG votes on pending proposals on a bi-weekly cadence, with the goal of voting on at least two proposals per month.

After the vote, the review manager will:

  1. Announce the vote results in the review thread.
  2. Update the Proposal’s status based on the vote result.
  3. Close the review thread.

Graduation Criteria

Every SSWG project has an associated maturity level: Sandbox, Incubating, or Graduated. Proposals should state their preferred initial maturity level, and the SSWG will take a vote to decide on the actual level.

A supermajority (two-thirds) is required for a project to be accepted as Incubating or Graduated. If there is not a super-majority of votes to enter at the Graduated level, then the votes toward Graduated are recounted as votes to enter at the Incubating level. If there is not a super-majority of votes to enter at the Incubating level, then all votes are recounted as sponsorship to enter at the Sandbox level. If there are not at least two sponsors, the Proposal is rejected.

Sandbox Level

To be accepted at the Sandbox level, a project must meet the SSWG minimal requirements detailed below and be endorsed by at least two SSWG sponsors.

Early adopters should treat early stage projects with extra care. While Sandbox projects are safe to try out, it is expected that some projects may fail and never move to the next maturity level. There is no guarantee of production readiness, users, or professional level support. As such, users must exercise their own judgment.

Incubating Level

To be accepted at Incubating level, a project must meet the Sandbox level requirements plus:

Graduated Level

To be accepted at Graduated level, a project must meet the SSWG graduation requirements detailed below, plus:

Process Diagram

process diagram

Ecosystem Index

All projects and their respective levels will be listed on the Swift Server Ecosystem Index. In cases where more than one project solves a particular problem (e.g., two similar database drivers), they will be ordered by popularity. The SSWG reserves the right to define a singular solution for critical building blocks, such as Logging or Metrics APIs, where consistency across the ecosystem is of a critical nature.

It is recommended for projects that have been accepted to any of the maturity levels to list the maturity level in their project’s README with the appropriate badge as defined:

sswg:sandbox sswg:incubating sswg:graduated

The SSWG will meet every 6 months to review all projects, and it reserves the right to demote, archive, or remove projects that no longer fulfill minimal requirements. For example, a Graduated project that no longer receives regular updates or fails to address security concerns in timely fashion. Similarly, the SSWG reserves the right to remove or archive Pitches and Proposals that no longer receive updates.

Changes to the Swift Server Ecosystem index page will be announced by the SSWG using the Swift Server forums.

Minimal Requirements

Graduation Requirements

Security

Please follow the guidance laid out in the Security section.

Technical Best Practices

Change Management

Changes to the incubation process must be documented and published publicly and are subject to semantic versioning schema:

Updates resulting in a version bump require a super-majority vote from the SSWG. Trivial changes, such as fixing typos or formatting, do not require a version bump.

Resources and References