Improving the documenting process.

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Improving the documenting process.

Laura Creighton
Chad suggested I post this reply to him back to doc-sig, and see
if there are others like me who think that the python documentation
problem centres around 'not enough good documentation being
produced' and a process that is opaque, has bottlenecks, and
excludes the very people who would be best at writing good
documentation, because they aren't python-language developers.

I thought to shorten it, and then thought, what the heck,  maybe
some other people would be interested in what I was doing in the 80s.
Sorry that this will bore some others.

Happy New Year,
Laura
------- Forwarded Message
Laura Creighton wrote:

> In a message of Sat, 31 Dec 2005 22:13:02 EST, Chad Whitacre writes:
>
>>Laura,
>>
>>Thanks for giving me an opportunity to clarify my proposal.
>
>
>>On the other hand, I confess that I don't follow your suggestion that
>>separation of "logical" and "rendered" information leads to a plain text
>>base format, one without any markup. Why exclude markup that is semantic
>>rather than presentational?
>
>
> Oh yes.  This may not be well-known.  I keep forgetting.
>
> Because authoring is an art.  What you need are tools that support
> the process of composing excellent prose. All of the structural
> markup greatly hinders the process.  In exactly the same way that
> all the curly-braces-and-semi-colon junk in languages we know and
> hate, all there for the benefit of the compiler, detract from writing
> well.  The more intrusive the markup, the worse the prose.  (Which
> has been measured in places like the lab I worked in in the 80s.)
>
> There is still hot debate in some circles as to exactly why this is
> so, but the prevailing theory is that good prose is dependant on using
> the part of your brain that listens.  So most people really have to
> 'hear the words in their heads' as they write in order to create the
> best prose.  (And some do not.  Why this is so is unknown.)  But when
> they start fiddling around with the presentation details at the same
> time as they are writing the text in first place, their attention is
> divided and the texts are significantly worse.
>
> So, when we stuck people into our labs and measured them, our standard
> for 'how people write' was 'using emacs or vi and the MS macro
> packages for troff'.  And it was clear that people were producing
> pretty rotten texts.  So we measured how well they wrote if they
> just used vi or emacs, and skipped the markup.  And for most people
> this produced a significant improvement.  At this point, believing I
> was onto something, I went out and founded a computer company, SoftQuad,
> with a bunch of friends of mine in the publishing business.  Device
> Independent Troff was new, laser printers were new,  bitmapped displays
> were new, and Apple was promising this thing called the Macintosh.  We
> thought that we had the killer app.  A WYSIWYG editor, though I don't
> think we called it that.  Without evidence, we were convinced that we
> knew why it was that people wrote poorer text when using troff, and
> that had to do with it being hard to use the macro packages.
>
> And this goes to show that 'it ain't the stuff you don't know but
> the stuff you know that ain't so' that really hurts you.  Because this
> was one of the more spectacular cases of 'completely getting it wrong'.
> We made an editor (actually two -- a moded one which we gave the vi
> bindings and a modeless one which we gave the emacs bindings) and then
> took our usual suspects of university students in the humanities who
> already knew vi or emacs and had them go at it.
>
> They were very happy to not have to learn the MS macro set.  But to our
> dismay, the prose still ended up rotten.  We'd solved the wrong problem.
> And the very best results were still being had by authors that used
> whatever text editor they liked best to compose text, and then handed
> the work to somebody else -- a compositor if they were dealing with
> our Dead-Tree-Printing Office, or the secretaries of the Political
> Economics department if you were a student or a professor there.
> Making the thing look good on paper -- or on the screen, was then
> somebody else's job.  But even if you composed the text first, and
> then made a second pass after you got the text down correct you would
> end up with a better result than if you composed and composited
> simultaneously.    Next we discovered that most people wrote better
> if they wrote with somebody else. (For non-fiction.  For fiction we
> couldn't come to any conclusions except that we needed to study the
> cognitive process of writing fiction more.) On the other hand, documents
> designed by committee almost never were well written unless the
> committee met, decided on the structure of the document and what
> its content was to be, and then let one or two people actually write
> the thing.
>
>
>>Also, you hint that it might be helpful to define the problem itself
>>more clearly, and I agree. The problem I want to see solved is
>>Fredrik's: how do we cut the documentation workflow cycle down from 3-6
>>months to, say, 3-6 days?
>
>
> This is a fine goal.  But I think our problem is that we do not have
> enough high-quality documentation, and that the people who find problems
> with the documentation do not have an easy way to discuss this with
> other people who are interested.  Submitting a bug report only means
> that people who are reading the bug tracker get to be informed.  This
> excludes the bulk of interested people.  
>
> If you haven't read the Kruger Dunning Report _Unskilled and Unaware of It_
> http://www.apa.org/journals/features/psp7761121.pdf I suggest you go read
> it now.  It applies with particular vengeance to authoring skills, most
> especially in people who are writing in their native language.  Ability
> in language usage it not particularly bell-curved.  Both ends have
> relatively large numbers when compared to the population at large.  
> Excellent writing ability is something that people have selected for
> to such an extent that the right end is greatly increased, while
> non-native speakers, and people with learning disabilities end up making
> the left end chunkier as well.
>
> Which sadly means that the it is not just the lowest octile of language
> users who lack the cognative abilities to judge their performance.  In
> our labs we found it remarkably easy to produce samples of people where
> 80% of the people in the room did not write very well, according to the
> judgement of the top 2%, but nearly all of that 80% believed that they
> wrote 'rather well'.
>
> This makes the whole process of criticise-and-rewrite even harder than
> it already is, which is hard enough in the first place, and makes a
> bug tracker a particularly difficult place to raise your issues. There
> is no particular good way to say 'could I have a different python
> developer to discuss this with?  This one is not skilled enough to
> understand me'.  The more confused you are, and the harder time you
> have expressing and understanding your confusion, the worse it becomes.
> (It is hard on the unskilled python developer, as well.  He really has
> no way to tell the difference between things he cannot understand because
> he lacks the skills, and things he cannot understand because the person
> who posted the idea lacks the skills, and plain old bad ideas.)
>
> One of the more frustrating things that I have seen happen again and again
> is where some new person, who doesn't understand how to do something,
> complains about the documentation.  All too often the response that this
> person gets centres around 'explaining to the newbie how the code
> really works and how the newbie should have solved his problem'.  This
> drives the newbie, who already has solved his problem up the wall.
> He doesn't want help in learning things, he wants different and
> better documentation.
>
> He may even have a fix.  But the fix is often going to be poor.  It
> may solve this problem, but it leaves things more confusing for others
> in some way.  This does not mean that the existing documentation is
> adequate.  It means that somebody who is both aware of the code
> involved, and who is aware of the newbies problems in comprehension,
> needs to rewrite the documentation.
>
> Now it may be that such people are rare in general.  I think they are
> rarer among computer progammers than in the population at large.  But
> I think that our structure exacerbates our problem.  If you re-read
> http://mail.python.org/pipermail/doc-sig/2005-December/003466.html
> you will see Fred Drake assert that:
>
>  'comments from the release X.Y.Z docs need to be handled before
>   releasing X.Y.Z+1 or X.Y+1.*, or they aren't being used to improve
>   the documentation at all'
>
> which is either trivially true, or the indication of a larger problem.
> This looks to me as if documentation releases are delayed until every
> (a large number? enough?) comments are handled, which strikes me
> as a very large bottleneck.  Wikipedia is proving that you can do
> continuous updates on documentation.  Do we need them?  Would we
> get more people working on improving the documents if the live
> version was a mediawiki?
>
> I think the question of 'what do we need in order to share and
> collaboratively work on documents more effectively' is the one that
> we need to solve if we want more rapid turnover.  So I would say
> that our workflow doesn't need _shortening_ so much as _transforming
> altogether_.  And I don't think I understand exactly all the steps
> we have now, so it would be nice if somebody who knows this very well
> would post them.  Then we could analyse them, and see why it is that
> we perform the way we do.
>
> Laura
------- End of Forwarded Message

_______________________________________________
Doc-SIG maillist  -  [hidden email]
http://mail.python.org/mailman/listinfo/doc-sig
Reply | Threaded
Open this post in threaded view
|

Re: Improving the documenting process.

Nick Coghlan
Laura Creighton wrote:
>> I think the question of 'what do we need in order to share and
>> collaboratively work on documents more effectively' is the one that
>> we need to solve if we want more rapid turnover.  So I would say
>> that our workflow doesn't need _shortening_ so much as _transforming
>> altogether_.

Something which hasn't come up so far is the difference in the nature of
coupling between code and documentation.

When code is broken, the right place and right way to fix it is usually (not
always) fairly obvious. When it isn't obvious, that's one of the things
python-dev is for: discussing where and how the problem should be addressed.

For documentation, the free-form nature of the prose means that there are
*many* right ways, meaning discussion is necessary much more often. The
current setup is *not* geared towards facilitating that discussion and
bringing it to a close (indeed, I believe it makes it difficult to get the
discussion going in the first place).

>>  And I don't think I understand exactly all the steps
>> we have now, so it would be nice if somebody who knows this very well
>> would post them.  Then we could analyse them, and see why it is that
>> we perform the way we do.

Even with the updates Trent and Neal have made to automate the documentation
update and posting process, it's still fairly disjointed.

   a. Someone tries to figure out why some code of theirs isn't working by
looking at the documentation. We'll assume they eventually find the answer,
but they think a simple tweak to the "most obvious place" would have made
their search much simpler [1].

   b. The online doc page they're looking at contains no obvious link
regarding where to send comments on that page. There is only a little "about
this document" link squirreled away in the footnotes.

   c. We'll assume our potential contributor has found that little note, and
has gone to the about page [2].

   d. General questions/comments are directed towards the email address
"[hidden email]". I'm not sure *who* ends up getting those, but I'm a little
surprised it doesn't simply redirect to "[hidden email]". (I could be
wrong here - it may actually do this already, or else it may go to the doc-sig
moderators for approval before being sent on to the wider list).

   e. If our submitter has an SF account, they may go to SF and log a bug
report (and possibly even attach some suggested text). Again, however,
discussion is *not* facilitated - the SF bug tracker UI bites, even for
discussing code changes, let alone changes to documentation prose.

Other things that are missing in terms of facilitating dicussion:
   - documentation pages don't have associated comments, making it difficult
for users to see what observations have already been made regarding particular
pages, and making it harder to review comments in light of the original text
(there's a significant disjoint between the email of SF tracker comment and
the original documentation text - source code at least has the luxury of
filenames and line numbers as an indexing system).
   - domain experts can't subscribe just to areas of particular interest to
them, in order to be automatically notified when changes are made or comments
are added to those specific areas

I think Laura is right in saying that the semantic and layout markup is a side
issue - those are really there to aid the toolchain, more so than to aid the
end user.

Wiki's (particularly full-featured ones like MediaWiki or Atlassian's
Confluence, which permit comments that are separate from the main text of the
wiki page) are designed not only to allow collaborative production of content,
but also to facilitate discussion about and review of that content. And it's
that latter part we currently seem to be struggling with.

Cheers,
Nick.

[1] Step a. isn't helped by the surfeit of documentation URL's at python.org:
   docs.python.org (last stable release)
   www.python.org/doc ()
   docs.python.org/dev (new automatically built docs)
   www.python.org/dev/doc/devel (manually updated development version)
   www.python.org/dev/doc/maint24 (manually updated 2.4 maintenance version)

     Also, only www.python.org/doc seems to provide access to old versions.
The obvious "docs.python.org/2.4.2" doesn't work, but
"www.python.org/doc/2.4.2" does.
     Lastly, the index page from the actual documentation set (which I find
quite pleasant and easy to read) is done away with for the stable versions of
the documentation, replacing it with a python.org page that uses a simple
list, rather than the clean tabular layout of the actual index page.

[2] http://docs.python.org/dev/lib/about.html

--
Nick Coghlan   |   [hidden email]   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org
_______________________________________________
Doc-SIG maillist  -  [hidden email]
http://mail.python.org/mailman/listinfo/doc-sig
Reply | Threaded
Open this post in threaded view
|

Re: Improving the documenting process.

Chris Jerdonek
In reply to this post by Laura Creighton
On Jan 2, 2006, at 5:17 PM, Laura Creighton wrote:

> Chad suggested I post this reply to him back to doc-sig, and see
> if there are others like me who think that the python documentation
> problem centres around 'not enough good documentation being
> produced' and a process that is opaque, has bottlenecks, and
> excludes the very people who would be best at writing good
> documentation, because they aren't python-language developers.

I really appreciate reading the thoughts Laura has expressed over the
last couple e-mails.

I've only been on this list for about a week.  I'm in the camp of not
being a python-language developer, but I can't say yet whether this
qualifies me as being good at writing documentation...

Some thoughts below.

>> Next we discovered that most people wrote better
>> if they wrote with somebody else. (For non-fiction.  For fiction we
>> couldn't come to any conclusions except that we needed to study the
>> cognitive process of writing fiction more.) On the other hand,
>> documents
>> designed by committee almost never were well written unless the
>> committee met, decided on the structure of the document and what
>> its content was to be, and then let one or two people actually write
>> the thing.
>> ...
>> Wikipedia is proving that you can do
>> continuous updates on documentation.  Do we need them?  Would we
>> get more people working on improving the documents if the live
>> version was a mediawiki?

The contrast here is interesting.  Do these observations conflict in
any way?  Do wikis have more or less in common with "writing by
committee"?

I wonder how wiki documentation compares to the best
individually-written Python documentation -- if the style gets
watered-down in the community process at all, and whether this
dissuades any writers.

>> I think the question of 'what do we need in order to share and
>> collaboratively work on documents more effectively' is the one that
>> we need to solve if we want more rapid turnover.

Backing up here, how does the documentation group judge success, or
what is its purpose?  Is it about creating an authoritative manuscript,
or facilitating learning by more people?

Also, there's one thing I'm still confused about.  Where do people fit
in who are interested in creating documentation for a specialized
Python module that's not part of Python's core?  Ideally, would the
documentation group supply and empower that person with the tools
needed to write and disseminate documentation on their own, or would
they become de facto members of the Python documentation group,
contributing to the official body of Python documentation (albeit to a
small corner of it)?

--Chris

_______________________________________________
Doc-SIG maillist  -  [hidden email]
http://mail.python.org/mailman/listinfo/doc-sig
Reply | Threaded
Open this post in threaded view
|

Re: Improving the documenting process.

David Priest
On 2-Jan-06, at 8:03 PM, Chris Jerdonek wrote, in part:
> I wonder how wiki documentation compares to the best
> individually-written Python documentation -- if the style gets
> watered-down in the community process at all, and whether this
> dissuades any writers.

Using the wiki for documentation will only work well if there is a  
structure for allowing a select group of editorial assistants to  
control the "Real Documentation" (as opposed to the marginalia/
discussion/questions/suggestions/etc part that would be somehow  
closely related to the "Real" -- perhaps via a Talk page, a la  
Wikipedia; perhaps via some Plone-like construct.)

In other words, we need a way that presents the official, well-
written, well-presented material *separate* from the public noise;  
and we need editors who will actively take the good stuff from that  
noise and use it in improving the official text.
_______________________________________________
Doc-SIG maillist  -  [hidden email]
http://mail.python.org/mailman/listinfo/doc-sig
Reply | Threaded
Open this post in threaded view
|

Re: Improving the documenting process.

Michael Foord
David Priest wrote:

> On 2-Jan-06, at 8:03 PM, Chris Jerdonek wrote, in part:
>
>>I wonder how wiki documentation compares to the best
>>individually-written Python documentation -- if the style gets
>>watered-down in the community process at all, and whether this
>>dissuades any writers.
>
>
> Using the wiki for documentation will only work well if there is a  
> structure for allowing a select group of editorial assistants to  
> control the "Real Documentation" (as opposed to the marginalia/
> discussion/questions/suggestions/etc part that would be somehow  
> closely related to the "Real" -- perhaps via a Talk page, a la  
> Wikipedia; perhaps via some Plone-like construct.)
>
> In other words, we need a way that presents the official, well-
> written, well-presented material *separate* from the public noise;  
> and we need editors who will actively take the good stuff from that  
> noise and use it in improving the official text.

I've been resisting replying to this thread, because I don't want to
just add more noise. However I think we *can* sort the workflow, and
that is a different question to what markup format is used.

I think that in order to improve documentation, encourage more
contribution, and get that contribution into the final docs we need :

1) An online system for contributing changes in *any markup* [#]_
2) Editors who take responsibility for specific areas of the documentation
3) Assistance for editors who need help turning user comments into LayTeX

I'm not just adding noise here - I'm happy to help by taking on
responsibility for *some documentation* and evaluating user additions.

This means that (1) *ought* to email the person responsible when a new
comment is made. It *ought* to include a system for marking comments as
accepted or rejected. Possibly allowing the administrator for a section
of documentation to delete rejected comments will be enough.

It also needs a login system (simple) to reduce spam.

For the sake of simplicity I would suggest that when a new version is
released old comments are *not* automatically migrated. Either they fall
by the wayside and can be re-submitted, or the documentation maintainer
can add them. An admin interface to allow migrating of comments from old
docs to new docs would be nice - but may or may not ever happen...

To facilitate (2) *someone* needs to break the documentation down into
areas and we need to sign up editors. They don't need to be the same
person who maintains the code. But they need to be approved by the BDFL
of the documentation (Fred L. Drake ?).

3) Can be done via this forum.

I hope this is helpful.

I'm sure we can use Ian Bickings commentary system as it stands - though
with the changes I've suggested above. (Some of which he's working on
anyway).

I'm happy to help, although I don't yet know LaTeX I do have writing
skills that I'd love to contribute.

This leaves markup as a separate question - but provides a good way of
getting user input to the docs. It's not really anything new, but let's
get it happening.

All the best,

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

.. [#] Actually we probably ought to restrict it to plain text, reST or
LayTeX.


> _______________________________________________
> Doc-SIG maillist  -  [hidden email]
> http://mail.python.org/mailman/listinfo/doc-sig
>
>
>

_______________________________________________
Doc-SIG maillist  -  [hidden email]
http://mail.python.org/mailman/listinfo/doc-sig
Reply | Threaded
Open this post in threaded view
|

Re: Improving the documenting process.

Chris Jerdonek
In reply to this post by Nick Coghlan
On Jan 2, 2006, at 8:00 PM, Nick Coghlan wrote:

>    d. General questions/comments are directed towards the email address
> "[hidden email]". I'm not sure *who* ends up getting those, but I'm a
> little
> surprised it doesn't simply redirect to "[hidden email]". (I could
> be
> wrong here - it may actually do this already, or else it may go to the
> doc-sig
> moderators for approval before being sent on to the wider list).

I sent a question about *creating documentation* to [hidden email] on
November 30, and got the below automatic message back.  I didn't get a
human response (Fred) until December 20 (though in fairness I didn't
send an additional e-mail after a week like the message says to).  I
still don't know the answer.

--Chris


This message is being sent in response to your message to the Python
documentation maintainers ([hidden email]).  Your message will
be handled by a human, but this message serves to answer the most
common questions sent to this address.

You will only receive this message if it has not been sent to you for
at least three months.

If your question is answered below, you may not receive an additional
message from the documentation maintainers.  If you feel the answers
below are not sufficient and you do not receive an additional response
within a week, please do send a note letting us know that your
question has not been properly answered, and be specific regarding
what additional information you are looking for.


   -Fred


Frequently Asked Questions about the Python Documentation
---------------------------------------------------------

   1.  Can I download HTML/PDF/PostScript versions of the docs?
   2.  Where can I download Python?
   3.  I can't unpack a downloaded copy on Windows; what should I do?
   4.  I can't unpack a downloaded copy on Mac OS; what should I do?
   5.  What can I use Python for?
   6.  How do I use module/function/whatever XXX?
   7.  What about JPython?
   8.  I found a bug in the documentation, who should I tell?
   9.  Can I get an algorithm to do THIS in language THAT?
  10.  How do I decode an XXX file from my email on a YYY computer?
  11.  Acrobat Reader won't print the PDF.  What's wrong?
  12.  Where can I find documentation in my native language?
  13.  Why is Python installed on my computer?


Answers to the Questions
------------------------

   1.  Can I download HTML/PDF/PostScript/<other> versions of the docs?

       Yes.  These are available via the Web and traditional FTP.  For
       Web access to the latest version, see:

          http://www.python.org/doc/

       For FTP access to the latest version and archives of previous
       versions, see:

           ftp.python.org:/pub/python/doc/

   2.  Where can I download Python?

       You can get Python in source form and as a Windows installer
       from the main Python website.  You can also find information
       about pre-built packages for other platforms there as well.

       Downloading information at the website is at the URL:

           http://www.python.org/download/

       The sources and Windows installer can be downloaded from the FTP
       site as well:

           ftp://ftp.python.org/pub/python/

   3.  I can't unpack a downloaded archive on Windows; what should I do?

       Make sure the archive was saved with the .tgz extension; you may
       need to watch carefully when telling the browser where to save
       the file, as the default may change the extension to .tar or
       even .exe.

       Once you're sure the file has the right extension, use a recent
       version of WinZip to upack the file (version 7.0 works).  Get
       WinZip from:

          http://www.winzip.com/

   4.  I can't unpack a downloaded archive on Mac OS; what should I do?

       Stuffit Expander 4.5 (and probably other versions) cannot handle
       the "tar" archive, although it can decompress it from the .tgz
       file.  Expander Enhancer, which you have to pay for, can handle
       the tar archive.

   5.  What can I use Python for?

       Python is a general purpose programming language.  See the
       Python home page at http://www.python.org/ for more information;
       introductory material is available at:

          http://www.python.org/doc/Intros.html

   6.  How do I use module/function/whatever XXX?

       Start by reading the documentation for XXX.  If the
       documentation doesn't make sense or seems incomplete, please
       file a specific bug report to [hidden email] (the
       address you sent your question to).  Otherwise, you probably
       sent your question to the wrong place (which does not preclude
       an answer, if I know it).

       If you're looking for examples or tutorial information on how to
       use a particular Python library component, check the Demo/
       directory of the source distribution or Windows installation;
       there might be an example.  If that doesn't help, point your Web
       browser to http://www.python.org/doc/ and look around; there may
       be a link to some interesting examples online.  After that, try
       searching the Python Web site at http://www.python.org/search/.

       If your question still hasn't been answered, you may send your
       query to the Python newsgroup (comp.lang.python) or the mailing
       list (see http://www.python.org/mailman/listinfo/python-list).
       If you'd rather not send you message to a public forum, you can
       try sending it to [hidden email].  (This is typically
       slower than sending your question to the public list, however.)

   7.  What about Jython and JPython?

       If your question is specific to Jython or JPython, you should
       consult the Jython website at:

          http://www.jython.org/

       Chances are very good that the person who answers questions
       posted to [hidden email] doesn't use Jython very often,
       and won't be able to give you a meaningful answer beyond "Look
       at the Jython website."  Sorry, I don't have *all* the answers!

   8.  I found a bug in the documentation, who should I tell?

       If you're reading this, you've found the right address!  Send
       all documentation bug reports to [hidden email].  If
       you prefer to use a Web-based reporting mechanism, you can use
       the bug database at http://www.python.org/python-bugs/.

   9.  Can I get an algorithm to do THIS in language THAT?

       If THAT is Python, look in the standard library.  If THAT isn't
       Python, use your favorite Internet search engine.

  10.  How do I decode an XXX file from my email on a YYY computer?

       I really, honestly do not know.  I don't even know why this
       question gets asked here.  Since I don't have a YYY computer,
       I couldn't even try a few things out for you.

  11.  Acrobat Reader won't print the PDF.  What's wrong?

       Adobe has reportedly admitted that there is a bug Acrobat Reader
       5.0 which causes it not to print at least some PDF files
       generated by pdfTeX.  This software is used to produce the PDF
       version of the Python documentation, and our documents
       definately trigger this bug in Acrobat Reader.  To print the PDF
       files, use Acrobat Reader 4.x, ghostscript, or xpdf.

       Information on ghostscript can be found at:

           http://www.ghostscript.com/

       Information on xpdf can be found at:

           http://www.foolabs.com/xpdf/

  12.  Where can I find documentation in my native language?

       There is a lot of contributed documentation in languages other
       than English.  Some of the documents are translations of English
       documents, and others were originally authored in other
       languages.  If we know about it, it will be listed at:

           http://www.python.org/doc/NonEnglish.html

  13.  Why is Python installed on my computer?

       We're increasingly seeing Python being installed on computers
       as delivered by vendors.  For more information on why, and
       whether it's safe to remove, see the "Why is Python Installed on
       my Computer?" FAQ, found at:

           http://www.python.org/doc/faq/installed.html

_______________________________________________
Doc-SIG maillist  -  [hidden email]
http://mail.python.org/mailman/listinfo/doc-sig