Rename RFC to PPC in the docs

Author: book

README.md

@@ -1,4 +1,4 @@
-This repository is for *Requests For Comments* - proposals to change the Perl language.
+This repository is for *Proposed Perl Changes* - proposals to change the Perl language.
 
 Right now, we're [trialling the process](docs/process.md). If you would like to submit a feature request, please [email an *elevator pitch*](mailto:[email protected]) - a short message with 4 paragraphs:
 
@@ -12,7 +12,7 @@ and if a "paragraph" is 1 sentence, great.
 That will be enough to make it obvious whether the idea is
 
 0) actually a **bug** - a change we'd also consider back porting to maintenance releases (so should be a opened as [*Report a Perl 5 bug*](https://github.com/Perl/perl5/issues/new/choose))
-0) worth drafting an RFC for
+0) worth drafting an PPC for
 0) better on CPAN first
 0) "nothing stops you putting it on CPAN, but it doesn't seem viable"
 
@@ -24,12 +24,12 @@ These files describe the process we are trialling
 
 * [motivation.md](docs/motivation.md) - why do we want to do something
 * [process.md](docs/process.md) - the initial version of the process
-* [template.md](docs/template.md) - the RFC template
+* [template.md](docs/template.md) - the PPC template
 * [future.md](docs/future.md) - how we see the process evolving
 * [others.md](docs/others.md) - what others do (or did), and what we can learn from them
 
 ## The Tracker
 
-The status of proposals is tracked in "[the RFC
+The status of proposals is tracked in "[the PPC
 Tracker](https://docs.google.com/spreadsheets/d/1hVOS7ePuLbVkYcf5S-e_eAodj4izm9Cj7AVs25HvngI)",
 a Google Sheets spreadsheet.  Keep up to date there!

docs/future.md

@@ -12,27 +12,27 @@ so there's a deliberately a lot of hand holding and centralisation, so that we c
 
 ## If the process works, I'd like to progress to
 
-* people submit draft RFCs, not just ideas
+* people submit draft PPCs, not just ideas
 * they've actually consulted other people *before* submitting
-* the person submitting the RFC knows that it they don't help, it dies
+* the person submitting the PPC knows that it they don't help, it dies
 * there's a clearer set of requirements needed to progress
 
-## What does the Author do/Where do RFCs live?
+## What does the Author do/Where do PPCs live?
 
-The Author is the champion for the RFC. Their motivation and enthusiasm to have the feature successfully implemented and shipped drives the process.  Their task is to eliminate each "lowest hanging excuse" in turn to get to shipping code. They are responsible for
+The Author is the champion for the PPC. Their motivation and enthusiasm to have the feature successfully implemented and shipped drives the process.  Their task is to eliminate each "lowest hanging excuse" in turn to get to shipping code. They are responsible for
 
 * seeking input
 * shepherding discussion to some sort of consensus (or appealing to the PSC to resolve an impasse)
-* ensuring all sections in the RFC are complete (working with implementers and others as necessary)
+* ensuring all sections in the PPC are complete (working with implementers and others as necessary)
 
-RFCs live in version control. Anyone can create an "Draft" RFC, self-assign it an ID, and start to flesh it out. "Exploratory" status gets you an official RFC ID, and from that point onward the RFC and history is mirrored/merged into the official repository.
+PPCs live in version control. Anyone can create an "Draft" PPC, self-assign it an ID, and start to flesh it out. "Exploratory" status gets you an official PPC ID, and from that point onward the PPC and history is mirrored/merged into the official repository.
 
-To make this workable, the RFC should be in a source code repository that the *Author* can edit directly (GitHub, GitLab, Bitbucket, self-hosted git, etc). The minimal workable requirements are that
+To make this workable, the PPC should be in a source code repository that the *Author* can edit directly (GitHub, GitLab, Bitbucket, self-hosted git, etc). The minimal workable requirements are that
 
 1. it gives a well-known stable URL for the rendered current version
 2. it can tag (or identify) specific previous revisions
 3. history can be mirrored into the official repo, and merged on status change
-4. discussion can be archived once RFC is "Accepted" and "Implemented"
+4. discussion can be archived once PPC is "Accepted" and "Implemented"
 
 Hence GitHub PRs might not be the best forum for discussion, unless they can be archived. Basically we want to avoid the situation were we have a feature live, and some third party can delete the historical discussion related to it.
 
@@ -41,15 +41,15 @@ As we get better at this, I think that the status transitions should aim for the
 
 ## Draft
 
-* *Author* self-assigns RFC ID
+* *Author* self-assigns PPC ID
 * *Author* seeks input/feedback
 
 ## Exploratory
 
 * MUST have *Sponsor* (on the core team, or PSC can delegate externally)
 * MUST have (at least minimal) Motivation, Rational and Examples
 * SHOULD have (at least a minimal) Specification
-* Gets an official RFC ID
+* Gets an official PPC ID
 
 Means "we think this idea is worth exploring"
 
@@ -85,9 +85,9 @@ Means "it's good to merge - we think we can support it in the future"
 
 where (at least) "Provisional" and "Shipped" can be skipped.
 
-## RFC IDs, and how to self-assign
+## PPC IDs, and how to self-assign
 
-* Official RFC IDs are 4 digits
+* Official PPC IDs are 4 digits
 * Self-assigned IDs should be `CPANID-#### or` `githubid-####`
 
 These are the obvious likely popular two, and done case sensitively will not clash. These two should be sufficient for a workable globally unique system.

docs/process.md

@@ -1,4 +1,6 @@
-# Bootstrapping an RFC process
+# Bootstrapping a PPC process
+
+PPC is the acronym for "Perl Proposed Change".
 
 80% of our feature requests are for changes to the language.
 
@@ -19,7 +21,7 @@ Hence we need a process that
 We'd like to record proposals to improve the language and their status as "Request For Comment" documents in their own repository under the Perl organisation on GitHub.
 
 
-We have a [template](template.md) for what an completed implemented RFC should end up as, but if all you have is an idea - don't worry, we'll help you get there.  We're still figuring this process out, so for now we're doing it as mail messages sent to p5p, not as "pull requests" to the RFC repository (or "issues" on the source repository). This way we can see if the process works as hoped, and fix the parts that don't.
+We have a [template](template.md) for what an completed implemented PPC should end up as, but if all you have is an idea - don't worry, we'll help you get there.  We're still figuring this process out, so for now we're doing it as mail messages sent to p5p, not as "pull requests" to the PPC repository (or "issues" on the source repository). This way we can see if the process works as hoped, and fix the parts that don't.
 
 
 ## What makes a good idea?
@@ -40,22 +42,22 @@ Costs are
 * linearly more implementation to maintain
 * exponentially more combinations of features to define and debug
 
-Not every good idea belongs in the Perl core. Some are better implemented on CPAN. For some ideas, the RFC process is overkill. And the other way - for some issues or PRs, the reviewer is going to realise that it's more complex than it seemed, and needs to become an RFC.
+Not every good idea belongs in the Perl core. Some are better implemented on CPAN. For some ideas, the PPC process is overkill. And the other way - for some issues or PRs, the reviewer is going to realise that it's more complex than it seemed, and needs to become a PPC.
 
 ## The Process
 
 ![a flowchart of the process described below](/images/flowchart.png)
 
 
-### Pre-RFC
+### Pre-PPC
 
-The RFC process starts with a formal proposal to add or change a language feature in Perl.  But you, the prospective author of an RFC, shouldn't start by writing that formal proposal.  Start by posting to p5p that you have an idea.  Explain what problem you're solving, how you think you can solve it, and what prior art you looked at.  Be clear and concise.  Make it easy for the rest of the list to see what you're suggesting without reading an enormous wall of text, but don't lose so much detail as to be meaningless.
+The PPC process starts with a formal proposal to add or change a language feature in Perl.  But you, the prospective author of a PPC, shouldn't start by writing that formal proposal.  Start by posting to p5p that you have an idea.  Explain what problem you're solving, how you think you can solve it, and what prior art you looked at.  Be clear and concise.  Make it easy for the rest of the list to see what you're suggesting without reading an enormous wall of text, but don't lose so much detail as to be meaningless.
 
 You are taking the temperature of the list.  If there is a great outcry that this is a bad idea, or has been tried before, or was explicitly rejected before, you should probably stop.  No hard feelings!
 
 Otherwise, you're ready to move on to the next step. You should post a follow-up, requesting that the PSC approve producing a draft.  If they do, move on to "Draft Proposal" below.  If not, they'll provide more feedback like "this is definitely impossible" or "you need to provide more information" or so on.
 
-During this "Pre-RFC" phase, your proposal isn't in the RFC tracker.  It's not an RFC yet!
+During this "Pre-PPC" phase, your proposal isn't in the PPC tracker.  It's not a PPC yet!
 
 During this phase, you (the proposer) are responsible for moving things forward.  If you contact the PSC for approval to file a draft, and the PSC does not respond, it's you who should be keeping track of that.
 
@@ -102,13 +104,13 @@ If no progress is reported for three months, the document moves to **Expired**.
 
 During the Testing phase, the PSC and the proposer (or implementor) will be working together and communicating regularly to keep track of what work remains to complete the testing phase.
 
-## What needs an RFC? What can just be a PR?
+## What needs a PPC? What can just be a PR?
 
-There's no obvious answer, because there's no clear cut off, and there never will be, even when the process is "out of beta". For now we think we should use RFCs for
+There's no obvious answer, because there's no clear cut off, and there never will be, even when the process is "out of beta". For now we think we should use PPCs for
 
 1. Language changes (feature changes to the parser, tokeniser)
 2. Command line options
 3. Adding/removing warnings (entries in `perldiag.pod`)
 4. Significant changes to when an existing warning triggers
 
-A case that came up recently was moving the reporting of an error from runtime to compile time (GH #18785). We think that this wouldn't warrant an RFC (just regular code review) because no correct code should be relying on when an error is reported. However, there is still a judgement call here, as it would **not** be correct for constant folding to report errors (such as divide by zero) as this might only happen on some platforms as a side effect of the values of constants, and those expressions were unreachable on those platforms.
+A case that came up recently was moving the reporting of an error from runtime to compile time (GH #18785). We think that this wouldn't warrant a PPC (just regular code review) because no correct code should be relying on when an error is reported. However, there is still a judgement call here, as it would **not** be correct for constant folding to report errors (such as divide by zero) as this might only happen on some platforms as a side effect of the values of constants, and those expressions were unreachable on those platforms.

docs/template.md

@@ -12,7 +12,7 @@ Author, Sponsor and similar should be valid e-mail addresses, or CPAN IDs.
 
 ## Abstract
 
-* 100 to 200 words summarising the entire RFC.
+* 100 to 200 words summarising the entire PPC.
 * The most important section is **Motivation**.
 
 ## Motivation
@@ -57,7 +57,7 @@ CVEs are not fun. Try to foresee problems.
 
 PEPs have this as "How to Teach This". That's a valid goal, but there are different audiences (from newcomers, to experienced Perl programmers unfamiliar with your plan).
 
-Most of us are not experienced teachers, but many folks reading your RFC are experienced programmers. So probably the best way to demonstrate the benefits of your proposal is to take some existing code in the core or on CPAN (and not your own code) and show how using your new feature can improve it (easier to read, less buggy, etc)
+Most of us are not experienced teachers, but many folks reading your PPC are experienced programmers. So probably the best way to demonstrate the benefits of your proposal is to take some existing code in the core or on CPAN (and not your own code) and show how using your new feature can improve it (easier to read, less buggy, etc)
 
 ## Prototype Implementation
 
@@ -83,7 +83,7 @@ eg *Why not have different behaviour in void context?*
 
 Likely the answer is in the previous discussion **somewhere**, but most people won't stop to read all the comments. It needs to be easy to find, and updated as it becomes clear which questions are common.
 
-Hence it **needs** to be in the RFC itself. Without this, the RFC process as a whole won't scale.
+Hence it **needs** to be in the PPC itself. Without this, the PPC process as a whole won't scale.
 
 ## Open Issues