+=head1 GOVERNANCE
+
+=head2 Perl 5 Porters
+
+Subscribers to perl5-porters (the porters themselves) come in several flavours.
+Some are quiet curious lurkers, who rarely pitch in and instead watch
+the ongoing development to ensure they're forewarned of new changes or
+features in Perl. Some are representatives of vendors, who are there
+to make sure that Perl continues to compile and work on their
+platforms. Some patch any reported bug that they know how to fix,
+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.
+
+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 Perl 6, while Perl 5 is
+shepherded by a "pumpking", a porter 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.
+
+You might sometimes see reference to Rule 1 and Rule 2. Larry's power
+as Supreme Court is expressed in The Rules:
+
+=over 4
+
+=item 1
+
+Larry is always by definition right about how Perl should behave.
+This means he has final veto power on the core functionality.
+
+=item 2
+
+Larry is allowed to change his mind about any matter at a later date,
+regardless of whether he previously invoked Rule 1.
+
+=back
+
+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.
+
+=head1 MAINTENANCE AND SUPPORT
+
+Perl 5 is developed by a community, not a corporate entity. Every change
+contributed to the Perl core is the result of a donation. Typically, these
+donations are contributions of code or time by individual members of our
+community. On occasion, these donations come in the form of corporate
+or organizational sponsorship of a particular individual or project.
+
+As a volunteer organization, the commitments we make are heavily dependent
+on the goodwill and hard work of individuals who have no obligation to
+contribute to Perl.
+
+That being said, we value Perl's stability and security and have long
+had an unwritten covenant with the broader Perl community to support
+and maintain releases of Perl.
+
+This document codifies the support and maintenance commitments that
+the Perl community should expect from Perl's developers:
+
+=over
+
+=item *
+
+We "officially" support the two most recent stable release series. 5.14.x
+and earlier are now out of support. As of the release of 5.20.0, we will
+"officially" end support for Perl 5.16.x, other than providing security
+updates as described below.
+
+=item *
+
+To the best of our ability, we will attempt to fix critical issues
+in the two most recent stable 5.x release series. Fixes for the
+current release series take precedence over fixes for the previous
+release series.
+
+=item *
+
+To the best of our ability, we will provide "critical" security patches
+/ releases for any major version of Perl whose 5.x.0 release was within
+the past three years. We can only commit to providing these for the
+most recent .y release in any 5.x.y series.
+
+=item *
+
+We will not provide security updates or bug fixes for development
+releases of Perl.
+
+=item *
+
+We encourage vendors to ship the most recent supported release of
+Perl at the time of their code freeze.
+
+=item *
+
+As a vendor, you may have a requirement to backport security fixes
+beyond our 3 year support commitment. We can provide limited support and
+advice to you as you do so and, where possible will try to apply
+those patches to the relevant -maint branches in git, though we may or
+may not choose to make numbered releases or "official" patches
+available. Contact us at E<lt>perl5-security-report@perl.orgE<gt>
+to begin that process.
+
+=back
+
+=head1 BACKWARD COMPATIBILITY AND DEPRECATION
+
+Our community has a long-held belief that backward-compatibility is a
+virtue, even when the functionality in question is a design flaw.
+
+We would all love to unmake some mistakes we've made over the past
+decades. Living with every design error we've ever made can lead
+to painful stagnation. Unwinding our mistakes is very, very
+difficult. Doing so without actively harming our users is
+nearly impossible.
+
+Lately, ignoring or actively opposing compatibility with earlier versions
+of Perl has come into vogue. Sometimes, a change is proposed which
+wants to usurp syntax which previously had another meaning. Sometimes,
+a change wants to improve previously-crazy semantics.
+
+Down this road lies madness.
+
+Requiring end-user programmers to change just a few language constructs,
+even language constructs which no well-educated developer would ever
+intentionally use is tantamount to saying "you should not upgrade to
+a new release of Perl unless you have 100% test coverage and can do a
+full manual audit of your codebase." If we were to have tools capable of
+reliably upgrading Perl source code from one version of Perl to another,
+this concern could be significantly mitigated.
+
+We want to ensure that Perl continues to grow and flourish in the coming
+years and decades, but not at the expense of our user community.
+
+Existing syntax and semantics should only be marked for destruction in
+very limited circumstances. If they can be easily replaced, are
+believed to be very rarely used, and stand in the way of actual
+improvement to the Perl language or perl interpreter, they may be
+considered for removal. If both the cost and the gain are believed to
+be low, backward compatibility wins. When a feature is deprecated, a
+statement of reasoning describing the decision process will be posted,
+and a link to it will be provided in the relevant perldelta documents.
+
+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.
+
+Historically, we've held ourselves to a far higher standard than
+backward-compatibility -- bugward-compatibility. Any accident of
+implementation or unintentional side-effect of running some bit of code
+has been considered to be a feature of the language to be defended with
+the same zeal as any other feature or functionality. No matter how
+frustrating these unintentional features may be to us as we continue
+to improve Perl, these unintentional features often deserve our
+protection. It is very important that existing software written in
+Perl continue to work correctly. If end-user developers have adopted a
+bug as a feature, we need to treat it as such.
+
+New syntax and semantics which don't break existing language constructs
+and syntax have a much lower bar. They merely need to prove themselves
+to be useful, elegant, well designed, and well tested. In most cases,
+these additions will be marked as I<experimental> for some time. See
+below for more on that.
+
+=head2 Terminology
+
+To make sure we're talking about the same thing when we discuss the removal
+of features or functionality from the Perl core, we have specific definitions
+for a few words and phrases.
+
+=over
+
+=item experimental
+
+If something in the Perl core is marked as B<experimental>, we may change
+its behaviour, deprecate or remove it without notice. While we'll always
+do our best to smooth the transition path for users of experimental
+features, you should contact the perl5-porters mailinglist if you find
+an experimental feature useful and want to help shape its future.
+
+Experimental features must be experimental in two stable releases before being
+marked non-experimental. Experimental features will only have their
+experimental status revoked when they no longer have any design-changing bugs
+open against them and when they have remained unchanged in behavior for the
+entire length of a development cycle. In other words, a feature present in
+v5.20.0 may be marked no longer experimental in v5.22.0 if and only if its
+behavior is unchanged throughout all of v5.21.
+
+=item deprecated
+
+If something in the Perl core is marked as B<deprecated>, we may remove it
+from the core in the future, though we might not. Generally, backward
+incompatible changes will have deprecation warnings for two release
+cycles before being removed, but may be removed after just one cycle if
+the risk seems quite low or the benefits quite high.
+
+As of
+Perl 5.12, deprecated features and modules warn the user as they're used.
+When a module is deprecated, it will also be made available on CPAN.
+Installing it from CPAN will silence deprecation warnings for that module.
+
+If you use a deprecated feature or module and believe that its removal from
+the Perl core would be a mistake, please contact the perl5-porters
+mailinglist and plead your case. We don't deprecate things without a good
+reason, but sometimes there's a counterargument we haven't considered.
+Historically, we did not distinguish between "deprecated" and "discouraged"
+features.
+
+=item discouraged
+
+From time to time, we may mark language constructs and features which we
+consider to have been mistakes as B<discouraged>. Discouraged features
+aren't currently candidates for removal, but
+we may later deprecate them if they're found to stand in the way of a
+significant improvement to the Perl core.
+
+=item removed
+
+Once a feature, construct or module has been marked as deprecated, we
+may remove it from the Perl core. Unsurprisingly,
+we say we've B<removed> these things. When a module is removed, it will
+no longer ship with Perl, but will continue to be available on CPAN.
+
+=back
+
+=head1 MAINTENANCE BRANCHES
+
+=over
+
+=item *
+
+New releases of maint should contain as few changes as possible.
+If there is any question about whether a given patch might merit
+inclusion in a maint release, then it almost certainly should not
+be included.
+
+=item *
+
+Portability fixes, such as changes to Configure and the files in
+hints/ are acceptable. Ports of Perl to a new platform, architecture
+or OS release that involve changes to the implementation are NOT
+acceptable.
+
+=item *
+
+Acceptable documentation updates are those that correct factual errors,
+explain significant bugs or deficiencies in the current implementation,
+or fix broken markup.
+
+=item *
+
+Patches that add new warnings or errors or deprecate features
+are not acceptable.
+
+=item *
+
+Patches that fix crashing bugs, assertion failures and
+memory corruption that do not otherwise change Perl's
+functionality or negatively impact performance are acceptable.
+
+=item *
+
+Patches that fix CVEs or security issues are acceptable, but should
+be run through the perl5-security-report@perl.org mailing list
+rather than applied directly.
+
+=item *
+
+Patches that fix regressions in perl's behavior relative to previous
+releases are acceptable.
+
+=item *
+
+Updates to dual-life modules should consist of minimal patches to
+fix crashing or security issues (as above).
+
+=item *
+
+Minimal patches that fix platform-specific test failures or build or
+installation issues are acceptable. When these changes are made
+to dual-life modules for which CPAN is canonical, any changes
+should be coordinated with the upstream author.
+
+=item *
+
+New versions of dual-life modules should NOT be imported into maint.
+Those belong in the next stable series.