Bitching about the documentation...

[skip at pobox.com]

    >> This is why things need to go into public trackers, or wiki pages.

    François> Whatever means the maintainer wants to fill his preservation
    François> needs, he is free to use them.  The problem arises when the
    François> maintainer wants imposing his own work methods on others.

François, that's not it at all.  It's not our fault that SF doesn't support
email-based tracker interaction.  It's our fault that we chose SF, but it
was the best overall choice at the time (there were more considerations than
just bug tracking) and now we're sort of stuck with it because for a number
of reasons we've been unable to move away from it.

Here's the scenario we have to use today to collect emailed requests and put
them in SF:

* Kind user notices a problem and posts a message somewhere, maybe to c.l.py
  or to another Python-related list or by direct email to a developer.

* Someone - maybe nobody, but maybe more than one person - notices the
  request and thinks, "better add that to SF so it doesn't get lost".

* That person visits SF and submits a ticket.

Now, consider some of the problems this scheme is fraught with:

* Maybe nobody notices it at all.  It might have been buried deep in another
  thread that no Python developer happened to read in its entirety.  Bummer.
  It's been lost until the next time someone notices and posts a similar
  request.

* Maybe more than one person notices.  Bummer.  Now we have duplicates.
  Worse yet, some might have been posted as feature requests, some as bug
  reports.  It also may not be obvious that they are duplicate without
  careful checking.

* The multiple reports might contain different useful perspectives on the
  problem.  Bummer.  SF doesn't allow you to easily merge two requests.  You
  have to manually transfer the information from one to the other and close
  the one.

* Maybe the original post generates further responses in that venue that
  would have been useful to have with the original report.  Most will
  probably never find their way to the tracker.  Bummer.  They got lost.

* Maybe the original requester's email gets missed in the process (or the
  problem isn't addressed immediately and the user has discarded the
  original address because it's spammed so heavily and moved on to a new
  one) and the Python developers need more info but they can't contact the
  requester.  Bummer.  The problem isn't adequately addressed.

* Finally, instead of one person spending a couple minutes submitting a
  report, several people will have spent their volunteer time, and there's a
  good chance that the report is not any better (perhaps even worse) than if
  the original requester had simply submitted the request directly to SF.

I know, we have to take these steps occasion.  When bug reports have to be
moved from another tracker to the Python tracker some of these issues arise.
We've incorportated bug reports from the Debian bug tracker that way and
have migrated python-mode requests from the Python project to the
python-mode project (both on SF).  It can be a pain.

The Python developers are not being lazy.  I would love it if there was an
email interaction mode with the SF trackers, but there isn't.  I'll repeat
what I wrote yesterday in response to an earlier message in this thread:

    I wish either a) SourceForge supported email interaction with their
    trackers or b) someone would finish off the Roundup issue tracker
    <http://roundup.sourceforge.net/> for python.org.  I doubt if anyone
    here can do anything about the first barrier, but if you know something
    about Roundup (or would like to learn about it) and would like to
    contribute something non-documentational that would really have a
    direct, positive impact on the Python community, send a note to
    webmaster at python.org.

Skip