[Pydotorg-redesign] Re: Kevin Altis blog move

[Steve Holden]

----- Original Message -----
From: "Richard Jones" <richard at mechanicalcat.net>
To: "Kevin Altis" <altis at semi-retired.com>
Cc: <pydotorg-redesign at python.org>
Sent: Monday, April 14, 2003 8:24 AM
Subject: [Pydotorg-redesign] Re: Kevin Altis blog move


> [Note: I'm not on the -redesign mailing list... please CC me]
>
> On Mon, 14 Apr 2003 09:55 am, Kevin Altis wrote:
> > BTW, there is a thread on the pydotorg-redesign mailing list that is
> > relevant to you because roundup might solve the tracker problem the
> > python.org maintainers currently have with webmaster at python.org...
> >
> >
http://mail.python.org/pipermail/pydotorg-redesign/2003-April/000006.html
> >
> >
http://mail.python.org/pipermail/pydotorg-redesign/2003-April/thread.html
> >
> > If you are able to volunteer to get it going on python.org and help with
> > any use issues that would be helpful. We're trying to "clean house"
before
> > "redecorating" python.org. :)
>
> I could set something up using Roundup, sure. Just gimme a spec :)
>
> It'll be easier to set up than the pythonlabs tracker, which is still
needing
> more attention than I have to give, because it requires significantly less
> customisation work, and doesn't require a database migration from
sourceforge
> :) I also need to do something very similar for work, so there's a much
> higher chance I'll get it done ;)
>
> In terms of spec, I suppose the simplest thing to do would be to have:
>
> 1. a form on the website that submits a new issue to the tracker (capture
>    details of query and email address for responses) ... the webmaster
alias
>    could also be pointed at this system too, I suppose

It might be prefereable to use an email address: if we can have receipt of
the mail at the webmaster address create the issue automatically then half
the battle is won. Requiring people to fill out a CGI from isn't helpful in
terms of user interface, since the less they know the more likely they are
to email webmaster anyway, and a response asking them to enter an issue in a
tracking system wouldn't be a good system :-(

It's really easy to store incoming mail in a database, as the following
example code (currently running in test mode on a local 2.2.1) shows:

#!/usr/bin/python

import email
import sys
parser = email.Parser.Parser()
msg = parser.parse(sys.stdin)
msgtxt = str(msg)
sys.stderr = sys.stdout = out
import MySQLdb
cn = MySQLdb.connect(host="localhost", db="test")
cu = cn.cursor()
cu.execute("INSERT INTO mt (msg) VALUES(%s)", (msgtxt, ))
cn.close()

> 2. on submission, the tracker:
>    - picks a random webmaster user (weighted by # of assigned issues) to
>      assign the issue to (that user automatically gets emailed a copy of
>      the query), and
>    - sends a form-letter to the user acknowledging the issue (/dev/null
reply
>      address)

Seems to me this is cimplicating the issue unnecessarily [YAGNI]. When a
Python user submits a bug on SF, there are no actions to assign the issue,
and I don't think there need to be for webmasters either. One of our main
problems is that different individual members of the group have rapidly
varying amount of time to commit to the webmaster tasks, so I'd much rather
fish for an "interesting" or "easy" issue in the outstanding list that be
forced to reject stuff I have neither the time nor the skills to handle.

Or, to complicate things still further, you could add an interface that lets
us say when we are prepared to accept webmaster assignments, and specify the
types of issue we are interested in ... :-)

> 3. a cron job checks for issues unanswered for 2 (or so) days and
reassigns
>    if necessary (new assignee gets the same query message sent to them)

Or: every day all webmasters are emailed with a list of outstanding issues?

> 4a. assigned user replies to the query message (which goes back to the
>     tracker) - the tracker closes the issue and forwards the reply to the
user
> 4b. assigned user manually closes or reassigns issue via web interface
> (5) optionally, the user responds to the message, and the issue is
reopened.
>     loop to 4.
>
>
The big drawback with the scheme I propose is keeping the loop closed at
step 5, but there's no reason why an email reply from the issue tracker
shouldn't contain a URL the user can follow to add further commentary.

Am I oversimplifying here, or can we really keep it simple and still have it
work? If the latter, I'd much prefer it. I dislike systems that send me work
:-)

regards
--
Steve Holden                                  http://www.holdenweb.com/
How lucky am I?      http://www.google.com/search?q=Steve+Holden&btnI=1
Python Web Programming                 http://pydish.holdenweb.com/pwp/