From 8ccb03464ab1d4610d01d7a74653d9a2fbd988d1 Mon Sep 17 00:00:00 2001 From: Karl Berry Date: Wed, 24 Oct 2018 07:26:20 -0700 Subject: [PATCH] autoupdate --- doc/maintain.texi | 52 +++++++++++++++++++++++++++++++++++++++++++++- doc/standards.texi | 18 +++++++++------- 2 files changed, 62 insertions(+), 8 deletions(-) diff --git a/doc/maintain.texi b/doc/maintain.texi index c09a1a4d97..4ad3cfe02d 100644 --- a/doc/maintain.texi +++ b/doc/maintain.texi @@ -5,7 +5,7 @@ @c For double-sided printing, uncomment: @c @setchapternewpage odd @c This date is automagically updated when you save this file: -@set lastupdate August 21, 2018 +@set lastupdate October 24, 2018 @c %**end of header @dircategory GNU organization @@ -67,6 +67,8 @@ Texts. A copy of the license is included in the section entitled * Distributions:: * Web Pages:: * Ethical and Philosophical Consideration:: +* Humor:: +* Other Politics:: * Terminology:: * Interviews and Speeches:: * Hosting:: @@ -2437,6 +2439,54 @@ frequently. We ask that GNU maintainers, at least on matters that pertain specifically to their package, stand with the rest of the GNU project when such issues come up. +@node Humor +@chapter Humor and GNU + +In GNU, we appreciate humor in our work. + +GNU is a project of hackers, and +@uref{https://stallman.org/articles/on-hacking.html,,hacking means +playful cleverness}. Even the name ``GNU'' is an example of playful +cleverness---it is a +@uref{https://gnu.org/gnu/the-gnu-project.html,,recursive acronym for +``GNU's Not Unix.''} + +In that spirit, we prize occasional doses of humor in GNU packages. +Humor is not mandatory in a GNU package; we do not tell maintainers, +``Make users smile, or else!'' But when maintainers do that, we too +smile. + +Nowadays, our humor-positive approach occasionally encounters direct, +blanket opposition. Some people advocate, and even demand, removal of +jokes from software packages simply because they are jokes. We shrug +off that point of view. + +Jokes are subject to the same sorts of issues and criticism as other +writing. Sometimes there is a valid objection to text which is +humorous, so we do not defend every joke obtusely to the bitter end. +But @emph{the fact that it is a joke} is not a valid objection. + +There are people who frown on anything that is slightly risqué or +controversial, including jokes. It would be a terrible shame for that +attitude to prevail, so our policy is that the occasional risqué joke +is ok. GNU is a 21st century project, not a 19th. + +@node Other Politics +@chapter Other Politics + +The GNU Project supports the cause of software freedom, that the users +of computing should have control of their computing activities. This +requires that they have control of their software that does those +activities, which in turn requires that they do these activities +with free software and have the possibility of replacing any shared +copies with their own copies. + +It also supports basic human rights in computing including use of the +internet; opposing censorship, for instance. + +A GNU package should not seriously advocate any other political +causes. Not that the GNU Project opposes those other causes. Rather, +it is neutral on them, and GNU packages should be neutral too. @node Terminology @chapter Terminology Issues diff --git a/doc/standards.texi b/doc/standards.texi index 468ba41eb1..86c26bb924 100644 --- a/doc/standards.texi +++ b/doc/standards.texi @@ -3,7 +3,7 @@ @setfilename standards.info @settitle GNU Coding Standards @c This date is automagically updated when you save this file: -@set lastupdate March 7, 2018 +@set lastupdate August 3, 2018 @c %**end of header @dircategory GNU organization @@ -3584,12 +3584,16 @@ The best place to explain how parts of the new code work with other code is in comments in the code, not in the change log. If you think that a change calls for explanation of @emph{why} the -change was needed (what problem the old code had), you're probably -right. Please put the explanation in comments in the code, where -people will see it whenever they see the code. An example of such an -explanation is, ``This function used to be iterative, but that failed -when MUMBLE was a tree.'' (Though such a simple reason would not need -this kind of explanation.) +change was needed---that is, what problem the old code had such that +it required this change---you're probably right. Please put the +explanation in comments in the code, where people will see it whenever +they see the code. An example of such an explanation is, ``This +function used to be iterative, but that failed when MUMBLE was a +tree.'' (Though such a simple reason would not need this kind of +explanation.) + +The best place for other kinds of explanation of the change is in the +change log entry. The easiest way to add an entry to @file{ChangeLog} is with the Emacs command @kbd{M-x add-change-log-entry}. An individual change should -- 2.39.5