[Pydotorg-redesign] webmaster email handling

[Steve Holden]

----- Original Message -----
From: "Richard Jones" <richard at mechanicalcat.net>
To: "Steve Holden" <sholden at holdenweb.com>; "Kevin Altis"
<altis at semi-retired.com>
Cc: <pydotorg-redesign at python.org>
Sent: Monday, April 14, 2003 5:47 PM
Subject: Re: [Pydotorg-redesign] webmaster email handling


> On Tue, 15 Apr 2003 01:27 am, Steve Holden wrote:
> > > 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 :-(
>
> As I mentioned, the webmaster alias could be pointed at the tracker too.
Or
> there could just be the webmaster alias with no web interface (which
> eliminates the problem of people mis-typing their email address ;)
>
I was simply interested in removing the step where someone has to manually
enter an issue which is received by email. If roundup already allows this
that's all we need.

>
> > 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:
>
> If that's all you need, then that's what you should implement :)
>
Well, naturally it isn't *all* we need, and the remainder appears to be some
sort of issue tracking, for which I imagine roundup will be suitable.

>
> > > 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.
>
> The specific need I am attempting to address here (let's call this the
Orginal
> Problem) is the current inability to know who is going to respond to a
query.
> This leads to:
>
> - multiple responses to a single query, or
> - no response as it's assumed that someone else is responding.
>
> I guess the difference between this system and the one I'm doing for
Common
> Ground is that at CG the resopondents (assignees) are paid to respond to
the
> issues, as opposed to the pydotorg webmaster alias which, as you
mentioned,
> involves "fish for an "interesting" or "easy" issue".
>
Indeed. That's why my putative database had a CGI interface allowing a
webmaster to claim an issue,  and another to list the unclaimed issues. If
roundup will dot he job, though, I am not suggesting we invent a new wheel
here - just make roundup use as pain-free as possible.

>
> > 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 ... :-)
>
> That requires more and accurate effort on the part of the user, and I
don't
> think you're going to get it ;)
>
It also requires a lot of (most likely unnecessary) programming. Your
[apparent] failure to recognise irony makes me suspect I should have added a
smiley before.

>
> > > 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?
>
> Again though, without including more manual processes for the webmasters,
how
> does this solve our Original Problem?
>
I'm assuming that the Python webmasters, being a well-motivated but
frequently busy bunch, will eventually claim any issue that's significant to
the Python community. Many issues could be closed immediately on the basis
that the auto-responded will provide an adequate reply.

If this turned out not to be the case, *then* we could go for automated
issue assignment, but frankly ot sounds like a nightmare to me - both
socially and logistically.

>
> > > 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.
>
> What happens to messages the user sends back in response to an webmaster
> reply? Thrown in the bin? As far as they're concerned, they're just adding
> further commentary. Roundup just handles that by reopening the issue and
> passing the new message on to the issue's nosy list.
>
Well, if roundup puts an identifying code in the subject line I'm sure the
email extracter could recognise it as a followup, but that would certainly
make the database work more complicated.
>
> > 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
>
> This was just my attempt to address the issues you have with the current
> system. Please feel free to disregard it and come up with your own
solution
> :)
>
Well, I value the input from someone with hard roundup experience, and I'm
grateful that you've bothered to take the time to describe a possible modus
operandi. This was supposed to be discussion, not criticism!

I'm just trying to suggest that any pydotorg webmaster system should be kept
as lightweight as possible. If roundup already does everything you describe
then I guess the only additional work for me is going to be reassigning all
the tasks I don't want and/or don't have time for.

At present the biggest failing is that some issues get picked up multiple
times, and some don't get picked up at all. Once that problem is solved
(however it is solved) I imagine we'll be able to take our time over further
refinement.

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/