Skip to content

Commit b23226f

Browse files
authored
Merge pull request #1902 from kalisjoshua/pr-to-pull-request
Change PR to pull request
2 parents 73a65af + 0ba091c commit b23226f

File tree

1 file changed

+24
-22
lines changed

1 file changed

+24
-22
lines changed

README.md

Lines changed: 24 additions & 22 deletions
Original file line numberDiff line numberDiff line change
@@ -113,29 +113,31 @@ are disingenuous about the drawbacks or alternatives tend to be poorly-received.
113113
from the larger community, and the author should be prepared to revise it in
114114
response.
115115
* Each pull request will be labeled with the most relevant [sub-team].
116-
* Each sub-team triages its RFC PRs. The sub-team will either close the PR
117-
(for RFCs that clearly will not be accepted) or assign it a *shepherd*. The
118-
shepherd is a trusted developer who is familiar with the RFC process, who will
119-
help to move the RFC forward, and ensure that the right people see and review
120-
it.
116+
* Each sub-team triages its RFC pull requests. The sub-team will either close
117+
the pull request (for RFCs that clearly will not be accepted) or assign it a
118+
*shepherd*. The shepherd is a trusted developer who is familiar with the RFC
119+
process, who will help to move the RFC forward, and ensure that the right people
120+
see and review it.
121121
* Build consensus and integrate feedback. RFCs that have broad support are much
122122
more likely to make progress than those that don't receive any comments. The
123123
shepherd assigned to your RFC should help you get feedback from Rust developers
124124
as well.
125125
* The shepherd may schedule meetings with the author and/or relevant
126126
stakeholders to discuss the issues in greater detail.
127-
* The sub-team will discuss the RFC PR, as much as possible in the comment
128-
thread of the PR itself. Offline discussion will be summarized on the PR comment
129-
thread.
127+
* The sub-team will discuss the RFC pull request, as much as possible in the
128+
comment thread of the pull request itself. Offline discussion will be summarized
129+
on the pull request comment thread.
130130
* RFCs rarely go through this process unchanged, especially as alternatives and
131131
drawbacks are shown. You can make edits, big and small, to the RFC to
132-
clarify or change the design, but make changes as new commits to the PR, and
133-
leave a comment on the PR explaining your changes. Specifically, do not squash
134-
or rebase commits after they are visible on the PR.
132+
clarify or change the design, but make changes as new commits to the pull
133+
request, and leave a comment on the pull request explaining your changes.
134+
Specifically, do not squash or rebase commits after they are visible on the pull
135+
request.
135136
* Once both proponents and opponents have clarified and defended positions and
136137
the conversation has settled, the RFC will enter its *final comment period*
137-
(FCP). This is a final opportunity for the community to comment on the PR and is
138-
a reminder for all members of the sub-team to be aware of the RFC.
138+
(FCP). This is a final opportunity for the community to comment on the pull
139+
request and is a reminder for all members of the sub-team to be aware of the
140+
RFC.
139141
* The FCP lasts one week. It may be extended if consensus between sub-team
140142
members cannot be reached. At the end of the FCP, the [sub-team] will either
141143
accept the RFC by merging the pull request, assigning the RFC a number
@@ -181,7 +183,7 @@ through to completion: authors should not expect that other project
181183
developers will take on responsibility for implementing their accepted
182184
feature.
183185

184-
Modifications to active RFC's can be done in follow-up PR's. We strive
186+
Modifications to active RFC's can be done in follow-up pull requests. We strive
185187
to write each RFC in a manner that it will reflect the final design of
186188
the feature; but the nature of the process means that we cannot expect
187189
every merged RFC to actually reflect what the end result will be at
@@ -198,18 +200,18 @@ specific guidelines in the sub-team RFC guidelines for the [language](lang_chang
198200
## Reviewing RFC's
199201
[Reviewing RFC's]: #reviewing-rfcs
200202

201-
While the RFC PR is up, the shepherd may schedule meetings with the
203+
While the RFC pull request is up, the shepherd may schedule meetings with the
202204
author and/or relevant stakeholders to discuss the issues in greater
203205
detail, and in some cases the topic may be discussed at a sub-team
204206
meeting. In either case a summary from the meeting will be
205207
posted back to the RFC pull request.
206208

207209
A sub-team makes final decisions about RFCs after the benefits and drawbacks are
208210
well understood. These decisions can be made at any time, but the sub-team will
209-
regularly issue decisions. When a decision is made, the RFC PR will either be
210-
merged or closed. In either case, if the reasoning is not clear from the
211-
discussion in thread, the sub-team will add a comment describing the rationale
212-
for the decision.
211+
regularly issue decisions. When a decision is made, the RFC pull request will
212+
either be merged or closed. In either case, if the reasoning is not clear from
213+
the discussion in thread, the sub-team will add a comment describing the
214+
rationale for the decision.
213215

214216

215217
## Implementing an RFC
@@ -240,9 +242,9 @@ closed (as part of the rejection process). An RFC closed with “postponed” is
240242
marked as such because we want neither to think about evaluating the proposal
241243
nor about implementing the described feature until some time in the future, and
242244
we believe that we can afford to wait until then to do so. Historically,
243-
"postponed" was used to postpone features until after 1.0. Postponed PRs may be
244-
re-opened when the time is right. We don't have any formal process for that, you
245-
should ask members of the relevant sub-team.
245+
"postponed" was used to postpone features until after 1.0. Postponed pull
246+
requests may be re-opened when the time is right. We don't have any formal
247+
process for that, you should ask members of the relevant sub-team.
246248

247249
Usually an RFC pull request marked as “postponed” has already passed
248250
an informal first round of evaluation, namely the round of “do we

0 commit comments

Comments
 (0)