]> Savannah Git Hosting - gnulib.git/commitdiff
autoupdate
authorKarl Berry <karl@freefriends.org>
Wed, 24 Oct 2018 14:26:20 +0000 (07:26 -0700)
committerKarl Berry <karl@freefriends.org>
Wed, 24 Oct 2018 14:26:20 +0000 (07:26 -0700)
doc/maintain.texi
doc/standards.texi

index c09a1a4d97038f6d1b6d9a0846b6d139d143096b..4ad3cfe02da8ca5f74e44c0e073c50969e922d4c 100644 (file)
@@ -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
index 468ba41eb1c24a9bbc34df2c2fc1908b03cd0e3c..86c26bb9242a51e5c58966531895b09a44064492 100644 (file)
@@ -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