[issue18280] Documentation is too personalized
New submission from Serhiy Storchaka:
Some documentation files contain a number of I/my/me. Looks like they grew from personal modules and personal articles. Perhaps the official documentation needs more depersonalized style. Here is full list of such files:
Doc/c-api/exceptions.rst
Doc/c-api/long.rst
Doc/distutils/builtdist.rst
Doc/extending/extending.rst
Doc/extending/windows.rst
Doc/howto/argparse.rst
Doc/howto/curses.rst
Doc/howto/functional.rst
Doc/howto/regex.rst
Doc/howto/sockets.rst
Doc/howto/urllib2.rst
Doc/install/index.rst
Doc/library/audioop.rst
Doc/library/ctypes.rst
Doc/library/doctest.rst
Doc/library/heapq.rst
Doc/library/numbers.rst
Doc/library/ossaudiodev.rst
Doc/library/tk.rst
Doc/library/unittest.mock-examples.rst
Doc/library/unittest.mock.rst
Doc/reference/introduction.rst
Doc/tutorial/classes.rst
The list doesn't include FAQs where it may be appropriate and whatsnew files.
Andrew Kuchling recently has fixed Doc/howto/unicode.rst for this issue (as part of issue4153).
----------
assignee: docs@python
components: Documentation
messages: 191636
nosy: akuchling, docs@python, eric.araujo, ezio.melotti, georg.brandl, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Documentation is too personalized
versions: Python 2.7, Python 3.3, Python 3.4
_______________________________________
Python tracker
Serhiy Storchaka added the comment:
Here is a filtered results of
find * -name '*.rst' -exec egrep -n -w -B1 -A1 'I|me|my' '{}' +
----------
Added file: http://bugs.python.org/file30665/Imemy.grep
_______________________________________
Python tracker
A.M. Kuchling added the comment:
I've looked through the matches. "I/O" and the -I command-line switch are false positives. Many references in the FAQ ("How do I do X?"), but those don't need to be fixed.
I think personalized references are most problematic when they're expressing uncertainty ("I don't know if we implement all of the spec") or opinions. Sentences like "When I run this command under Linux, I see..." could be rewritten as "When *you* run this command...", but they don't seem worth fixing to me.
Files with personalized text are:
c-api/exceptions.rst
c-api/long.rst
distutils/builtdist.rst
extending/extending.rst
install/index.rst
library/audioop.rst
library/ctypes.rst
library/doctest.rst
library/heapq.rst
library/imaplib.rst
library/numbers.rst
library/ossaudiodev.rst
library/unittest.mock-examples.rst
library/unittest.mock.rst
reference/introduction.rst
tutorial/classes.rst
----------
_______________________________________
Python tracker
Terry J. Reedy added the comment:
I find some anonymous I references (Guido? 20 years ago?) off-putting when reading the doc as formal reference.
----------
nosy: +terry.reedy
_______________________________________
Python tracker
Antoine Pitrou added the comment:
The sockets tutorial deserves a good overhaul :-)
----------
nosy: +pitrou
_______________________________________
Python tracker
Changes by A.M. Kuchling
Cheryl Sabella added the comment:
Would it be OK for me to tackle this?
----------
nosy: +csabella
_______________________________________
Python tracker
Raymond Hettinger added the comment: Fred, do you want to opine on this? In some cases, like heapq.py, the personal touch is an essential and beautiful part of the presentation and is a cherished part of Python. In other cases, it seems unnecessary or a little off-putting, so perhaps a few changes are warranted. Personally, I've grown to really dislike the incessant stream of proposals to make broad sweeping trivial changes across the code or documentation to fix made-up problems (ones not reported or cared about by actual users). In particular, I worry about sending some new dev on a mission to rewrite documentation that was written by domain experts (Alex Martelli reported that copy-editors "wreaked havoc" on one of his books just prior to publication by subtly changing the meaning or correctness of his prose while applying grammar rules and minor style edits -- I wish to avoid the same for us). Also, I place high value on text written by Guido and think we lose something every time someone wants to rewrite it to fit their personal tastes and views of the language. The tastes and views of module authors are more important are easily lost in style edits (especially those that change point of view, mood, or theme of presentation). Another thought is that there should be different general rules for different sections. The standard library docs tend to be more formal. The language reference tends to be even more formal ("for language lawyers"). The tutorial tends to be personable. The how-to guides are often have a personal touch and are the only places where we attribute authorship back individuals (actual by-lines at the top of the file). [Cheryl Sabella]
Would it be OK for me to tackle this? You could, but I would really like to get you involved in more substantive work that involves thinking about real issues and real code. IMO, this project isn't worthy of you time and is not on the critical path to your stated goals. That said, feel free to volunteer for anything that interests you.
----------
assignee: docs@python -> fdrake
nosy: +fdrake, rhettinger
versions: +Python 3.7 -Python 2.7, Python 3.3, Python 3.4
_______________________________________
Python tracker
Matej Cepl
Guido van Rossum
Michael Felt
Serhiy Storchaka
You should use two spaces after a sentence-ending period in multi- sentence comments, except after the final sentence.
You must adhere to the Emacs convention of adding two spaces at the end of every sentence.
AFAIK in English typography the space after a sentence-ending period is longer than spaces between words. In other European typographies they have the same width.
----------
_______________________________________
Python tracker
Michael Felt
Serhiy Storchaka
added the comment: I think they are not required, but recommended.
You should use two spaces after a sentence-ending period in multi- sentence comments, except after the final sentence.
You must adhere to the Emacs convention of adding two spaces at the end of every sentence.
AFAIK in English typography the space after a sentence-ending period is longer than spaces between words. In other European typographies they have the same width.
I thought it was where type setters, classically, used the break between the endings of a sentence - additional 'kerning' could be applied there. Anyway - final question: does .rst reformat line-lingths, or does it present everything literally - only adding ``embellishments``. I have been thinking it does both - and, yet another convention for sentence endings is to always start a sentence on a new line (and two new-lines indicate start of a paragraph. However, for now - double-spaces will remain - and I hope to remember to add my own :)
----------
_______________________________________ Python tracker
https://bugs.python.org/issue18280 _______________________________________
----------
_______________________________________
Python tracker
Change by Raymond Hettinger
Change by Matej Cepl
Change by Michael Felt
Jim Jewett
Change by Georg Brandl
participants (11)
-
A.M. Kuchling
-
Antoine Pitrou
-
Cheryl Sabella
-
Georg Brandl
-
Guido van Rossum
-
Jim Jewett
-
Matej Cepl
-
Michael Felt
-
Raymond Hettinger
-
Serhiy Storchaka
-
Terry J. Reedy