Skip to content

Update process.md #1815

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Oct 17, 2022
Merged

Update process.md #1815

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
bb1d7f4
Update process.md
benrimmington Oct 13, 2022
48d3370
Update process.md
benrimmington Oct 15, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
61 changes: 39 additions & 22 deletions process.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ Swift is a powerful and intuitive programming language that is designed to make

## Scope

The Swift evolution process covers all changes to the Swift language and the public interface of the Swift standard library, including new language features and APIs (no matter how small), changes to existing language features or APIs, removal of existing features, and so on. Smaller changes, such as bug fixes, optimizations, or diagnostic improvements can be contributed via the normal contribution process; see [Contributing to Swift](https://swift.org/community/#contributing).
The Swift evolution process covers all changes to the Swift language and the public interface of the Swift standard library, including new language features and APIs (no matter how small), changes to existing language features or APIs, removal of existing features, and so on. Smaller changes, such as bug fixes, optimizations, or diagnostic improvements can be contributed via the normal contribution process; see [Contributing to Swift](https://www.swift.org/contributing/).

## Goals

Expand All @@ -15,18 +15,18 @@ The Swift evolution process aims to leverage the collective ideas, insights, and

There is a natural tension between these two goals. Open evolution processes are, by nature, chaotic. Yet, maintaining a coherent vision for something as complicated as a programming language requires some level of coordination. The Swift evolution process aims to strike a balance that best serves the Swift community as a whole.

## Community structure

* [Core Team](https://www.swift.org/community/#core-team) members are responsible for the strategic direction of Swift.
* [Language Workgroup](https://www.swift.org/community/#language-workgroup) members initiate, participate in, and manage the public review of proposals and have the authority to accept or reject changes to Swift.

## Participation

Everyone is welcome to propose, discuss, and review ideas to improve
the Swift language and standard library in the
[Evolution section of the Swift forums](https://forums.swift.org/c/evolution).
Before posting a review, please see the section "What goes into a review?" below.

The Swift [core team](https://swift.org/community/#core-team) is
responsible for the strategic direction of Swift. Core team members
initiate, participate in, and manage the public review of proposals
and have the authority to accept or reject changes to Swift.

## What goes into a review?

The goal of the review process is to improve the proposal under review
Expand All @@ -53,20 +53,20 @@ of the upcoming Swift release. Proposals that are clearly out of scope
for the upcoming Swift release will not be brought up for review. If you can't resist discussing a proposal that you know is out of scope, please include the tag `[Out of scope]` in the subject.
* **Socialize the idea**: propose a rough sketch of the idea in the ["pitches" section of the Swift forums](https://forums.swift.org/c/evolution/pitches), the problems it solves, what the solution looks like, etc., to gauge interest from the community.
* **Develop the proposal**: expand the rough sketch into a complete proposal, using the [proposal template](proposal-templates/0000-swift-template.md), and continue to refine the proposal on the forums. Prototyping an implementation and its uses along with the proposal is *required* because it helps ensure both technical feasibility of the proposal as well as validating that the proposal solves the problems it is meant to solve.
* **Request a review**: initiate a pull request to the [swift-evolution repository][swift-evolution-repo] to indicate to the core team that you would like the proposal to be reviewed. When the proposal is sufficiently detailed and clear, and addresses feedback from earlier discussions of the idea, the pull request will be accepted. The proposal will be assigned a proposal number as well as a core team member to manage the review.
* **Request a review**: initiate a pull request to the [swift-evolution repository][swift-evolution-repo] to indicate to the Language Workgroup that you would like the proposal to be reviewed. When the proposal is sufficiently detailed and clear, and addresses feedback from earlier discussions of the idea, the pull request will be accepted. The proposal will be assigned a proposal number as well as a Language Workgroup member to manage the review.
* **Address feedback**: in general, and especially [during the review period][proposal-status], be responsive to questions and feedback about the proposal.

## Preparing an implementation

When you are ready to request a review, a pull request with an implementation is required in addition to your proposal. Proposals that can ship as part of the [Standard Library Preview package][preview-package] should be paired with a pull request against the [swift-evolution-staging repository][swift-evolution-staging]. All other proposals should be paired with an implementation pull request against the [main Swift repository](https://github.com/apple/swift).

The preview package can accept new types, new protocols, and extensions to existing types and protocols that can be implemented without access to standard library internals or other non-public features. For more information about the kinds of changes that can be implemented in the preview package, see [SE-0264](https://github.com/apple/swift-evolution/blob/master/proposals/0264-stdlib-preview-package.md).
The preview package can accept new types, new protocols, and extensions to existing types and protocols that can be implemented without access to standard library internals or other non-public features. For more information about the kinds of changes that can be implemented in the preview package, see [SE-0264](https://github.com/apple/swift-evolution/blob/main/proposals/0264-stdlib-preview-package.md).

## Review process

The review process for a particular proposal begins when a member of
the core team accepts a pull request of a new or updated proposal into
the [swift-evolution repository][swift-evolution-repo]. That core team
the Language Workgroup accepts a pull request of a new or updated proposal into
the [swift-evolution repository][swift-evolution-repo]. That Language Workgroup
member becomes the *review manager* for the proposal. The proposal
is assigned a proposal number (if it is a new proposal), and then enters
the review queue. If your proposal's accompanying implementation takes the form of a package, the review manager will merge your pull request into a new branch in the [swift-evolution-staging repository][swift-evolution-staging].
Expand All @@ -82,38 +82,55 @@ reviews. To avoid delays, it is important that the proposal authors be
available to answer questions, address feedback, and clarify their
intent during the review period.

After the review has completed, the core team will make a decision on
After the review has completed, the Language Workgroup will make a decision on
the proposal. The review manager is responsible for determining
consensus among the core team members, then reporting their decision
consensus among the Language Workgroup members, then reporting their decision
to the proposal authors and forums. The review manager will
update the proposal's state in the [swift-evolution
repository][swift-evolution-repo] to reflect that decision.

## Proposal states

```mermaid
flowchart LR
%% <https://mermaid-js.github.io/>

%% Nodes:
1{{"Awaiting\nreview"}}
2{{"Scheduled\nfor review"}}
3{"Active\nreview"}
4["Returned\nfor revision"]
5(["Withdrawn"])
6(["Rejected"])
7_8["Accepted\n(with revisions)"]
9[["Previewing"]]
10(["Implemented"])

%% Links:
1 ==> 3 ==> 7_8 ==> 10
1 -.-> 2 -.-> 3 -.-> 4 -.-> 5 & 1
3 -.-> 6
7_8 -.-> 9 -.-> 10
```

A given proposal can be in one of several states:

* **Awaiting review**: The proposal is awaiting review. Once known, the dates
for the actual review will be placed in the proposal document. When the review
period begins, the review manager will update the state to *Active review*.
* **Scheduled for review (FULL_MONTH_NAME DAY...FULL_MONTH_NAME DAY)**: The public review of the proposal
* **Scheduled for review (...)**: The public review of the proposal
in the [Swift forums][proposal-reviews]
has been scheduled for the specified date range.
* **Active review (FULL_MONTH_NAME DAY...FULL_MONTH_NAME DAY)**: The proposal is undergoing public review
* **Active review (...)**: The proposal is undergoing public review
in the [Swift forums][proposal-reviews].
The review will continue through the specified date range.
* **Returned for revision**: The proposal has been returned from review
for additional revision to the current draft.
* **Withdrawn**: The proposal has been withdrawn by the original submitter.
* **Deferred**: Consideration of the proposal has been deferred
because it does not meet the [goals of the upcoming major Swift
release](README.md). Deferred proposals will be reconsidered when
scoping the next major Swift release.
* **Rejected**: The proposal has been considered and rejected.
* **Accepted (YYYY-MM-DD)**:
The proposal has been accepted (on the specified date) and is either awaiting
* **Accepted**: The proposal has been accepted and is either awaiting
implementation or is actively being implemented.
* **Accepted with revisions (YYYY-MM-DD)**:
The proposal has been accepted (on the specified date),
* **Accepted with revisions**: The proposal has been accepted,
contingent upon the inclusion of one or more revisions.
* **Previewing**: The proposal has been accepted and is available for preview
in the [Standard Library Preview package][preview-package].
Expand Down