Self-referencing definitions - it's a bit like time travel.
This was originally submitted back in December, but I never saw it show up,
and didn't see it in the archives, so I'm going to throw it to the meta
list for hacking before there are a slew of PDDs floating around.
(I'm withholding the attachment, which is a skeleton PDD.)
=head1 TITLE
Perl Design Documents
=head1 VERSION
=head2 CURRENT
Maintainer: Bryan C. Warnock <[EMAIL PROTECTED]>
Class: Meta
PDD Number: TBD
Version: 2
Status: Proposed
Last Modified: 9 February 2001
PDD Format: 0
Language: English
=head2 HISTORY
v1 created on 7 Dec 2000 by BCWarnock <[EMAIL PROTECTED]>
=head1 CHANGES
Merged I<pddfield.txt> attachment. Reproposed.
=head1 ABSTRACT
This document defines a standard format for documenting Perl
development decisions - the how and why of Perl internals, as well as
the surrounding ethos and culture of the development community. This
document identifies Perl Design Document Format 1.
=head1 DESCRIPTION
One of the shortcomings of most long-term development and maintenance
efforts - and Perl has been no exception - is the lack of readily
available documentation describing the rationale behind many of the
implementation decisions. News archives and mailing archives are
becoming increasingly difficult to find random information in,
particularly with the myriad lists that Perl 6 begot.
Although there will always be decisions which are obvious due to a lack
of alternatives, many design decisions may have multiple technically
feasible solutions. Why X instead of Y? Why this instead of that? Is
the decision based on an obscure bit of technical arcana? Is the
decision based on Perl culture, which itself is a product of many of
the undocumented decisions made before? Or is the decision truly a
toss-up, with a solution picked pseudo-randomly?
A Perl Design Document (PDD) is a readily available record of the Perl
community's thought process in regards to a specific structure related
to Perl development. As such, it serves three major purposes.
=over 4
=item 1
A clear indication of the direction of current development. A PDD
provides a road map from abstraction to implementation of an idea.
=item 2
An historical record of the rationale behind the decision. A PDD
provides context to future developers, who may not have been familiar
with the original discussion, but are currently involved with the
resultant implementation.
=item 3
An historical technical and cultural perspective for future development
work. Re-implementation or even tangential tasks need only address what
has changed since the original PDD.
=back
It is not a vehicle for brainstorming or creating a wish-list. PDDs
are reserved for a concrete snapshot of what B<is>, and what B<will>
be.
=head1 IMPLEMENTATION
All newly created PDDs will adhere to the PDD standard current as of
the time of proposal. In the absence of an accepted standard, the PDD
will be written in the last generally accepted format, and will
indicate the S<I<PDD Format>> as 0. (See L<VERSION|"VERSION:">.)
All existing PDDs will adhere to the PDD standard current as of the
time of resubmission. Existing PDDs need not be modified and
resubmitted B<solely> for the purpose of adhering to a PDD format
change.
=head2 FORMAT
All PDDs will be written in POD parseable by the current stable release
of Perl. Although XML is a viable solution and has its vocal
supporters within the Perl community, POD is still the traditional
documentation language for All Things Perl, and PDDs have yet to reach
the level of complexity that requires some of XML's more powerful
capabilities, particularly at a trade-off to the legibility of POD's
simplicity.
All PDDs will be written in English. British, American, or Other is
the choice of the author. Translation to other languages, like all
Perl documentation, is encouraged. (See S<L<"PDD TRANSLATIONS">>.)
All PDDs will contain the following information:
=over 4
=item TITLE:
A short, general description of a specific area within Perl. For
instance, "Sorting" vice "Sorting with a Heap Sort".
PDDs should be limited to a specific area of Perl - in the above case,
sorting - but should be broad enough to include the reasons for and
against any specific implementation that may be discussed. Historical
perspectives can be contrasted and compared through archived versions
of a PDD, vice multiple searches through archived versions of I<n>
number of PDDs.
=item VERSION:
Contains current and selected historical metadata on the PDD itself.
=over 4
=item CURRENT:
Contains the following information, current as of the date of
submission.
=over 4
=item Maintainer
Required. The name and current email address for the POC of the PDD.
This is to whom questions, comments, and patches are generally
addressed.
=item Class
Required. The area of Perl the PDD covers. This allows related PDDs
to be logically grouped. The current list of valid classes roughly
mirror the Perl 6 mailing lists, and are:
Documentation - on perl documentation.
Meta - on Perl as an entity.
Internals - on the internals of perl components.
Testing - on the testing of perl.
PDDs should be scoped to their lowest level.
=item PDD Number
Required. Newly created PDDs should have a PDD Number of I<TBD>. PDD
Numbers will be assigned by the Perl Librarian, based on the following
scheme:
=over 4
=item *
C<Informational> PDDs are given a PDD Number of C<I#>, where C<#> is a
one-up integer based on order of release by the Perl Librarian.
=item *
C<Experimental> PDDs are given a PDD Number of C<X#>, where C<#> is a
one-up integer based on order of release by the Perl Librarian.
=item *
C<Proposed> PDDs are B<not> given a PDD Number. They are given an
unprefixed one-up integer when promoted to C<Developing>.
=back
Since C<Informational> and C<Experimental> PDDs don't require the same
approval process as C<Standard>-track PDDs, their PDD Number should
readily reflect their purpose. Since C<Proposed> PDDs may be delayed
or prevented from reaching an inclusive status, withholding a PDD
Number can prevent gaps from the PDD Number sequence.
=item Version
Required. A one-up integer reflecting each public revision of a PDD.
=item Status
Required. The current state of the PDD. Currently, there are three
tracks of PDD, C<Informational>, C<Experimental>, and C<Standard>.
Each track has its own list of states, which are:
=over 4
=item INFORMATIONAL TRACK
=over 4
=item Informational
For general consumption. Perl History, for example, would be
informational.
=item Superceded by PDD #
Replaced in whole by another PDD.
=item Obsolete
Naturally obsolete.
=back
=item EXPERIMENTAL TRACK
=over 4
=item Experimental
Documentation on an experimental feature or use of Perl, such as
porting Perl to a PS2.
=item Superceded by PDD #
Replaced in whole by another PDD.
=item Obsolete
Naturally obsolete.
=back
=item STANDARD TRACK
=over 4
=item Proposed
A rough draft submitted for consideration from the Perl development
community at large. A snapshot of the general discussion
surrounding issue foo, but may not accurately reflect the true
direction the community wishes to go.
=item Developing
An acceptable (at least, on theory) PDD that needs much further
fleshing out and fine tuning. The PDD, as well as the
implementation it describes are both under official development by
the Perl development community.
=item Standard
A frozen snapshot of the issue, as it applies to Perl at the time of
acceptance.
=item Superseded by PDD #
Replaced in whole by another PDD.
=item Obsolete
Naturally obsolete.
=back
=back
PDDs that switch tracks will always begin at the first stage of the
track.
=item Last Modified
Required. The date of the last submission.
=item PDD Format
Required. The specific format the PDD adheres to. This allows scripts
to better parse PDDs of multiple aging formats.
=item Language
Optional. The language the PDD is written in.
=back
=item HISTORY:
A list of free-flow descriptions of significant metadata changes, such
as status changes, or change of maintainers. Each entry should include
the version, date, and nature of the change. This provides a quick
historical glimpse to the major metadata changes of a PDD.
=back
=item CHANGES:
A summary of the changes since the last version. A comprehensive
change log should be kept, but only within a supporting document.
=item ABSTRACT:
A quick blurb explaining the purpose of the PDD.
=item DESCRIPTION:
A description of the general nature of the PDD and how it relates to
Perl.
=item IMPLEMENTATION:
A major section of the PDD that encapsulates a free-form discussion of
any and all applicable information related to the final observations,
conclusions, and what-have-you that required writing the document in
the first place.
=item ATTACHMENTS:
References to supporting files that should be considered part of the
PDD. Text files and image files may be in any widely accepted format,
which is rather subjective. Violators may be prosecuted.
Text files and image files should only provide supplemental
information; no fair hiding all the info in an attachment just to not
have to write an implementation section.
=item REFERENCES:
References to additional sources of information, but not those
necessary for the PDD itself.
=back
The PDD author may add any additional sections he or she wishes.
=head2 SUBMISSION CRITERIA
It is expected that all PDDs submitted as a proposal will have
undergone an actual discussion within the applicable group(s).
Following a general consensus of the need for a PDD (and, hopefully, a
general consensus on the particular slant of a PDD proposal), the PDD
can be submitted to the Perl Librarian.
The Perl Librarian should check the document for format, and either
return to the PDD to the maintainer for correction, or publish the PDD
- whatever that actually entails. (Mailing lists, web site, etc.)
C<Informational> and C<Experimental> PDDs may be submitted on a whim,
but otherwise require the same submittal process as regular PDDs.
=head2 PDD TRANSLATIONS
Should a PDD be translated into another language, the following
guidelines should be met.
=over 4
=item *
The C<Maintainer> field should reflect who did the translation.
=item *
The C<Version> number should match the original document's C<Version>
number. Should multiple translated versions of a single original PDD
be done (to correct spellings, etc), the revision specific to that
document version should be included in parentheses following the
version number.
=item *
Attributions in the C<HISTORY> section should be left alone.
=back
=head2 PDD STATUS CHANGES
Only Larry, a project leader, pumpking, or working group chair may set
C<Status> to anything other than C<Proposed>, C<Informational>, or
C<Experimental>.
=head2 AVAILABILITY
All C<Proposed>, C<Informational>, and C<Experimental> PDDs should be
readily available, in a centralized location, to at least the current
Perl development circles. All C<Standard>-track PDDs should be
readily available, in a centralized location, to the general public.
All C<Superseded> PDDs should be available upon request. All
historical versions of PDDs should be available upon request.
=head1 ATTACHMENTS
A. F<pddtempl.pod>
=head1 REFERENCES
Dan Sugalski's original PDD guidelines at
http://www.mail-archive.com/perl6-internals@perl.org/msg01766.html
--
Bryan C. Warnock
[EMAIL PROTECTED]
