-
-
Notifications
You must be signed in to change notification settings - Fork 11
/
guidelines.htp
247 lines (194 loc) · 10.1 KB
/
guidelines.htp
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
Title: Author Guidlines for the Sixth International Python Conference
Author: ipc6@python.org
<h1>Guidelines for Authors</h1>
<P>Here is more detailed information about submitting a paper to the
Sixth International Python Conference. These guidelines have been
adapted from those developed by the USENIX Association, co-sponsor of
this year's Python conference.
<p>Please read this page carefully. It was written to help you
give your submission the best possible chance to be accepted. (As you
know, the program committee can't accept every paper submitted to the
conference.)
<p>Generally speaking, we are looking for papers in a broad range of
practical issues in the development and use of open computer systems.
However, please do not be discouraged if you think that your paper
will not "fit" the Python conference format. Some of the best papers
of past conferences have been papers that were unusual and definitely
not "traditional".
<p>The key element of a good paper is that it teaches the readers
something that they can use when designing or using their systems, or
causes them to think about a computing issue in new ways.
<h3>Conference Dates</h3>
<P>The Sixth International Python Conference willl be held in San Jose,
California, October 14-17, 1997.
<p>
Dates for paper submissions:
<table border=0 cellspacing=0 cellpadding=0>
<tr><td>Email intent: </td> <td>June 20, 1997</td></tr>
<tr><td>Submissions due: </td> <td>July 25, 1997</td></tr>
<tr><td>Notification to authors:</td> <td>August 25, 1997</td></tr>
<tr><td>Camera-ready papers due: </td> <td>September 19, 1997</td></tr>
</table>
<h3>The Call for Papers</h3>
For your convenience, here is a summary of important submission
information in the Call For Papers. A complete copy of the Call For
Papers for this conference is <a href="cfp.html">available online</a>.
<P>If you intend to submit a paper, please send a short email
describing the intended paper to <a
href="mailto:ipc6-papers@python.org">ipc6-papers@python.org</A> by
June 20. (This step is optional but highly encouraged.)
<p> Authors must submit a full draft of the paper to the program chair
via one of the following methods. Papers should be 6 to 12
single-spaced, 8.5"x11" pages (about 3000-6000 words), including
figures and references.
<p> All submissions will be acknowledged.
<p><b>Preferred Method:</b> email to <a
href="mailto:ipc6-papers@python.org">ipc6-papers@python.org</A>.
Acceptable formats are:
<p>
<li>Plain ASCII text
<li>HTML (a single file, with no external links)
<li>MS-Word
<li>Postscript
<p>
<p><b>Alternate Method:</b> surface mail to:
<blockquote>
Sixth International Python Conference<br>
c/o Guido van Rossum<br>
CNRI<br>
1895 Preston White Drive<br>
Reston, VA 20191<br>
</blockquote>
<P>The authors must also submit via email to <a
href="mailto:ipc6-papers@python.org">ipc6-papers@python.org</A>
the following information:
<p>
<li> 1. The title of the manuscript and the names of the authors.
<li> 2. The name of one author who will serve as a contact, his or her
email address, day and evening phone numbers, postal mail
address, and a fax number, if available.
<li> 3. A short abstract of the paper (100-200 words) (This should be the
same as the paper's abstract.)
<p>
The final paper should be 6-12 pages in length.
<h3>What Kinds of Papers Do We Publish</h3>
<P>The most important thought to keep in mind when deciding whether to
submit a paper is "what will the audience or readers learn from my
paper?" We don't expect every paper to report on a major breakthrough,
but we do look for something new, potentially useful, and not entirely
obvious. Think about how different your work is from previously
published papers; it may be good work but if there is nothing new to
learn, it isn't worth reading (or writing) a conference paper about it.
Think about how other people might find your work useful; can they apply
what you are teaching them to their own systems? And, does your work
really improve upon the previous state of the art? Or does it show how
other people have been confused? "Negative results" that contradict the
conventional wisdom are often more important than positive results.
<p>Trying to decide if something is non-obvious isn't easy (patent
lawyers make lots of money arguing about this), and sometimes the best
ideas seem obvious in hindsight; but if lots of people have done the
same thing, and you are simply the first person to have considered
writing a paper about it, perhaps it's too obvious.
<p>The Program Committee will also be trying to decide if papers will lead
to a good 20-minute presentation (plus 10 minutes for questions).
Some systems are just too complex to
be presented this way (perhaps you should focus on just one aspect);
other papers just don't have enough to talk about for that long. On
the other hand, a few rare papers are accepted mostly because the
committee expects them to produce an interesting talk, but that might
not otherwise merit publication.
<p>Again, when you are writing your paper, keep in mind "what do I intend
to teach the reader?" That means keeping the paper focused on one or a
few main points. Don't try to cram too many big issues into the paper,
and don't fill it up with irrelevant details. But do include enough
background for the reader to understand why your problem is important,
how your work relates to previous work in the field, and how it might
fit into a practical system. Also, provide enough detail for the
reader to put your performance measurements in context. It is vitally
important to provide a good bibliography, both so that you give proper
credit to previous work, and so that a reader can know where to turn to
find additional background information. The program committee will not
look kindly on a paper if the author doesn't appear to be familiar with
the current literature.
<p>
<h3>What Do We Mean by a Draft of a Full Paper?</h3>
You will have the opportunity to revise your paper before the
camera-ready copy deadline, so it's okay to have a few rough edges or to
include a few explanatory notes for the program committee. However, a
submitted draft of your paper should include essentially all of your
results and a substantial portion of your analysis. Please do not omit
any essential details.
<h3>How Should I Get my Manuscript to You?</h3>
<P>The Program Committee would prefer to receive submissions via electronic
mail, but there are occasionally problems in printing them. If you have
any reason to suspect that your submission might not be easy for us to
print, please submit a printed hardcopy by surface mail in addition to
your electronic version.
<p>Submissions via email can be made in several formats. Flat text files
are always easy to print, but if you have any figures or graphics this
probably won't work. If you do use flat text, please remember to
format it neatly and keep lines under 80 columns in width.
<P>PostScript files are usually the best format, <b>but</b> some PostScript
generators are quite buggy and we may not be able to print their
output. For example, lots of software generates PostScript that can
only be printed on Apple Laserwriters. If you send PostScript,
remember the following:
<p>
<li> Use only the most basic of fonts (TimesRoman, Helvetica,
Courier). Other fonts are often not available with every
printer or previewer.
<li> PostScript that requires some special prolog to be loaded
into the printer won't work for us. Don't send it.
<li> If you used a PC or Macintosh-based word processor to
generate your PostScript, print it on a more generic
PostScript printer before sending it, to make absolutely sure
that the PostScript is portable.
<p>
<P>We also accept HTML and MS-Word. If you submit HTML, please submit
a single file containing the main text (separate files containing
in-line images are okay, but please don't submit more than one .html
file; we need to be able to print it as a single print job).
<b>Do not</b> send files meant for other word-processing packages
(LaTeX, TeX, Troff, WordPerfect, MacWrite, etc.). We don't have the
resources to deal with them.
<p>Since electronic mail systems have been known to mangle mail, it is
always a good idea to wrap up your submission either by using MIME
encapsulation (quoted-printable or base64, as appropriate) or by using
shar(1) or tar(1). Note, if you use tar, or, if your email contains
any non-printing characters, use uuencode(1) to convert your email to
pure ASCII characters.
<p>Overseas authors should make sure that their abstract prints properly
on US-style 8.5x11 inch paper. Please make sure that you leave enough
room for top and bottom margins.
<h3>More Information Is Available</h3>
<P>Lots of papers and books have been written about how to write a good
paper. We suggest that you read a paper called
<a href="good_paper.html">"An
Evaluation of the Ninth SOSP Submissions; or, How (and How Not) to
Write a Good Systems Paper."</a> This was written by Roy Levin and David
D. Redell, the program committee co-chairs for SOSP-9, and first
appeared in ACM SIGOPS Operating Systems Review, Vol. 17, No. 3 (July,
1983), pages 35-40.
<p>The authors have graciously agreed to make this paper available
<a href="good_paper.html">online</a>.
<p>
Another helpful paper is:
<br>
"The Science of Scientific Writing", George D. Gopen and Judith A.
Swan, <i>American Scientist</i>, Vol. 78, No. 6 (Nov-Dec, 1990),
pp. 550-558.
<P>This article describes not how to write an entire paper, but how to
write sentences and paragraphs that readers can understand.
Unfortunately, due to copyright restrictions we cannot make this
available online or send you photocopies, but almost any library should
have copies of this magazine.
<p>We also recommend that you read the proceedings of some recent USENIX
conferences to get an idea of what kinds of papers are published. Not
every one of these papers is perfect (or even great), but most of them
are better than most of the ones that got rejected.
<p>
Finally, if you have any other questions, feel free to send mail to the
<a href="mailto:ipc6@python.org">program committee chairs at
ipc6@python.org</a>.
<P>Good Luck,<br>
The Program Committee