pod: update a few documents for perlgov changes

(cherry picked from commit 66c65f79d3ac3abda04a869359d6f034ab2c32aa)

4 files changed, 41 insertions, 32 deletions

diff --git a/pod/perlhack.pod b/pod/perlhack.pod
index ba5725992d..8e856cfd4e 100644
--- a/pod/perlhack.pod
+++ b/pod/perlhack.pod
@@ -684,7 +684,7 @@ still options for the future of prototypes that haven't been addressed.
 
 Good patches (tight code, complete, correct) stand more chance of going
 in.  Sloppy or incorrect patches might be placed on the back burner
-until the pumpking has time to fix, or might be discarded altogether
+until fixes can be made, or they might be discarded altogether
 without further notice.
 
 =head3 Is the implementation generic enough to be portable?
@@ -721,7 +721,7 @@ man's pointless cruft.
 
 =head3 Does it create too much work?
 
-Work for the pumpking, work for Perl programmers, work for module
+Work for the committers, work for Perl programmers, work for module
 authors, ... Perl is supposed to be easy.
 
 =head3 Patches speak louder than words
@@ -1162,7 +1162,7 @@ functions do, as well as the many macros used in the source.
 =item * F<Porting/pumpkin.pod>
 
 This is a collection of words of wisdom for a Perl porter; some of it
-is only useful to the pumpkin holder, but most of it applies to anyone
+is only useful to the pumpkin holders, but most of it applies to anyone
 wanting to go about Perl development.
 
 =back
diff --git a/pod/perlhist.pod b/pod/perlhist.pod
index 5b7c2e18c6..091c4e7de4 100644
--- a/pod/perlhist.pod
+++ b/pod/perlhist.pod
@@ -65,8 +65,8 @@ the strings?).
 =head1 THE RECORDS
 
  Pump-  Release         Date            Notes
- king                                   (by no means
-                                         comprehensive,
+ kin                                    (by no means
+ Holder                                  comprehensive,
                                          see Changes*
                                          for details)
  ======================================================================
diff --git a/pod/perlpolicy.pod b/pod/perlpolicy.pod
index 35f2a9a630..ba54b92598 100644
--- a/pod/perlpolicy.pod
+++ b/pod/perlpolicy.pod
@@ -24,22 +24,26 @@ some are actively patching their pet area (threads, Win32, the regexp
 -engine), while others seem to do nothing but complain.  In other
 words, it's your usual mix of technical people.
 
+Among these people are the core Perl team.  These are trusted volunteers
+involved in the ongoing development of the Perl language and interpreter.
+They are not required to be language developers or committers.
+
 Over this group of porters presides Larry Wall.  He has the final word
 in what does and does not change in any of the Perl programming languages.
 These days, Larry spends most of his time on Raku, while Perl 5 is
-shepherded by a "pumpking", a porter responsible for deciding what
+shepherded by a steering council of porters responsible for deciding what
 goes into each release and ensuring that releases happen on a regular
 basis.
 
 Larry sees Perl development along the lines of the US government:
-there's the Legislature (the porters), the Executive branch (the
--pumpking), and the Supreme Court (Larry).  The legislature can
-discuss and submit patches to the executive branch all they like, but
-the executive branch is free to veto them.  Rarely, the Supreme Court
-will side with the executive branch over the legislature, or the
-legislature over the executive branch.  Mostly, however, the
-legislature and the executive branch are supposed to get along and
-work out their differences without impeachment or court cases.
+there's the Legislature (the porters, represented by the core team), the
+Executive branch (the steering council), and the Supreme Court (Larry).
+The legislature can discuss and submit patches to the executive branch
+all they like, but the executive branch is free to veto them.  Rarely,
+the Supreme Court will side with the executive branch over the
+legislature, or the legislature over the executive branch.  Mostly,
+however, the legislature and the executive branch are supposed to get
+along and work out their differences without impeachment or court cases.
 
 You might sometimes see reference to Rule 1 and Rule 2.  Larry's power
 as Supreme Court is expressed in The Rules:
@@ -61,6 +65,10 @@ regardless of whether he previously invoked Rule 1.
 Got that?  Larry is always right, even when he was wrong.  It's rare
 to see either Rule exercised, but they are often alluded to.
 
+For the specifics on how the members of the core team and steering
+council are elected or rotated, consult L<perlgov>, which spells it all
+out in detail.
+
 =head1 MAINTENANCE AND SUPPORT
 
 Perl 5 is developed by a community, not a corporate entity. Every change
@@ -168,7 +176,7 @@ Using a lexical pragma to enable or disable legacy behavior should be
 considered when appropriate, and in the absence of any pragma legacy
 behavior should be enabled.  Which backward-incompatible changes are
 controlled implicitly by a 'use v5.x.y' is a decision which should be
-made by the pumpking in consultation with the community.
+made by the steering council in consultation with the community.
 
 Historically, we've held ourselves to a far higher standard than
 backward-compatibility -- bugward-compatibility.  Any accident of
@@ -263,8 +271,9 @@ perl (e.g. spelling corrections in documentation) should be resisted in order
 to reduce the overall risk of overlooking something.  The intention is to
 create maintenance releases which are both worthwhile and which users can have
 full confidence in the stability of.  (A secondary concern is to avoid burning
-out the maint-pumpking or overwhelming other committers voting on changes to be
-included (see L</"Getting changes into a maint branch"> below).)
+out the maint-release manager or overwhelming other committers voting on
+changes to be included (see L</"Getting changes into a maint branch">
+below).)
 
 The following types of change may be considered acceptable, as long as they do
 not also fall into any of the "unacceptable" categories set out below:
@@ -328,7 +337,8 @@ The following types of change are NOT acceptable:
 
 =item *
 
-Patches that break binary compatibility.  (Please talk to a pumpking.)
+Patches that break binary compatibility.  (Please talk to the steering
+council.)
 
 =item *
 
@@ -356,11 +366,11 @@ be included.
 
 =head2 Getting changes into a maint branch
 
-Historically, only the pumpking cherry-picked changes from bleadperl
-into maintperl.  This has scaling problems.  At the same time,
-maintenance branches of stable versions of Perl need to be treated with
-great care.  To that end, as of Perl 5.12, we have a new process for
-maint branches.
+Historically, only the single-person project manager cherry-picked
+changes from bleadperl into maintperl.  This has scaling problems.  At
+the same time, maintenance branches of stable versions of Perl need to
+be treated with great care.  To that end, as of Perl 5.12, we have a new
+process for maint branches.
 
 Any committer may cherry-pick any commit from blead to a maint branch by
 first adding an entry to the relevant voting file in the maint-votes branch
@@ -383,7 +393,7 @@ interested may be heard.
 
 It is not necessary for voting to be held on cherry-picking perldelta
 entries associated with changes that have already been cherry-picked, nor
-for the maint-pumpking to obtain votes on changes required by the
+for the maint-release manager to obtain votes on changes required by the
 F<Porting/release_managers_guide.pod> where such changes can be applied by
 the means of cherry-picking from blead.
 
@@ -436,7 +446,7 @@ should be respected whenever possible.
 
 =item *
 
-Patches may be applied by the pumpkin holder without the explicit
+Patches may be applied by the steering council without the explicit
 cooperation of the module author if and only if they are very minor,
 time-critical in some fashion (such as urgent security fixes), or if
 the module author cannot be reached.  Those patches must still be
@@ -451,7 +461,7 @@ of the change acknowledged.
 The version of the module distributed with Perl should, whenever
 possible, be the latest version of the module as distributed by the
 author (the latest non-beta version in the case of public Perl
-releases), although the pumpkin holder may hold off on upgrading the
+releases), although the steering council may hold off on upgrading the
 version of the module distributed with Perl to the latest version
 until the latest version has had sufficient testing.
 
@@ -464,10 +474,9 @@ reasonable compromises when there are disagreements).
 
 As a last resort, however:
 
-
 If the author's vision of the future of their module is sufficiently
-different from the vision of the pumpkin holder and perl5-porters as a
-whole so as to cause serious problems for Perl, the pumpkin holder may
+different from the vision of the steering council and perl5-porters as a
+whole so as to cause serious problems for Perl, the steering council may
 choose to formally fork the version of the module in the Perl core from the
 one maintained by the author.  This should not be done lightly and
 should B<always> if at all possible be done only after direct input
diff --git a/pod/perlsecpolicy.pod b/pod/perlsecpolicy.pod
index ad555f074a..07a702495d 100644
--- a/pod/perlsecpolicy.pod
+++ b/pod/perlsecpolicy.pod
@@ -30,7 +30,7 @@ security team.
 You should receive an initial response to your report within 72 hours.
 If you do not receive a response in that time, please contact
 the security team lead L<John Lightsey|mailto:john@04755.net> and
-the Perl pumpking L<SawyerX|mailto:xsawyerx@cpan.org>.
+the L<Perl steering council|mailto:steering-council@perl.org>.
 
 When members of the security team reply to your messages, they will
 generally include the perl-security@perl.org address in the "To" or "CC"
@@ -297,8 +297,8 @@ open and transparent as possible about the state of your security report.
 New vulnerability reports will receive an initial reply within 72 hours
 from the time they arrive at the security team's mailing list. If you do
 not receive any response in that time, contact the security team lead
-L<John Lightsey|mailto:john@04755.net> and the Perl pumpking
-L<SawyerX|mailto:xsawyerx@cpan.org>.
+L<John Lightsey|mailto:john@04755.net> and the the L<Perl steering
+council|mailto:steering-council@perl.org>.
 
 The initial response sent by the security team will confirm your message was
 received and provide an estimated time frame for the security team's