Commit | Line | Data |
---|---|---|
3db23aec SH |
1 | =encoding utf8 |
2 | ||
48cb5b3a | 3 | =head1 NAME |
3c78fafa | 4 | |
9a7064ee | 5 | perlpolicy - Various and sundry policies and commitments related to the Perl core |
48cb5b3a JV |
6 | |
7 | =head1 DESCRIPTION | |
8 | ||
9 | This document is the master document which records all written | |
10 | policies about how the Perl 5 Porters collectively develop and maintain | |
11 | the Perl core. | |
12 | ||
a101a770 JV |
13 | =head1 GOVERNANCE |
14 | ||
15 | =head2 Perl 5 Porters | |
16 | ||
17 | Subscribers to perl5-porters (the porters themselves) come in several flavours. | |
18 | Some are quiet curious lurkers, who rarely pitch in and instead watch | |
19 | the ongoing development to ensure they're forewarned of new changes or | |
20 | features in Perl. Some are representatives of vendors, who are there | |
21 | to make sure that Perl continues to compile and work on their | |
22 | platforms. Some patch any reported bug that they know how to fix, | |
23 | some are actively patching their pet area (threads, Win32, the regexp | |
24 | -engine), while others seem to do nothing but complain. In other | |
25 | words, it's your usual mix of technical people. | |
26 | ||
66c65f79 RS |
27 | Among these people are the core Perl team. These are trusted volunteers |
28 | involved in the ongoing development of the Perl language and interpreter. | |
29 | They are not required to be language developers or committers. | |
30 | ||
a101a770 JV |
31 | Over this group of porters presides Larry Wall. He has the final word |
32 | in what does and does not change in any of the Perl programming languages. | |
17b35041 | 33 | These days, Larry spends most of his time on Raku, while Perl 5 is |
66c65f79 | 34 | shepherded by a steering council of porters responsible for deciding what |
a101a770 JV |
35 | goes into each release and ensuring that releases happen on a regular |
36 | basis. | |
37 | ||
38 | Larry sees Perl development along the lines of the US government: | |
66c65f79 RS |
39 | there's the Legislature (the porters, represented by the core team), the |
40 | Executive branch (the steering council), and the Supreme Court (Larry). | |
41 | The legislature can discuss and submit patches to the executive branch | |
42 | all they like, but the executive branch is free to veto them. Rarely, | |
43 | the Supreme Court will side with the executive branch over the | |
44 | legislature, or the legislature over the executive branch. Mostly, | |
45 | however, the legislature and the executive branch are supposed to get | |
46 | along and work out their differences without impeachment or court cases. | |
a101a770 JV |
47 | |
48 | You might sometimes see reference to Rule 1 and Rule 2. Larry's power | |
49 | as Supreme Court is expressed in The Rules: | |
50 | ||
51 | =over 4 | |
52 | ||
53 | =item 1 | |
54 | ||
55 | Larry is always by definition right about how Perl should behave. | |
56 | This means he has final veto power on the core functionality. | |
57 | ||
58 | =item 2 | |
59 | ||
60 | Larry is allowed to change his mind about any matter at a later date, | |
61 | regardless of whether he previously invoked Rule 1. | |
62 | ||
63 | =back | |
64 | ||
65 | Got that? Larry is always right, even when he was wrong. It's rare | |
66 | to see either Rule exercised, but they are often alluded to. | |
67 | ||
66c65f79 RS |
68 | For the specifics on how the members of the core team and steering |
69 | council are elected or rotated, consult L<perlgov>, which spells it all | |
70 | out in detail. | |
71 | ||
70eadc36 JV |
72 | =head1 MAINTENANCE AND SUPPORT |
73 | ||
74 | Perl 5 is developed by a community, not a corporate entity. Every change | |
75 | contributed to the Perl core is the result of a donation. Typically, these | |
76 | donations are contributions of code or time by individual members of our | |
77 | community. On occasion, these donations come in the form of corporate | |
78 | or organizational sponsorship of a particular individual or project. | |
79 | ||
80 | As a volunteer organization, the commitments we make are heavily dependent | |
81 | on the goodwill and hard work of individuals who have no obligation to | |
82 | contribute to Perl. | |
83 | ||
3b4ebcde | 84 | That being said, we value Perl's stability and security and have long |
70eadc36 JV |
85 | had an unwritten covenant with the broader Perl community to support |
86 | and maintain releases of Perl. | |
87 | ||
88 | This document codifies the support and maintenance commitments that | |
89 | the Perl community should expect from Perl's developers: | |
90 | ||
91 | =over | |
92 | ||
93 | =item * | |
94 | ||
826b5eeb KE |
95 | We "officially" support the two most recent stable release series. 5.30.x |
96 | and earlier are now out of support. As of the release of 5.36.0, we will | |
97 | "officially" end support for Perl 5.32.x, other than providing security | |
70eadc36 JV |
98 | updates as described below. |
99 | ||
100 | =item * | |
101 | ||
102 | To the best of our ability, we will attempt to fix critical issues | |
e26b5c49 | 103 | in the two most recent stable 5.x release series. Fixes for the |
70eadc36 JV |
104 | current release series take precedence over fixes for the previous |
105 | release series. | |
106 | ||
107 | =item * | |
108 | ||
109 | To the best of our ability, we will provide "critical" security patches | |
f50f542d | 110 | / releases for any major version of Perl whose 5.x.0 release was within |
70a565f4 RS |
111 | the past three years. We can only commit to providing these for the |
112 | most recent .y release in any 5.x.y series. | |
70eadc36 JV |
113 | |
114 | =item * | |
115 | ||
116 | We will not provide security updates or bug fixes for development | |
117 | releases of Perl. | |
118 | ||
119 | =item * | |
120 | ||
121 | We encourage vendors to ship the most recent supported release of | |
122 | Perl at the time of their code freeze. | |
123 | ||
124 | =item * | |
125 | ||
126 | As a vendor, you may have a requirement to backport security fixes | |
127 | beyond our 3 year support commitment. We can provide limited support and | |
128 | advice to you as you do so and, where possible will try to apply | |
129 | those patches to the relevant -maint branches in git, though we may or | |
130 | may not choose to make numbered releases or "official" patches | |
87c118b9 DM |
131 | available. See L<perlsec/SECURITY VULNERABILITY CONTACT INFORMATION> |
132 | for details on how to begin that process. | |
70eadc36 JV |
133 | |
134 | =back | |
135 | ||
70e4a83b JV |
136 | =head1 BACKWARD COMPATIBILITY AND DEPRECATION |
137 | ||
138 | Our community has a long-held belief that backward-compatibility is a | |
139 | virtue, even when the functionality in question is a design flaw. | |
140 | ||
141 | We would all love to unmake some mistakes we've made over the past | |
142 | decades. Living with every design error we've ever made can lead | |
143 | to painful stagnation. Unwinding our mistakes is very, very | |
144 | difficult. Doing so without actively harming our users is | |
145 | nearly impossible. | |
146 | ||
147 | Lately, ignoring or actively opposing compatibility with earlier versions | |
148 | of Perl has come into vogue. Sometimes, a change is proposed which | |
149 | wants to usurp syntax which previously had another meaning. Sometimes, | |
339a461d | 150 | a change wants to improve previously-crazy semantics. |
70e4a83b JV |
151 | |
152 | Down this road lies madness. | |
153 | ||
154 | Requiring end-user programmers to change just a few language constructs, | |
155 | even language constructs which no well-educated developer would ever | |
156 | intentionally use is tantamount to saying "you should not upgrade to | |
157 | a new release of Perl unless you have 100% test coverage and can do a | |
158 | full manual audit of your codebase." If we were to have tools capable of | |
159 | reliably upgrading Perl source code from one version of Perl to another, | |
160 | this concern could be significantly mitigated. | |
161 | ||
162 | We want to ensure that Perl continues to grow and flourish in the coming | |
163 | years and decades, but not at the expense of our user community. | |
164 | ||
165 | Existing syntax and semantics should only be marked for destruction in | |
1adbeba0 | 166 | very limited circumstances. If they are believed to be very rarely used, |
667f5e7f RS |
167 | stand in the way of actual improvement to the Perl language or perl |
168 | interpreter, and if affected code can be easily updated to continue | |
169 | working, they may be considered for removal. When in doubt, caution | |
170 | dictates that we will favor backward compatibility. When a feature is | |
171 | deprecated, a statement of reasoning describing the decision process | |
172 | will be posted, and a link to it will be provided in the relevant | |
173 | perldelta documents. | |
5ae454f0 RS |
174 | |
175 | Using a lexical pragma to enable or disable legacy behavior should be | |
176 | considered when appropriate, and in the absence of any pragma legacy | |
177 | behavior should be enabled. Which backward-incompatible changes are | |
178 | controlled implicitly by a 'use v5.x.y' is a decision which should be | |
66c65f79 | 179 | made by the steering council in consultation with the community. |
70e4a83b JV |
180 | |
181 | Historically, we've held ourselves to a far higher standard than | |
182 | backward-compatibility -- bugward-compatibility. Any accident of | |
183 | implementation or unintentional side-effect of running some bit of code | |
184 | has been considered to be a feature of the language to be defended with | |
185 | the same zeal as any other feature or functionality. No matter how | |
186 | frustrating these unintentional features may be to us as we continue | |
187 | to improve Perl, these unintentional features often deserve our | |
188 | protection. It is very important that existing software written in | |
189 | Perl continue to work correctly. If end-user developers have adopted a | |
190 | bug as a feature, we need to treat it as such. | |
191 | ||
192 | New syntax and semantics which don't break existing language constructs | |
193 | and syntax have a much lower bar. They merely need to prove themselves | |
b50cfd0a RS |
194 | to be useful, elegant, well designed, and well tested. In most cases, |
195 | these additions will be marked as I<experimental> for some time. See | |
196 | below for more on that. | |
70e4a83b JV |
197 | |
198 | =head2 Terminology | |
199 | ||
200 | To make sure we're talking about the same thing when we discuss the removal | |
201 | of features or functionality from the Perl core, we have specific definitions | |
202 | for a few words and phrases. | |
203 | ||
204 | =over | |
205 | ||
206 | =item experimental | |
207 | ||
208 | If something in the Perl core is marked as B<experimental>, we may change | |
209 | its behaviour, deprecate or remove it without notice. While we'll always | |
210 | do our best to smooth the transition path for users of experimental | |
211 | features, you should contact the perl5-porters mailinglist if you find | |
212 | an experimental feature useful and want to help shape its future. | |
213 | ||
f1126a90 RS |
214 | Experimental features must be experimental in two stable releases before being |
215 | marked non-experimental. Experimental features will only have their | |
216 | experimental status revoked when they no longer have any design-changing bugs | |
217 | open against them and when they have remained unchanged in behavior for the | |
218 | entire length of a development cycle. In other words, a feature present in | |
219 | v5.20.0 may be marked no longer experimental in v5.22.0 if and only if its | |
220 | behavior is unchanged throughout all of v5.21. | |
221 | ||
70e4a83b JV |
222 | =item deprecated |
223 | ||
224 | If something in the Perl core is marked as B<deprecated>, we may remove it | |
5c5fd8eb KW |
225 | from the core in the future, though we might not. Generally, backward |
226 | incompatible changes will have deprecation warnings for two release | |
227 | cycles before being removed, but may be removed after just one cycle if | |
228 | the risk seems quite low or the benefits quite high. | |
229 | ||
230 | As of | |
70e4a83b | 231 | Perl 5.12, deprecated features and modules warn the user as they're used. |
42b68fb1 DG |
232 | When a module is deprecated, it will also be made available on CPAN. |
233 | Installing it from CPAN will silence deprecation warnings for that module. | |
234 | ||
235 | If you use a deprecated feature or module and believe that its removal from | |
236 | the Perl core would be a mistake, please contact the perl5-porters | |
237 | mailinglist and plead your case. We don't deprecate things without a good | |
238 | reason, but sometimes there's a counterargument we haven't considered. | |
239 | Historically, we did not distinguish between "deprecated" and "discouraged" | |
240 | features. | |
70e4a83b JV |
241 | |
242 | =item discouraged | |
243 | ||
244 | From time to time, we may mark language constructs and features which we | |
245 | consider to have been mistakes as B<discouraged>. Discouraged features | |
5c5fd8eb | 246 | aren't currently candidates for removal, but |
70e4a83b | 247 | we may later deprecate them if they're found to stand in the way of a |
9a7064ee | 248 | significant improvement to the Perl core. |
70e4a83b JV |
249 | |
250 | =item removed | |
251 | ||
5c5fd8eb KW |
252 | Once a feature, construct or module has been marked as deprecated, we |
253 | may remove it from the Perl core. Unsurprisingly, | |
42b68fb1 DG |
254 | we say we've B<removed> these things. When a module is removed, it will |
255 | no longer ship with Perl, but will continue to be available on CPAN. | |
70e4a83b JV |
256 | |
257 | =back | |
48cb5b3a | 258 | |
fcf56c88 JV |
259 | =head1 MAINTENANCE BRANCHES |
260 | ||
366d02b5 SH |
261 | New releases of maintenance branches should only contain changes that fall into |
262 | one of the "acceptable" categories set out below, but must not contain any | |
263 | changes that fall into one of the "unacceptable" categories. (For example, a | |
264 | fix for a crashing bug must not be included if it breaks binary compatibility.) | |
265 | ||
266 | It is not necessary to include every change meeting these criteria, and in | |
267 | general the focus should be on addressing security issues, crashing bugs, | |
268 | regressions and serious installation issues. The temptation to include a | |
269 | plethora of minor changes that don't affect the installation or execution of | |
270 | perl (e.g. spelling corrections in documentation) should be resisted in order | |
271 | to reduce the overall risk of overlooking something. The intention is to | |
272 | create maintenance releases which are both worthwhile and which users can have | |
273 | full confidence in the stability of. (A secondary concern is to avoid burning | |
66c65f79 RS |
274 | out the maint-release manager or overwhelming other committers voting on |
275 | changes to be included (see L</"Getting changes into a maint branch"> | |
276 | below).) | |
fcf56c88 | 277 | |
c792d632 SH |
278 | The following types of change may be considered acceptable, as long as they do |
279 | not also fall into any of the "unacceptable" categories set out below: | |
280 | ||
281 | =over | |
282 | ||
fcf56c88 JV |
283 | =item * |
284 | ||
79f83602 | 285 | Patches that fix CVEs or security issues. These changes should |
87c118b9 DM |
286 | be passed using the security reporting mechanism rather than applied |
287 | directly; see L<perlsec/SECURITY VULNERABILITY CONTACT INFORMATION>. | |
fcf56c88 JV |
288 | |
289 | =item * | |
290 | ||
4c0ef208 | 291 | Patches that fix crashing bugs, assertion failures and |
a6f83414 | 292 | memory corruption but which do not otherwise change perl's |
79f83602 | 293 | functionality or negatively impact performance. |
fcf56c88 JV |
294 | |
295 | =item * | |
296 | ||
56b40e63 | 297 | Patches that fix regressions in perl's behavior relative to previous |
fc088d5f SH |
298 | releases, no matter how old the regression, since some people may |
299 | upgrade from very old versions of perl to the latest version. | |
56b40e63 RS |
300 | |
301 | =item * | |
302 | ||
539a060c AC |
303 | Patches that fix bugs in features that were new in the corresponding 5.x.0 |
304 | stable release. | |
305 | ||
306 | =item * | |
307 | ||
e2b7b23f SH |
308 | Patches that fix anything which prevents or seriously impacts the build |
309 | or installation of perl. | |
310 | ||
311 | =item * | |
312 | ||
64b35da5 | 313 | Portability fixes, such as changes to Configure and the files in |
79f83602 | 314 | the hints/ folder. |
fcf56c88 JV |
315 | |
316 | =item * | |
317 | ||
e2b7b23f | 318 | Minimal patches that fix platform-specific test failures. |
27d0393b | 319 | |
64b35da5 SH |
320 | =item * |
321 | ||
79f83602 SH |
322 | Documentation updates that correct factual errors, explain significant |
323 | bugs or deficiencies in the current implementation, or fix broken markup. | |
64b35da5 SH |
324 | |
325 | =item * | |
326 | ||
327 | Updates to dual-life modules should consist of minimal patches to | |
b33e5804 SH |
328 | fix crashing bugs or security issues (as above). Any changes made to |
329 | dual-life modules for which CPAN is canonical should be coordinated with | |
330 | the upstream author. | |
64b35da5 | 331 | |
c792d632 SH |
332 | =back |
333 | ||
334 | The following types of change are NOT acceptable: | |
335 | ||
336 | =over | |
337 | ||
338 | =item * | |
339 | ||
66c65f79 RS |
340 | Patches that break binary compatibility. (Please talk to the steering |
341 | council.) | |
c792d632 SH |
342 | |
343 | =item * | |
344 | ||
79f83602 | 345 | Patches that add or remove features. |
c792d632 | 346 | |
27d0393b JV |
347 | =item * |
348 | ||
79f83602 | 349 | Patches that add new warnings or errors or deprecate features. |
fcf56c88 JV |
350 | |
351 | =item * | |
352 | ||
79f83602 SH |
353 | Ports of Perl to a new platform, architecture or OS release that |
354 | involve changes to the implementation. | |
fcf56c88 JV |
355 | |
356 | =item * | |
357 | ||
64b35da5 SH |
358 | New versions of dual-life modules should NOT be imported into maint. |
359 | Those belong in the next stable series. | |
fcf56c88 JV |
360 | |
361 | =back | |
362 | ||
a969a3c5 SH |
363 | If there is any question about whether a given patch might merit |
364 | inclusion in a maint release, then it almost certainly should not | |
365 | be included. | |
366 | ||
fcf56c88 JV |
367 | =head2 Getting changes into a maint branch |
368 | ||
66c65f79 RS |
369 | Historically, only the single-person project manager cherry-picked |
370 | changes from bleadperl into maintperl. This has scaling problems. At | |
371 | the same time, maintenance branches of stable versions of Perl need to | |
372 | be treated with great care. To that end, as of Perl 5.12, we have a new | |
373 | process for maint branches. | |
fcf56c88 | 374 | |
29f85661 SH |
375 | Any committer may cherry-pick any commit from blead to a maint branch by |
376 | first adding an entry to the relevant voting file in the maint-votes branch | |
377 | announcing the commit as a candidate for back-porting, and then waiting for | |
378 | at least two other committers to add their votes in support of this (i.e. a | |
379 | total of at least three votes is required before a commit may be back-ported). | |
380 | ||
381 | Most of the work involved in both rounding up a suitable set of candidate | |
382 | commits and cherry-picking those for which three votes have been cast will | |
383 | be done by the maint branch release manager, but anyone else is free to add | |
384 | other proposals if they're keen to ensure certain fixes don't get overlooked | |
385 | or fear they already have been. | |
386 | ||
387 | Other voting mechanisms may also be used instead (e.g. sending mail to | |
388 | perl5-porters and at least two other committers responding to the list | |
389 | giving their assent), as long as the same number of votes is gathered in a | |
390 | transparent manner. Specifically, proposals of which changes to cherry-pick | |
391 | must be visible to everyone on perl5-porters so that the views of everyone | |
392 | interested may be heard. | |
6788bcfc | 393 | |
402f2e6a SH |
394 | It is not necessary for voting to be held on cherry-picking perldelta |
395 | entries associated with changes that have already been cherry-picked, nor | |
66c65f79 | 396 | for the maint-release manager to obtain votes on changes required by the |
402f2e6a SH |
397 | F<Porting/release_managers_guide.pod> where such changes can be applied by |
398 | the means of cherry-picking from blead. | |
399 | ||
48cb5b3a JV |
400 | =head1 CONTRIBUTED MODULES |
401 | ||
402 | ||
403 | =head2 A Social Contract about Artistic Control | |
6ee623d5 GS |
404 | |
405 | What follows is a statement about artistic control, defined as the ability | |
406 | of authors of packages to guide the future of their code and maintain | |
407 | control over their work. It is a recognition that authors should have | |
408 | control over their work, and that it is a responsibility of the rest of | |
409 | the Perl community to ensure that they retain this control. It is an | |
410 | attempt to document the standards to which we, as Perl developers, intend | |
411 | to hold ourselves. It is an attempt to write down rough guidelines about | |
412 | the respect we owe each other as Perl developers. | |
413 | ||
414 | This statement is not a legal contract. This statement is not a legal | |
415 | document in any way, shape, or form. Perl is distributed under the GNU | |
416 | Public License and under the Artistic License; those are the precise legal | |
417 | terms. This statement isn't about the law or licenses. It's about | |
418 | community, mutual respect, trust, and good-faith cooperation. | |
419 | ||
420 | We recognize that the Perl core, defined as the software distributed with | |
421 | the heart of Perl itself, is a joint project on the part of all of us. | |
aaa2bbb1 | 422 | From time to time, a script, module, or set of modules (hereafter referred |
6ee623d5 GS |
423 | to simply as a "module") will prove so widely useful and/or so integral to |
424 | the correct functioning of Perl itself that it should be distributed with | |
9a7064ee | 425 | the Perl core. This should never be done without the author's explicit |
6ee623d5 GS |
426 | consent, and a clear recognition on all parts that this means the module |
427 | is being distributed under the same terms as Perl itself. A module author | |
428 | should realize that inclusion of a module into the Perl core will | |
429 | necessarily mean some loss of control over it, since changes may | |
430 | occasionally have to be made on short notice or for consistency with the | |
431 | rest of Perl. | |
432 | ||
433 | Once a module has been included in the Perl core, however, everyone | |
434 | involved in maintaining Perl should be aware that the module is still the | |
435 | property of the original author unless the original author explicitly | |
436 | gives up their ownership of it. In particular: | |
437 | ||
48cb5b3a JV |
438 | =over |
439 | ||
171407a0 JJ |
440 | =item * |
441 | ||
9a7064ee | 442 | The version of the module in the Perl core should still be considered the |
171407a0 JJ |
443 | work of the original author. All patches, bug reports, and so |
444 | forth should be fed back to them. Their development directions | |
445 | should be respected whenever possible. | |
6ee623d5 | 446 | |
48cb5b3a JV |
447 | =item * |
448 | ||
66c65f79 | 449 | Patches may be applied by the steering council without the explicit |
48cb5b3a JV |
450 | cooperation of the module author if and only if they are very minor, |
451 | time-critical in some fashion (such as urgent security fixes), or if | |
452 | the module author cannot be reached. Those patches must still be | |
453 | given back to the author when possible, and if the author decides on | |
454 | an alternate fix in their version, that fix should be strongly | |
455 | preferred unless there is a serious problem with it. Any changes not | |
456 | endorsed by the author should be marked as such, and the contributor | |
457 | of the change acknowledged. | |
458 | ||
459 | =item * | |
460 | ||
461 | The version of the module distributed with Perl should, whenever | |
462 | possible, be the latest version of the module as distributed by the | |
463 | author (the latest non-beta version in the case of public Perl | |
66c65f79 | 464 | releases), although the steering council may hold off on upgrading the |
48cb5b3a JV |
465 | version of the module distributed with Perl to the latest version |
466 | until the latest version has had sufficient testing. | |
467 | ||
468 | =back | |
6ee623d5 GS |
469 | |
470 | In other words, the author of a module should be considered to have final | |
471 | say on modifications to their module whenever possible (bearing in mind | |
472 | that it's expected that everyone involved will work together and arrive at | |
473 | reasonable compromises when there are disagreements). | |
474 | ||
475 | As a last resort, however: | |
476 | ||
48cb5b3a | 477 | If the author's vision of the future of their module is sufficiently |
66c65f79 RS |
478 | different from the vision of the steering council and perl5-porters as a |
479 | whole so as to cause serious problems for Perl, the steering council may | |
9a7064ee | 480 | choose to formally fork the version of the module in the Perl core from the |
48cb5b3a | 481 | one maintained by the author. This should not be done lightly and |
c4f5d98d | 482 | should B<always> if at all possible be done only after direct input |
48cb5b3a | 483 | from Larry. If this is done, it must then be made explicit in the |
9a7064ee | 484 | module as distributed with the Perl core that it is a forked version and |
48cb5b3a JV |
485 | that while it is based on the original author's work, it is no longer |
486 | maintained by them. This must be noted in both the documentation and | |
487 | in the comments in the source of the module. | |
6ee623d5 GS |
488 | |
489 | Again, this should be a last resort only. Ideally, this should never | |
490 | happen, and every possible effort at cooperation and compromise should be | |
491 | made before doing this. If it does prove necessary to fork a module for | |
492 | the overall health of Perl, proper credit must be given to the original | |
493 | author in perpetuity and the decision should be constantly re-evaluated to | |
494 | see if a remerging of the two branches is possible down the road. | |
495 | ||
496 | In all dealings with contributed modules, everyone maintaining Perl should | |
497 | keep in mind that the code belongs to the original author, that they may | |
498 | not be on perl5-porters at any given time, and that a patch is not | |
499 | official unless it has been integrated into the author's copy of the | |
500 | module. To aid with this, and with points #1, #2, and #3 above, contact | |
501 | information for the authors of all contributed modules should be kept with | |
502 | the Perl distribution. | |
503 | ||
504 | Finally, the Perl community as a whole recognizes that respect for | |
505 | ownership of code, respect for artistic control, proper credit, and active | |
506 | effort to prevent unintentional code skew or communication gaps is vital | |
507 | to the health of the community and Perl itself. Members of a community | |
508 | should not normally have to resort to rules and laws to deal with each | |
509 | other, and this document, although it contains rules so as to be clear, is | |
510 | about an attitude and general approach. The first step in any dispute | |
511 | should be open communication, respect for opposing views, and an attempt | |
512 | at a compromise. In nearly every circumstance nothing more will be | |
513 | necessary, and certainly no more drastic measure should be used until | |
514 | every avenue of communication and discussion has failed. | |
3c78fafa | 515 | |
70e4a83b | 516 | |
3b4ebcde JV |
517 | =head1 DOCUMENTATION |
518 | ||
519 | Perl's documentation is an important resource for our users. It's | |
520 | incredibly important for Perl's documentation to be reasonably coherent | |
521 | and to accurately reflect the current implementation. | |
522 | ||
523 | Just as P5P collectively maintains the codebase, we collectively | |
524 | maintain the documentation. Writing a particular bit of documentation | |
525 | doesn't give an author control of the future of that documentation. | |
526 | At the same time, just as source code changes should match the style | |
527 | of their surrounding blocks, so should documentation changes. | |
528 | ||
529 | Examples in documentation should be illustrative of the concept | |
530 | they're explaining. Sometimes, the best way to show how a | |
531 | language feature works is with a small program the reader can | |
532 | run without modification. More often, examples will consist | |
533 | of a snippet of code containing only the "important" bits. | |
534 | The definition of "important" varies from snippet to snippet. | |
1bb8a155 | 535 | Sometimes it's important to declare C<use strict> and C<use warnings>, |
3b4ebcde JV |
536 | initialize all variables and fully catch every error condition. |
537 | More often than not, though, those things obscure the lesson | |
538 | the example was intended to teach. | |
539 | ||
540 | As Perl is developed by a global team of volunteers, our | |
541 | documentation often contains spellings which look funny | |
542 | to I<somebody>. Choice of American/British/Other spellings | |
543 | is left as an exercise for the author of each bit of | |
544 | documentation. When patching documentation, try to emulate | |
545 | the documentation around you, rather than changing the existing | |
546 | prose. | |
547 | ||
548 | In general, documentation should describe what Perl does "now" rather | |
549 | than what it used to do. It's perfectly reasonable to include notes | |
550 | in documentation about how behaviour has changed from previous releases, | |
9e9fdd5d | 551 | but, with very few exceptions, documentation isn't "dual-life" -- |
3b4ebcde JV |
552 | it doesn't need to fully describe how all old versions used to work. |
553 | ||
17c80487 RS |
554 | =head1 STANDARDS OF CONDUCT |
555 | ||
556 | The official forum for the development of perl is the perl5-porters mailing | |
e4b61f95 | 557 | list, mentioned above, and its bugtracker at GitHub. Posting to the |
ef7498d2 AC |
558 | list and the bugtracker is not a right: all participants in discussion are |
559 | expected to adhere to a standard of conduct. | |
17c80487 RS |
560 | |
561 | =over 4 | |
562 | ||
563 | =item * | |
564 | ||
565 | Always be civil. | |
566 | ||
ef7498d2 | 567 | =item * |
17c80487 RS |
568 | |
569 | Heed the moderators. | |
570 | ||
571 | =back | |
572 | ||
ef7498d2 AC |
573 | Civility is simple: stick to the facts while avoiding demeaning remarks, |
574 | belittling other individuals, sarcasm, or a presumption of bad faith. It is | |
575 | not enough to be factual. You must also be civil. Responding in kind to | |
576 | incivility is not acceptable. If you relay otherwise-unposted comments to | |
577 | the list from a third party, you take responsibility for the content of | |
578 | those comments, and you must therefore ensure that they are civil. | |
17c80487 | 579 | |
8764ee63 CB |
580 | While civility is required, kindness is encouraged; if you have any doubt about |
581 | whether you are being civil, simply ask yourself, "Am I being kind?" and aspire | |
582 | to that. | |
583 | ||
17c80487 | 584 | If the list moderators tell you that you are not being civil, carefully |
8764ee63 CB |
585 | consider how your words have appeared before responding in any way. Were they |
586 | kind? You may protest, but repeated protest in the face of a repeatedly | |
ef7498d2 AC |
587 | reaffirmed decision is not acceptable. Repeatedly protesting about the |
588 | moderators' decisions regarding a third party is also unacceptable, as is | |
589 | continuing to initiate off-list contact with the moderators about their | |
590 | decisions. | |
591 | ||
592 | Unacceptable behavior will result in a public and clearly identified | |
593 | warning. A second instance of unacceptable behavior from the same | |
e4b61f95 DB |
594 | individual will result in removal from the mailing list and GitHub issue |
595 | tracker, for a period of one calendar month. The rationale for this is to | |
ef7498d2 AC |
596 | provide an opportunity for the person to change the way they act. |
597 | ||
598 | After the time-limited ban has been lifted, a third instance of | |
599 | unacceptable behavior will result in a further public warning. A fourth | |
600 | or subsequent instance will result in an indefinite ban. The rationale | |
601 | is that, in the face of an apparent refusal to change behavior, we must | |
602 | protect other community members from future unacceptable actions. The | |
603 | moderators may choose to lift an indefinite ban if the person in | |
604 | question affirms they will not transgress again. | |
605 | ||
606 | Removals, like warnings, are public. | |
17c80487 | 607 | |
0c6082f4 | 608 | The list of moderators will be public knowledge. At present, it is: |
98812e18 | 609 | Karen Etheridge, Neil Bowers, Nicholas Clark, Ricardo Signes, Todd Rinaldo. |
3b4ebcde | 610 | |
48cb5b3a JV |
611 | =head1 CREDITS |
612 | ||
3b4ebcde | 613 | "Social Contract about Contributed Modules" originally by Russ Allbery E<lt>rra@stanford.eduE<gt> and the perl5-porters. |
3c78fafa | 614 |