[Pydotorg-redesign] webmaster email handling

[Richard Jones]

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 ;)


> 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 :)


> > 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".


> 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 ;)


> > 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?


> > 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.


> 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 
:)


    Richard