Skip to content

More text update on owners. #12

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 1 commit into from
Nov 13, 2024
Merged

More text update on owners. #12

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
8 changes: 4 additions & 4 deletions community/language-change-process.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,12 +19,12 @@ Announce your intent to implement the feature in the [Announcement Channel in Gi

## Iterate on design and implementation

The OWNERs of docs/proposals (aka the “language OWNERs”) may weigh in on feature proposal issues to give guidance on what they expect will or will not be accepted as changes to the language.
The Owners of docs/proposals (aka the “language OWNERs”) may weigh in on feature proposal issues to give guidance on what they expect will or will not be accepted as changes to the language.

If it is clear to the language OWNERs that a proposed feature will not be accepted, they may close out the issue with an explanation of the reasoning.
If it is clear to the language Owners that a proposed feature will not be accepted, they may close out the issue with an explanation of the reasoning.
Ideally, you should wait to get positive feedback from at least one language OWNER before moving forward with implementation, to avoid the possibility of wasted effort.

Assuming positive community support for your proposal, move your tracking issue's status to "experimental" and begin putting up PRs for reviews by relevant code OWNERs.
Assuming positive community support for your proposal, move your tracking issue's status to "experimental" and begin putting up PRs for reviews by relevant code Owners.

During the implementation period, you are expected to:

Expand All @@ -42,7 +42,7 @@ Include in that PRs that (a) mark your feature stable in the code, (b) creates a

We encourage sending the intention to stabilize well in advance of wanting to actually have it ship stably — the more time, the more community feedback and ‘banging on the tires’ you can create.

At decision time, the owners listed in `docs/proposals/OWNERS.txt` will discuss privately (using OWNERs consensus) and share their decision on the email thread. After this, the relevant PRs can land as normal and the feature is stable.
At decision time, the Owners listed in `.github/CODEOWNERS` will discuss privately (using Owners consensus) and share their decision on the email thread. After this, the relevant PRs can land as normal and the feature is stable.

We expect that between 3-7 days will be given for community feedback in typical cases. Some lived experience is needed before we can make a policy about how long review periods need to last.

Expand Down