-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathsep-0001.html
455 lines (446 loc) · 26.4 KB
/
sep-0001.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
<!--
This HTML is auto-generated. DO NOT EDIT THIS FILE!
DO NOT USE THIS HTML FILE AS YOUR TEMPLATE!
-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="generator" content="Docutils 0.8.1: http://docutils.sourceforge.net/" />
<meta http-equiv="Content-Type" content="text/html;charset=utf-8">
<meta name="robots" content="index,follow">
<title>SEP 1 -- SEP Purpose and Guidelines</title>
<link rel="stylesheet" type="text/css" charset="utf-8" media="all" href="common.css"/>
<link rel="stylesheet" href="sep.css" type="text/css" />
</head>
<body lang="en" dir="ltr">
<div id="dpage">
<div id="dpage-inner">
<div id="header">
</div> <!-- /#header -->
<div style="margin-left: 10px;">
<p>
[<b><a href="http://AuburnSPaRC.github.com/SEP/sep-0000.html">SEP Index</a></b>]
[<b><a href="https://github.com/AuburnSPaRC/SEP/blob/master/sep-0001.txt">SEP Source</a></b>]
</p>
<div>
<table class="rfc2822 docutils field-list" frame="void" rules="none">
<col class="field-name" />
<col class="field-body" />
<tbody valign="top">
<tr class="field"><th class="field-name">SEP:</th><td class="field-body">1</td>
</tr>
<tr class="field"><th class="field-name">Title:</th><td class="field-body">SEP Purpose and Guidelines</td>
</tr>
<tr class="field"><th class="field-name">Version:</th><td class="field-body">5ef736d43c3e266046837a674d77d3a29b78fdfb</td>
</tr>
<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference external" href="https://github.com/AuburnSPaRC/SEP/blob/master/sep-0001.txt"> Tue Apr 17 10:37:52 2012 -0500</a></td>
</tr>
<tr class="field"><th class="field-name">Author:</th><td class="field-body">Michael Carroll <mjcarroll at ieee.org></td>
</tr>
<tr class="field"><th class="field-name">Status:</th><td class="field-body">Active</td>
</tr>
<tr class="field"><th class="field-name">Type:</th><td class="field-body">Process</td>
</tr>
<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference external" href="https://AuburnSPaRC.github.com/SEP/sep-0012">text/x-rst</a></td>
</tr>
<tr class="field"><th class="field-name">Created:</th><td class="field-body">18-Sep-2010</td>
</tr>
<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">19-Sep-2010, 20-Feb-2012</td>
</tr>
</tbody>
</table>
<hr />
<div class="contents topic" id="contents">
<p class="topic-title first">Contents</p>
<ul class="simple">
<li><a class="reference internal" href="#what-is-a-sep" id="id16">What is a SEP?</a></li>
<li><a class="reference internal" href="#sep-types" id="id17">SEP Types</a></li>
<li><a class="reference internal" href="#sep-work-flow" id="id18">SEP Work Flow</a></li>
<li><a class="reference internal" href="#what-belongs-in-a-successful-sep" id="id19">What belongs in a successful SEP?</a></li>
<li><a class="reference internal" href="#sep-formats-and-templates" id="id20">SEP Formats and Templates</a></li>
<li><a class="reference internal" href="#sep-header-preamble" id="id21">SEP Header Preamble</a></li>
<li><a class="reference internal" href="#auxiliary-files" id="id22">Auxiliary Files</a></li>
<li><a class="reference internal" href="#reporting-sep-bugs-or-submitting-sep-updates" id="id23">Reporting SEP Bugs, or Submitting SEP Updates</a></li>
<li><a class="reference internal" href="#transferring-sep-ownership" id="id24">Transferring SEP Ownership</a></li>
<li><a class="reference internal" href="#sep-editor-responsibilities-workflow" id="id25">SEP Editor Responsibilities & Workflow</a></li>
<li><a class="reference internal" href="#references-and-footnotes" id="id26">References and Footnotes</a></li>
</ul>
</div>
<div class="section" id="what-is-a-sep">
<h1><a class="toc-backref" href="#id16">What is a SEP?</a></h1>
<p>SEP stands for SPaRC Enhancement Proposal. A SEP is a design
document providing information to the SPaRC team, or describing
a new feature for SPaRC or its processes or environment. The SEP
should provide a concise technical specification of the feature and a
rationale for the feature.</p>
<p>We intend SEPs to be the primary mechanisms for proposing new
processes, for collecting team input on an issue, and for
documenting the decisions that have gone into SPaRC. The SEP
author is responsible for building consensus within the team and
documenting dissenting opinions.</p>
<p>Because the SEPs are maintained as text files in a versioned
repository, their revision history is the historical record of the
proposal <a class="footnote-reference" href="#id4" id="id1">[1]</a>.</p>
<p>The SEP process is based on the Python PEP process. We are thankful to
the Python PEP contributors for providing a process, tools, and
templates for community participation in a design process. Additionally,
we are thankful to the ROS REP contributors for extending this process
for robotics.</p>
<p>This initial document is based on a search-and-replace of PEP 1 by
Barry Warsaw, Jeremy Hylton, David Goodger. Over time, it will
incorporate SPaRC-specific changes to this process. The Author field of
this document has been changed in order to denote seponsibility for
maintenance, not credit for original authorship.</p>
</div>
<div class="section" id="sep-types">
<h1><a class="toc-backref" href="#id17">SEP Types</a></h1>
<p>There are three kinds of SEP:</p>
<ol class="arabic simple">
<li>A <strong>Rules</strong> SEP describes a set of rules or modifications to bylaws
governing the SPaRC program.</li>
<li>An <strong>Informational</strong> SEP describes a SPaRC design issue, or
provides general guidelines or information to the SPaRC team,
but does not necessarily represent a rule or bylaw. Informational
SEPs do not necessarily represent a SPaRC team consensus or
recommendation, so members are free to ignore Informational SEPs
or follow their advice.</li>
<li>A <strong>Process</strong> SEP describes a process surrounding SPaRC, or
proposes a change to (or an event in) a process. Process SEPs are
like Rules SEPs but apply to areas other than the SPaRC
program itself. They often require community consensus; unlike
Informational SEPs, they are more than recommendations, and members
are typically not free to ignore them. Examples include
procedures, guidelines, changes to the decision-making process, and
changes to the tools or environment used in SPaRC development.
Any meta-SEP is also considered a Process SEP.</li>
</ol>
</div>
<div class="section" id="sep-work-flow">
<h1><a class="toc-backref" href="#id18">SEP Work Flow</a></h1>
<p>The SEP editors assign SEP numbers and change their status. Please send
all SEP-related email to <<a class="reference external" href="mailto:ausparc@googlegroups.com">ausparc@googlegroups.com</a>> (no cross-posting please).
Also see <a class="reference internal" href="#sep-editor-responsibilities-workflow">SEP Editor Responsibilities & Workflow</a> below.</p>
<p>The SEP process begins with a new idea for SPaRC. It is highly
recommended that a single SEP contain a single key proposal or new
idea. Small enhancements or patches often don't need a SEP and can be
injected into the SPaRC development work flow with a submission to
the SPaRC <a class="reference external" href="http://github.com/AuburnSPaRC">issue tracker</a> <a class="footnote-reference" href="#id6" id="id7">[3]</a>. The more focussed the SEP, the more
successful it tends to be. The SEP editor reserves the
right to reject SEP proposals if they appear too unfocussed or too
broad. If in doubt, split your SEP into several well-focussed ones.</p>
<p>Each SEP must have a champion -- someone who writes the SEP using the
style and format described below, shepherds the discussions in the
appropriate forums, and attempts to build community consensus around
the idea. The SEP champion (a.k.a. Author) should first attempt to
ascertain whether the idea is SEP-able. Posting to the ausparc list
is the best way to go about this.</p>
<p>Vetting an idea publicly before going as far as writing a SEP is meant
to save the potential author time. Many ideas have been brought
forward for changing SPaRC that have been rejected for various
reasons. Asking the SPaRC team first if an idea is original
helps prevent too much time being spent on something that is
guaranteed to be rejected based on prior discussions (searching
the internet does not always do the trick). It also helps to make sure
the idea is applicable to the entire community and not just the author.
Just because an idea sounds good to the author does not
mean it will work for most people in most areas where SPaRC is used.</p>
<p>Once the champion has asked the SPaRC community as to whether an idea
has any chance of acceptance, a draft SEP should be presented to
<<a class="reference external" href="mailto:ausparc@googlegroups.com">ausparc@googlegroups.com</a>>. This gives the author a chance to flesh
out the draft SEP to make properly formatted, of high quality, and
to address initial concerns about the proposal. It is appropriate to
place the draft version of the SEP in the 'master' branch of the
SEP repository on Github. Please assign a temporary name to your SEP,
the final number is to be assigned by the SEP editors.</p>
<p>Following a discussion on the <<a class="reference external" href="mailto:ausparc@googlegroups.com">ausparc@googlegroups.com</a>>, the draft
SEP should be presented to the list again. The draft must be written
in SEP style as described below, or else it will be sent back without
further regard until proper formatting rules are followed.</p>
<p>If the SEP editor approves, he will assign the SEP a number, label it
as Rules, Informational, or Process, give it status "Draft",
and create and check-in the initial draft of the SEP. The SEP editor
will not unreasonably deny a SEP. Reasons for denying SEP status
include duplication of effort, being technically unsound, not
providing proper motivation or addressing backwards compatibility, or
not in keeping with the SPaRC philosophy. The MDFN (Malevolent Dictator
for Now, TBD) can be consulted during the approval phase, and is the
final arbiter of the draft's SEP-ability.</p>
<p>As updates are necessary, the SEP author can check in new versions,
or can email new SEP versions to the SEP editor for committing.</p>
<p>SEP authors are responsible for collecting community feedback on a SEP
before submitting it for review. However, wherever possible, long
open-ended discussions on public mailing lists (or in meetings)
should be avoided. Strategies to keep the discussions efficient
include: setting up a separate SIG mailing list for the topic,
having the SEP author accept private comments in the early design
phases, setting up a wiki page, etc. SEP authors should use their
discretion here.</p>
<p>Once the authors have completed a SEP, they must inform the SEP editor
that it is ready for review. SEPs are reviewed by the MDFN and his
chosen consultants, who may accept or reject a SEP or send it back to
the author(s) for revision. For a SEP that is pre-determined to be
acceptable (e.g., it is an obvious win as-is and/or its implementation
has already been checked in) the MDFN may also initiate a SEP review,
first notifying the SEP author(s) and giving them a chance to make
revisions.</p>
<p>For a SEP to be accepted it must meet certain minimum criteria. It
must be a clear and complete description of the proposed enhancement.
The enhancement must sepresent a net improvement. The proposed
implementation, if applicable, must be solid and must not complicate
existing libraries unduly. Finally, a proposed enhancement must be
"SPaRC-ish". (However, "SPaRC-ish" is an imprecise term; it may be
defined as whatever is acceptable to SPaRC members. This logic is
intentionally circular.)</p>
<p>Once a SEP has been accepted, and approved by the SPaRC team,
the status will be changed to "Final".</p>
<p>A SEP can also be assigned status "Deferred". The SEP author or
editor can assign the SEP this status when no progress is being made
on the SEP. Once a SEP is deferred, the SEP editor can re-assign it
to draft status.</p>
<p>A SEP can also be "Rejected". Perhaps after all is said and done it
was not a good idea. It is still important to have a record of this
fact.</p>
<p>SEPs can also be replaced by a different SEP, rendering the original
obsolete. This is intended for Informational SEPs, where version 2 of
an idea can replace version 1.</p>
<p>The possible paths of the status of SEPs are as follows:</p>
<img alt="sep-0001-1.png" src="sep-0001-1.png" />
<p>Some Informational and Process SEPs may also have a status of "Active"
if they are never meant to be completed. E.g. SEP 1 (this SEP).</p>
</div>
<div class="section" id="what-belongs-in-a-successful-sep">
<h1><a class="toc-backref" href="#id19">What belongs in a successful SEP?</a></h1>
<p>Each SEP should have the following parts:</p>
<ol class="arabic">
<li><p class="first">Preamble -- <a class="reference external" href="http://www.faqs.org/rfcs/rfc822.html">RFC 822</a> style headers containing meta-data about the
SEP, including the SEP number, a short descriptive title (limited
to a maximum of 44 characters), the names, and optionally the
contact info for each author, etc.</p>
</li>
<li><p class="first">Abstract -- a short (~200 word) description of the technical issue
being addressed.</p>
</li>
<li><p class="first">Copyright/public domain -- Each SEP must either be explicitly
labelled as placed in the public domain (see this SEP as an
example) or licensed under the <a class="reference external" href="http://www.opencontent.org/openpub/">Open Publication License</a> <a class="footnote-reference" href="#id9" id="id10">[4]</a>.</p>
</li>
<li><p class="first">Specification -- The technical specification should describe the
syntax and semantics of any new feature or process. This should be
complete enough that new members can gain deep technical knowledge on
the SPaRC program quickly.</p>
</li>
<li><p class="first">Motivation -- The motivation is critical for SEPs that want to
change the SPaRC rules or processes. It should clearly explain
why the existing rule or process is inadequate to address the problem that
the SEP solves. SEP submissions without sufficient motivation may
be rejected outright.</p>
</li>
<li><p class="first">Rationale -- The rationale fleshes out the specification by
describing what motivated the design and why particular design
decisions were made. It should describe alternate designs that
were considered and related work, e.g. how the feature is supported
in other languages.</p>
<p>The rationale should provide evidence of consensus within the
community and discuss important objections or concerns raised
during discussion.</p>
</li>
</ol>
</div>
<div class="section" id="sep-formats-and-templates">
<h1><a class="toc-backref" href="#id20">SEP Formats and Templates</a></h1>
<p>All SEP are expected to be formatted in <a class="reference external" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> <a class="footnote-reference" href="#id11" id="id12">[5]</a> with
UTF-8-encoding. <a class="reference external" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> <a class="footnote-reference" href="#id11" id="id13">[5]</a> SEPs allow for rich markup that is
still quite easy to read. SEP 12 contains instructions and a template
<a class="footnote-reference" href="#id5" id="id2">[2]</a> for reStructuredText.</p>
<p>There is a Python script that converts SEPs to HTML for viewing on the
web. reStructuredText SEPs are parsed and converted by <a class="reference external" href="http://docutils.sourceforge.net/">Docutils</a> <a class="footnote-reference" href="#id14" id="id15">[6]</a> code
called from the script.</p>
</div>
<div class="section" id="sep-header-preamble">
<h1><a class="toc-backref" href="#id21">SEP Header Preamble</a></h1>
<p>Each SEP must begin with an <a class="reference external" href="http://www.faqs.org/rfcs/rfc822.html">RFC 822</a> style header preamble. The headers
must appear in the following order. Headers marked with "*" are
optional and are described below. All other headers are required.</p>
<pre class="literal-block">
SEP: <sep number>
Title: <sep title>
Version: <svn version string>
Last-Modified: <svn date string>
Author: <list of authors' real names and optionally, email addrs>
* Discussions-To: <email address>
Status: <Draft | Active | Accepted | Deferred | Rejected |
Withdrawn | Final | Replaced>
Type: <Rules | Informational | Process>
* Content-Type: <text/plain | text/x-rst>
* Requires: <sep numbers>
Created: <date created on, in dd-mmm-yyyy format>
Post-History: <dates of postings to ausparc>
* Replaces: <sep number>
* Replaced-By: <sep number>
</pre>
<p>The Author header lists the names, and optionally the email addresses
of all the authors/owners of the SEP. The format of the Author header
value must be</p>
<blockquote>
Random J. User <<a class="reference external" href="mailto:address@dom.ain">address@dom.ain</a>></blockquote>
<p>if the email address is included, and just</p>
<blockquote>
Random J. User</blockquote>
<p>if the address is not given. For historical reasons the format
"<a class="reference external" href="mailto:address@dom.ain">address@dom.ain</a> (Random J. User)" may appear in a SEP, however new
SEPs must use the mandated format above, and it is acceptable to
change to this format when SEPs are updated.</p>
<p>If there are multiple authors, each should be on a separate line
following <a class="reference external" href="http://www.faqs.org/rfcs/rfc2822.html">RFC 2822</a> continuation line conventions. Note that personal
email addresses in SEPs will be obscured as a defense against spam
harvesters.</p>
<p>While a SEP is in private discussions (usually during the initial
Draft phase), a Discussions-To header will indicate the mailing list
or URL where the SEP is being discussed. No Discussions-To header is
necessary if the SEP is being discussed privately with the author, or
on the ausparc email mailing lists. Note that email addresses in
the Discussions-To header will not be obscured.</p>
<p>The Type header specifies the type of SEP: Rules,
Informational, or Process.</p>
<p>The format of a SEP is specified with a Content-Type header. The only
supported values is "text/x-rst", which designates reStructuredText
encoding (see SEP 12 <a class="footnote-reference" href="#id5" id="id3">[2]</a>).</p>
<p>The Created header records the date that the SEP was assigned a
number, while Post-History is used to record the dates of when new
versions of the SEP are posted to ausparc. Both headers should be
in dd-mmm-yyyy format, e.g. 14-Aug-2010.</p>
<p>SEPs may have a Requires header, indicating the SEP numbers that this
SEP depends on.</p>
<p>SEPs may also have a Replaced-By header indicating that a SEP has been
rendered obsolete by a later document; the value is the number of the
SEP that replaces the current document. The newer SEP must have a
Replaces header containing the number of the SEP that it rendered
obsolete.</p>
</div>
<div class="section" id="auxiliary-files">
<h1><a class="toc-backref" href="#id22">Auxiliary Files</a></h1>
<p>SEPs may include auxiliary files such as diagrams. Such files must be
named <tt class="docutils literal"><span class="pre">sep-XXXX-Y.ext</span></tt>, where "XXXX" is the SEP number, "Y" is a
serial number (starting at 1), and "ext" is replaced by the actual
file extension (e.g. "png").</p>
</div>
<div class="section" id="reporting-sep-bugs-or-submitting-sep-updates">
<h1><a class="toc-backref" href="#id23">Reporting SEP Bugs, or Submitting SEP Updates</a></h1>
<p>How you seport a bug, or submit a SEP update depends on several
factors, such as the maturity of the SEP, the preferences of the SEP
author, and the nature of your comments. For the early draft stages
of the SEP, it's probably best to send your comments and changes
directly to the SEP author. For more mature, or finished SEPs you may
want to submit corrections to the SPaRC <a class="reference external" href="http://github.com/AuburnSPaRC">issue tracker</a> <a class="footnote-reference" href="#id6" id="id8">[3]</a> so that your
changes don't get lost. If the SEP author is a SPaRC developer, assign the
bug/patch to him, otherwise assign it to the SEP editor.</p>
<p>When in doubt about where to send your changes, please check first
with the SEP author and/or SEP editor.</p>
</div>
<div class="section" id="transferring-sep-ownership">
<h1><a class="toc-backref" href="#id24">Transferring SEP Ownership</a></h1>
<p>It occasionally becomes necessary to transfer ownership of SEPs to a
new champion. In general, we'd like to retain the original author as
a co-author of the transferred SEP, but that's really up to the
original author. A good reason to transfer ownership is because the
original author no longer has the time or interest in updating it or
following through with the SEP process, or has fallen off the face of
the 'net (i.e. is unreachable or not responding to email). A bad
reason to transfer ownership is because you don't agree with the
direction of the SEP. We try to build consensus around a SEP, but if
that's not possible, you can always submit a competing SEP.</p>
<p>If you are interested in assuming ownership of a SEP, send a message
asking to take over, addressed to both the original author and
<<a class="reference external" href="mailto:ausparc@googlegroups.com">ausparc@googlegroups.com</a>>. If the original author doesn't respond to email in a
timely manner, the SEP editor will make a unilateral decision (it's
not like such decisions can't be reversed :).</p>
</div>
<div class="section" id="sep-editor-responsibilities-workflow">
<h1><a class="toc-backref" href="#id25">SEP Editor Responsibilities & Workflow</a></h1>
<p>All SEP-related correspondence should be sent (or CC'd) to
<<a class="reference external" href="mailto:ausparc@googlegroups.com">ausparc@googlegroups.com</a>>.</p>
<p>For each new SEP that comes in an editor does the following:</p>
<ul class="simple">
<li>Read the SEP to check if it is ready: sound and complete. The ideas
must make technical sense, even if they don't seem likely to be
accepted.</li>
<li>The title should accurately describe the content.</li>
<li>Edit the SEP for language (spelling, grammar, sentence structure,
etc.), markup (for reST SEPs), code style (examples should match SEP
8 & 7).</li>
</ul>
<p>If the SEP isn't ready, the editor will send it back to the author for
revision, with specific instructions.</p>
<p>Once the SEP is ready for the repository, the SEP editor will:</p>
<ul class="simple">
<li>Assign a SEP number (almost always just the next available number,
but sometimes it's a special/joke number, like 666 or 3141).</li>
<li>List the SEP in SEP 0 (in two places: the categorized list, and the
numeric list).</li>
<li>Add the SEP to Github.</li>
<li>Send email back to the SEP author with next steps (post to
<a class="reference external" href="mailto:ausparc@googlegroups.com">ausparc@googlegroups.com</a>).</li>
</ul>
<p>Updates to existing SEPs also come in to <<a class="reference external" href="mailto:ausparc@googlegroups.com">ausparc@googlegroups.com</a>>.</p>
<p>Many SEPs are written and maintained by developers with write access
to the SPaRC codebase. The SEP editors monitor the list for
SEP changes, and correct any structure, grammar, spelling, or markup
mistakes we see.</p>
<p>The editors don't pass judgement on SEPs. We merely do the
administrative & editorial part. Except for times like this, there's
relatively low volume.</p>
<p>Resources:</p>
</div>
<div class="section" id="references-and-footnotes">
<h1><a class="toc-backref" href="#id26">References and Footnotes</a></h1>
<table class="docutils footnote" frame="void" id="id4" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id1">[1]</a></td><td>This historical record is available by the Github account:
<a class="reference external" href="https://github.com/AuburnSPaRC/SEP">https://github.com/AuburnSPaRC/SEP</a></td></tr>
</tbody>
</table>
<table class="docutils footnote" frame="void" id="id5" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label">[2]</td><td><em>(<a class="fn-backref" href="#id2">1</a>, <a class="fn-backref" href="#id3">2</a>)</em> SEP 12, Sample reStructuredText SEP Template
(<a class="reference external" href="http://AuburnSPaRC.github.com/SEP/sep-0012.html">http://AuburnSPaRC.github.com/SEP/sep-0012.html</a>)</td></tr>
</tbody>
</table>
<blockquote>
Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
coding: utf-8
End:</blockquote>
<table class="docutils footnote" frame="void" id="id6" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label">[3]</td><td><em>(<a class="fn-backref" href="#id7">1</a>, <a class="fn-backref" href="#id8">2</a>)</em> <a class="reference external" href="http://github.com/AuburnSPaRC">http://github.com/AuburnSPaRC</a></td></tr>
</tbody>
</table>
<table class="docutils footnote" frame="void" id="id9" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id10">[4]</a></td><td><a class="reference external" href="http://www.opencontent.org/openpub/">http://www.opencontent.org/openpub/</a></td></tr>
</tbody>
</table>
<table class="docutils footnote" frame="void" id="id11" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label">[5]</td><td><em>(<a class="fn-backref" href="#id12">1</a>, <a class="fn-backref" href="#id13">2</a>)</em> <a class="reference external" href="http://docutils.sourceforge.net/rst.html">http://docutils.sourceforge.net/rst.html</a></td></tr>
</tbody>
</table>
<table class="docutils footnote" frame="void" id="id14" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id15">[6]</a></td><td><a class="reference external" href="http://docutils.sourceforge.net/">http://docutils.sourceforge.net/</a></td></tr>
</tbody>
</table>
</div>
</div></div> <!-- /#dpage-inner, /#dpage -->
</body>
</html>