From altis at semi-retired.com Tue Apr 1 11:53:39 2003 From: altis at semi-retired.com (Kevin Altis) Date: Tue Apr 1 14:50:21 2003 Subject: [Pydotorg-redesign] Python.org Website Redesign OpenSpace Message-ID: This mailing list is for continuing the python.org redesign discussions started at PyCon 2003. http://www.python.org/cgi-bin/moinmoin/PythonOrgWebsiteRedesignOpenSpace ka --- Kevin Altis altis@semi-retired.com From altis at semi-retired.com Tue Apr 1 14:47:40 2003 From: altis at semi-retired.com (Kevin Altis) Date: Tue Apr 1 17:44:19 2003 Subject: [Pydotorg-redesign] other web sites for reference Message-ID: Here are some sites to keep in mind as we go through our analysis phase. Feel free to suggest others that you think work particularly well or exhibit features that we should avoid. We can "steal" the good ideas for python.org and avoid the mistakes. http://www.php.net/ http://www.perl.org/ http://use.perl.org/ http://www.ruby-lang.org/en/ Horrible URL, at least we don't have that problem. http://www.apache.org/ http://www.postgresql.org/ Note that if you try and go to http://www.java.com/ you get redirected to: http://java.sun.com/getjava/ instead of http://java.sun.com/ http://www.microsoft.com/net/ http://www.macromedia.com/software/flash/ http://www.linux.org/ ka ps. Is that the "official Linux home page"? As someone who doesn't use Linux, I find it quite surprising. Not as bad as when you go to http://www.python.net/ and find no site, or go to http://python.net/ and get confused by the Starship, or go to python.com and find a porn gateway, but I digress ;-) From aahz at pythoncraft.com Fri Apr 4 15:41:51 2003 From: aahz at pythoncraft.com (Aahz) Date: Fri Apr 4 15:42:17 2003 Subject: [Pydotorg-redesign] FWD: Deobfuscating of bookmarks. Message-ID: <20030404204151.GA27586@panix.com> [Forwarded to pydotorg-redesign with cc to webmaster; anyone on webmaster who cares about issues like this should subscribe to the other list -- webmaster and pydotorg should be reserved for maintenance issues.] I've taken a quick look at some random pages, and while there's room for improvement, I'd say this should be low on our list of priorities -- we do pretty well on this. ----- Forwarded message from Chris W ----- > Date: Thu, 03 Apr 2003 21:30:12 -0600 > From: Chris W > To: webmaster@python.org > Subject: Deobfuscating of bookmarks. > > Thanks for taking the time to read my comments. I hope this doesn't > sound like arrogant presumption on my part, but you should seriously > consider making a change to your web site. As I am sure you are aware, > the text in the title tag of your web pages is what is used for the > title of any bookmark or favorites that are stored by users of your > site. It is my opinion that there is far too much superfluous text in > the title of web sites that make it harder for users to organize > favorites and find them later. Ideally this text should just be the > title of the business or organization. Let me give a quick example to > illustrate this point. Recently I have decided to get a private pilots > license. So I have been searching the web for pilot related web sites. > Below are listed a few of the sites I have found. > > Spinners Discount Pilot Shop > Pilot Shop World > My Pilot Store > Pilot Mall > The Pilot Shop > Chief Aircraft Inc. > > Now here is the list as they would appear if you set a bookmark to each > site. > > Pilot Supplies from Spinners Discount Pilot Shop - pilot supplies from > all the major manufacturers > Aviation pilot supplies from Pilot Shop World > Pilot Supplies Store - Shop for Aviation Pilot Supplies at My Pilot > Store .com > Pilot Mall Pilot Supplies and Equipment at the Aviation Superstore > Pilot Supplies from The Pilot Shop > Chief Aircraft Inc - Aircraft Parts, Avionics, Instruments, Pilot > Supplies, Art, Models > > One example that is not in this list is the custom of putting "Welcome > to" in front of a site name for the title. This makes a sorted list of > bookmarks almost useless. > > I don't know about you but I do a lot of business on the web, as well as > a lot of work and personal research. With all that time on the web, > I have over 2,000 bookmarks. If I don't keep them well organized, I > might as well start over at google and search for the sites again. > Having short, concise titles for my bookmarks makes it easier to keep > them organized and find the site I am looking for. Attention to simple > details like this make the Internet easier to use and more profitable. > > I wrote some code to send this message to every web site I have a > bookmark to, if your we bsite is one of the few that are done right, > please accept my apologies for taking your time, and thank you > for making my life easier by doing it right. > > -- > Chris Woodhouse > 3147 SW 127th St. > Oklahoma City, OK 73170 > 405-691-5206 > chrisw@programmer.net > N35? 20.492' > W97? 34.342' > > "They that can give up essential liberty > to obtain a little temporary safety > deserve neither liberty nor safety." > -- Benjamin Franklin, 1759 Historical Review of Pennsylvania > > ----- End forwarded message ----- From altis at semi-retired.com Sat Apr 5 10:15:41 2003 From: altis at semi-retired.com (Kevin Altis) Date: Sat Apr 5 13:12:32 2003 Subject: [Pydotorg-redesign] where are the time sinks in python.org maintenance? Message-ID: At the PyCon Open Space session, Aahz mentioned a number of items that took up the most time in managing python.org from job postings to requests to webmaster@python.org that should have been directed to comp.lang.python or help@python.org or python-tutor... It would be useful to have the pydotorg maintainers enumerate the issues here so we can keep them in mind. ka From altis at semi-retired.com Mon Apr 7 17:35:07 2003 From: altis at semi-retired.com (Kevin Altis) Date: Mon Apr 7 19:58:49 2003 Subject: [Pydotorg-redesign] redesign issues from marketing-python mailing list Message-ID: The following posts/threads from marketing-python mailing list are relevant to the redesign discussion. Rather than repost the messages in full, I'm just providing links. We should probably start new threads for each issue on this list. Please add a "What is Python?" button at top http://pythonology.org/pipermail/marketing-python/2003-March/001062.html alternate color scheme and job board posting that started the discussion http://pythonology.org/pipermail/marketing-python/2003-March/001090.html http://pythonology.org/pipermail/marketing-python/2003-March/001094.html what is Python and redesign ideas http://pythonology.org/pipermail/marketing-python/2003-March/001135.html consolidation of SIGs/Mailing lists pages http://pythonology.org/pipermail/marketing-python/2003-March/001136.html search on python.org http://pythonology.org/pipermail/marketing-python/2003-March/001137.html Thomas Wouters explaining wwwstats for python.org http://pythonology.org/pipermail/marketing-python/2003-March/001147.html ka From altis at semi-retired.com Thu Apr 10 14:13:26 2003 From: altis at semi-retired.com (Kevin Altis) Date: Thu Apr 10 16:10:31 2003 Subject: [Pydotorg-redesign] pytdotorg-redesign notes from PyCon Open Space session Message-ID: Some meeting notes from the python.org redesign Open Space session at PyCon 2003 http://www.python.org/cgi-bin/moinmoin/PythonOrgWebsiteRedesignOpenSpace Thanks to Evelyn Mitchell for providing her excellent meeting notes as the basis for this document. Any errors below were probably introduced by me and my imperfect memory ;-) Hopefully, this will help refresh our memories and get some sub-topic discussions going. I won't generally cross-post messages, so if you want to be involved in the python.org redesign, then join the mailing list. I consider making python.org better the top priority in our promotion efforts for reasons cited below. http://mail.python.org/mailman/listinfo/pydotorg-redesign ka --- Kevin Altis would like to see a 10x increase in the Python user-base in the next 2 years. Promoting Python leverage evangelism (what are the tenets of evangelism) website is very high visibility - don't have phone number or press contact I suggest that people interested in learning more about effective evangelism watch and read what Guy Kawasaki has to say on the subject. All of his books are quite readable, pretty short, and contain many amusing anecdotes. See the link below for more info; the signal to noise ratio is very good. [ka] http://pythonology.org/pipermail/marketing-python/2003-March/001124.html The main point about the website is that since we don't have traditional marketing and PR dollars, nor do we have normal phone and email contacts for people to get immediate answers about Python, the website needs to do that work for us. The site is the face of Python to the rest of the world. [ka] Who is the customer? people who don't use python today people who do use python today - information source lots of different types of customers identify use cases for groups of users We need to establish metrics track usage to ensure modifications that are improvements Adoption rate of python increase in traffic and new users of python By establishing some metrics in the web site stats such as total unique IP addresses, page views, and downloads per month, etc. we can see how our "popularity" is growing. Metrics should also tell us whether some of the "improvements" made to the site really did what we thought they would or ended up having a negative impact on usage. That way we aren't just guessing and modifying blindly. [ka] Not focused on technical solutions identify problems identify customers how are people using website what is missing what are websites we like (similar customer bases) At the Open Space, I didn't want to focus on the technical issues of implementing the site, but that conversation is okay to carry on in parallel here on the list. [ka] Kevin is comfortable with the site redesign process Product Mockups templates estimate work to estimate effort Before implementing any actual changes, we should make templates and mockups to get feedback before making the changes live. [ka] Current implementation problems No database backend I expect Aahz, Steve, Thomas, and other pydotorg maintainers to articulate the current problems they have maintaining the site, time sinks, and ideas for where we might make site maintenance easier and improve their lives. :) [ka] Make recommendations to current web maintainers and PSF members Process establish a working group empowered to make changes to the website the website is owned by PSF That's what this mailing list is about. [ka] Problems ownership of domain clarifying process to change website get authority delegated from PSF to implement changes Opportunities Recommendations 5-6 people balanced between management and implementation Where is the effort to do the work going to come from Ongoing management is required to ensure that maintenance on an ongoing basis gets done Behind job postings that don't get uploaded 50% of the mail to webmaster doesn't get answered webmaster workflow multiple responses Personnel Who is available to do work How much time do they have What are the skill sets Split off the PR effort from the language development effort Introducing Python Video done Appeal to the people who have the skills that are required Audience People who don't use python today recommendation from another source resource for further information Advanced developers defectors journalists who are trying to get more information Managers (tool selection) teachers python core team PythonLabs python contributors (community) newbies (programming newbies) non-programmers community of exiting python users job seekers event page books user group trainers What is python How do I start doing python Metrics identify customers python in business teaching/learning python then track traffic to the sub pages to discover customers wide diversity more general launching page home page is too complicated home page asking "what were you looking for. Did you find it" search - used to determine what they were looking form Analysis of search term metrics will be difficult because the access to the log is hard to get. We still have assets at CNRI seach.cnri Anyone interested in joining the python.org maintenance team Aahz says the team members are restricted to well known community members Give the appearance of needing help Give the appearance of being open to joining Look for volunteers Specific specialized areas of responsibility Python in education Kirby Urner for the edu-sig/Python in Education pages can be our test case of having page or section maintainers not directly involved in the maintenance of the rest of python.org. [ka] py.org experience Zope3 ht to html still works well Wiki Needs a strong editor Which maintenances take the most time Where is the time going now? job listings add a form to allow for posting jobs add a secure form to allow for removing jobs event listings add a form to allow for posting events broken links webmaster mail help@python.org ->tutor reflector (a static page of suggestions) Jeff Eppler to work with Steve to do the PyCon website Credit card donations Paypal ShareIt donate.python.org python.org needs a certificate 40% Documentation is the number one hit RDF file is also getting a lot of hits 750000 hits unique IPs in march 180,000 http://www.python.org/wwwstats Similar sites php.net mysql.com postgresql.org Web site computer resources are adequate for current needs 10% load on the machine hot backup could be provided Continuing the discussion PSF board meetings forming a subcommittee or group of volunteers to carry on the work downloads of documentation faster to have unified download page too confusing "Get Python Now" Make the download of documentation very straightforward Matrix of choices python.org SIG design mailing list -> next action reimplementing SIGs pythonology.org a good new user site only if the support of the pages will come from the original author From mats at laplaza.org Thu Apr 10 23:09:53 2003 From: mats at laplaza.org (Mats Wichmann) Date: Fri Apr 11 10:48:47 2003 Subject: [Pydotorg-redesign] Re: [marketing-python] pytdotorg-redesign notes from PyCon Open Space session In-Reply-To: Message-ID: <5.1.0.14.1.20030410220418.00a96830@mail.laplaza.org> >Behind > job postings that don't get uploaded > 50% of the mail to webmaster doesn't get answered > webmaster workflow > multiple responses Hmmm, not much of the first two now. Coordinated responses (item 3) are a bit of an issue, we talked some about using an issue tracker but most things would take more time to plug into the tracker than they take to handle on the spot. If people with /requests/ did the entering into the tracker it might work. >Personnel > Who is available to do work > How much time do they have > What are the skill sets Vast, of course :-) From fdrake at acm.org Fri Apr 11 11:54:41 2003 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Fri Apr 11 10:55:18 2003 Subject: [Pydotorg-redesign] [marketing-python] pytdotorg-redesign notes from PyCon Open Space session In-Reply-To: <5.1.0.14.1.20030410220418.00a96830@mail.laplaza.org> References: <5.1.0.14.1.20030410220418.00a96830@mail.laplaza.org> Message-ID: <16022.55089.238841.914694@grendel.zope.com> Mats Wichmann writes: > If people with /requests/ did the entering into the tracker it > might work. Of course, if there were a tracker that created issues from incoming emails, that would work like a charm. I'm certain this has been done before. ;-) I'm not familiar with what trackers are available that work like this, much less how to set them up, though. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From sholden at holdenweb.com Fri Apr 11 13:12:32 2003 From: sholden at holdenweb.com (Steve Holden) Date: Fri Apr 11 12:13:58 2003 Subject: [Pydotorg-redesign] Re: PyCon website References: <20030411153159.GB924@unpythonic.net> Message-ID: <035001c30045$29507cf0$5a00000a@holdenweb.com> I susp[ect this might have been athino for "Jeff Elkner" (the scholltaecher from Yorktown High). Not that I'd refuse help from you were you able to offer it :-) regards -- Steve Holden http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/pwp/ Did you miss PyCon DC 2003? Would you come to PyCOn DC 2004? ----- Original Message ----- From: "Jeff Epler" To: Cc: Sent: Friday, April 11, 2003 11:32 AM Subject: PyCon website > [I'm not a pydotorg-redesign subscriber, so please copy me on any replies] > > I just read on > http://www.python.org/cgi-bin/moinmoin/PythonOrgWebsiteRedesignOpenSpace > that "Jeff Eppler to work with Steve to do the PyCon website" > > Did I agree to do this while I was at pycon? I don't actually remember > doing so. I also don't think I was at this openspace session. > > Please remind me what I offered to do, so that I'm not leaving the > community in the lurch. > > feeling like a dork, > Jeff Epler (one 'P') > jepler@unpythonic.net > From jepler at unpythonic.net Fri Apr 11 11:32:00 2003 From: jepler at unpythonic.net (Jeff Epler) Date: Fri Apr 11 14:35:52 2003 Subject: [Pydotorg-redesign] PyCon website Message-ID: <20030411153159.GB924@unpythonic.net> [I'm not a pydotorg-redesign subscriber, so please copy me on any replies] I just read on http://www.python.org/cgi-bin/moinmoin/PythonOrgWebsiteRedesignOpenSpace that "Jeff Eppler to work with Steve to do the PyCon website" Did I agree to do this while I was at pycon? I don't actually remember doing so. I also don't think I was at this openspace session. Please remind me what I offered to do, so that I'm not leaving the community in the lurch. feeling like a dork, Jeff Epler (one 'P') jepler@unpythonic.net From mats at laplaza.org Fri Apr 11 11:12:22 2003 From: mats at laplaza.org (Mats Wichmann) Date: Fri Apr 11 14:36:07 2003 Subject: [Pydotorg-redesign] [marketing-python] pytdotorg-redesign notes from PyCon Open Space session In-Reply-To: <16022.55089.238841.914694@grendel.zope.com> References: <5.1.0.14.1.20030410220418.00a96830@mail.laplaza.org> <5.1.0.14.1.20030410220418.00a96830@mail.laplaza.org> Message-ID: <5.1.0.14.1.20030411101009.02950800@mail.laplaza.org> At 10:54 AM 4/11/2003 -0400, Fred L. Drake, Jr. wrote: > >Mats Wichmann writes: > > If people with /requests/ did the entering into the tracker it > > might work. > >Of course, if there were a tracker that created issues from incoming >emails, that would work like a charm. > >I'm certain this has been done before. ;-) I'm not familiar with >what trackers are available that work like this, much less how to set >them up, though. I've seen it work fine with several systems if people follow a submission template. I suppose something could just snarf up a piece of email to webmaster and save it as the body of the issue without processing, but I think without enforcing a template it's going to be pretty tough for it to be useful. And I don't see any way to enforce a template, "webmaster" is like "postmaster", it's an address that's expected to be there and people just send to it, free-form. From altis at semi-retired.com Fri Apr 11 12:57:13 2003 From: altis at semi-retired.com (Kevin Altis) Date: Fri Apr 11 14:54:21 2003 Subject: [Pydotorg-redesign] pytdotorg-redesign notes from PyCon Open Space session In-Reply-To: <5.1.0.14.1.20030411101009.02950800@mail.laplaza.org> Message-ID: > From: Mats Wichmann > > At 10:54 AM 4/11/2003 -0400, Fred L. Drake, Jr. wrote: > > > >Mats Wichmann writes: > > > If people with /requests/ did the entering into the tracker it > > > might work. > > > >Of course, if there were a tracker that created issues from incoming > >emails, that would work like a charm. > > > >I'm certain this has been done before. ;-) I'm not familiar with > >what trackers are available that work like this, much less how to set > >them up, though. > > I've seen it work fine with several systems > if people follow a submission template. I > suppose something could just snarf up a piece > of email to webmaster and save it as the > body of the issue without processing, but I > think without enforcing a template it's going > to be pretty tough for it to be useful. And > I don't see any way to enforce a template, > "webmaster" is like "postmaster", it's an > address that's expected to be there and > people just send to it, free-form. [Note that we probably shouldn't continue cross-posting to marketing-python, so I've taken that list off of this reply.] A typical help desk system would have some stock email reply templates with FAQ answers, links to the FAQ page, tutor list, and other places to get additional help. A web interface to the pending emails should allow any of the people on help desk duty to send a stock reply with a single click. A basic email can go out right away with some of the stock answers and an issue tracking number. If the person who sent the original email requires a follow-up, the issue tracking number in the reply can be used to look at their original question. If we expand the Help page http://www.python.org/Help.html to include a form then a bulleted list of say the top 10 questions and answers can be on the page. We can try that for a few months and see whether it reduces the incoming email burden. To some extent that's what the current Help page tries to do. Are the questions that come in actually answered on the Help page? Is there an online archive of old messages that can be scanned to look for common questions...? Is there an off-the-shelf solution we can use? I don't know. Anyone want to volunteer to do a bit of research? We have to accomodate the straight emails to help@python.org or webmaster@python.org... as well as submissions via a web page. ka From altis at semi-retired.com Fri Apr 11 13:28:19 2003 From: altis at semi-retired.com (Kevin Altis) Date: Fri Apr 11 15:25:24 2003 Subject: [Pydotorg-redesign] status of search engine upgrade? Message-ID: Prior to PyCon, Aahz said "Updates to python.org search capabilities are probably on hold until we install the Ultraseek upgrade." http://pythonology.org/pipermail/marketing-python/2003-March/001138.html Any status updates or timeline for this? ka From revanna at mn.rr.com Fri Apr 11 15:25:25 2003 From: revanna at mn.rr.com (Anna Ravenscroft) Date: Fri Apr 11 15:25:31 2003 Subject: [Pydotorg-redesign] pytdotorg-redesign notes from PyCon Open Space session In-Reply-To: References: Message-ID: <200304111425.25310.revanna@mn.rr.com> On Friday 11 April 2003 13:57, Kevin Altis wrote: > > From: Mats Wichmann > > > > At 10:54 AM 4/11/2003 -0400, Fred L. Drake, Jr. wrote: > > >Mats Wichmann writes: > > > > If people with /requests/ did the entering into the tracker it > > > > might work. > > > > > >Of course, if there were a tracker that created issues from incoming > > >emails, that would work like a charm. > > > > > >I'm certain this has been done before. ;-) I'm not familiar with > > >what trackers are available that work like this, much less how to set > > >them up, though. > > > > I've seen it work fine with several systems > > if people follow a submission template. I > > suppose something could just snarf up a piece > > of email to webmaster and save it as the > > body of the issue without processing, but I > > think without enforcing a template it's going > > to be pretty tough for it to be useful. And > > I don't see any way to enforce a template, > > "webmaster" is like "postmaster", it's an > > address that's expected to be there and > > people just send to it, free-form. > > [Note that we probably shouldn't continue cross-posting to > marketing-python, so I've taken that list off of this reply.] > > A typical help desk system would have some stock email reply templates with > FAQ answers, links to the FAQ page, tutor list, and other places to get > additional help. A web interface to the pending emails should allow any of > the people on help desk duty to send a stock reply with a single click. A > basic email can go out right away with some of the stock answers and an > issue tracking number. > > If the person who sent the original email requires a follow-up, the issue > tracking number in the reply can be used to look at their original > question. > > If we expand the Help page http://www.python.org/Help.html to include a > form then a bulleted list of say the top 10 questions and answers can be on > the page. We can try that for a few months and see whether it reduces the > incoming email burden. To some extent that's what the current Help page > tries to do. > > Are the questions that come in actually answered on the Help page? Is there > an online archive of old messages that can be scanned to look for common > questions...? > > Is there an off-the-shelf solution we can use? I don't know. Anyone want to > volunteer to do a bit of research? We have to accomodate the straight > emails to help@python.org or webmaster@python.org... as well as submissions > via a web page. AB Strakt has a helpdesk app that would probably handle this, programmed in Python. It's possible they'd be willing to do something like this... Someone would have to check with them - I'd suggest asking Laura Creighton about it. cordially, Anna Ravenscroft From guido at python.org Fri Apr 11 18:43:41 2003 From: guido at python.org (Guido van Rossum) Date: Fri Apr 11 17:47:17 2003 Subject: [Pydotorg-redesign] [marketing-python] pytdotorg-redesign notes from PyCon Open Space session In-Reply-To: Your message of "Fri, 11 Apr 2003 10:12:22 MDT." <5.1.0.14.1.20030411101009.02950800@mail.laplaza.org> References: <5.1.0.14.1.20030410220418.00a96830@mail.laplaza.org> <5.1.0.14.1.20030410220418.00a96830@mail.laplaza.org> <5.1.0.14.1.20030411101009.02950800@mail.laplaza.org> Message-ID: <200304112144.h3BLhnq04253@odiug.zope.com> > >Of course, if there were a tracker that created issues from incoming > >emails, that would work like a charm. > > > >I'm certain this has been done before. ;-) I'm not familiar with > >what trackers are available that work like this, much less how to set > >them up, though. > > I've seen it work fine with several systems > if people follow a submission template. I > suppose something could just snarf up a piece > of email to webmaster and save it as the > body of the issue without processing, but I > think without enforcing a template it's going > to be pretty tough for it to be useful. And > I don't see any way to enforce a template, > "webmaster" is like "postmaster", it's an > address that's expected to be there and > people just send to it, free-form. Entering each piece of free-form email in a tracker as a new issue shouldn't be hard, should it? Lots of commercial support systems do this. The people answering the queries interact via the tracker, the original poster sees email and can reply to it. A cookie in the subject can be used to match incoming email to the right issue. Someone, somewhere has probably already written this in Python. (Hm, maybe we should stop cross-posting to marketing-python?) --Guido van Rossum (home page: http://www.python.org/~guido/) From brichard at clusterworldexpo.com Fri Apr 11 16:08:45 2003 From: brichard at clusterworldexpo.com (Bryan J Richard) Date: Fri Apr 11 18:13:11 2003 Subject: [Pydotorg-redesign] [marketing-python] pytdotorg-redesign notes from PyCon Open Space session In-Reply-To: <200304112144.h3BLhnq04253@odiug.zope.com> References: <5.1.0.14.1.20030410220418.00a96830@mail.laplaza.org> <5.1.0.14.1.20030410220418.00a96830@mail.laplaza.org> <5.1.0.14.1.20030411101009.02950800@mail.laplaza.org> <200304112144.h3BLhnq04253@odiug.zope.com> Message-ID: <20030411190845.GC1750@clusterworldexpo.com> Sounds like you are talking about Roundup http://roundup.sourceforge.net/ E-Mail Gateway http://roundup.sourceforge.net/doc-0.5/user_guide.html#e-mail-gateway I'm not sure how up-to-date the docs are but simple issue creation via the email gateway is supported -- I've used it on a number of projects. - Bryan On Fri, Apr 11, 2003 at 05:43:41PM -0400, Guido van Rossum wrote: > > >Of course, if there were a tracker that created issues from incoming > > >emails, that would work like a charm. > > > > > >I'm certain this has been done before. ;-) I'm not familiar with > > >what trackers are available that work like this, much less how to set > > >them up, though. > > > > I've seen it work fine with several systems > > if people follow a submission template. I > > suppose something could just snarf up a piece > > of email to webmaster and save it as the > > body of the issue without processing, but I > > think without enforcing a template it's going > > to be pretty tough for it to be useful. And > > I don't see any way to enforce a template, > > "webmaster" is like "postmaster", it's an > > address that's expected to be there and > > people just send to it, free-form. > > Entering each piece of free-form email in a tracker as a new issue > shouldn't be hard, should it? Lots of commercial support systems do > this. The people answering the queries interact via the tracker, the > original poster sees email and can reply to it. A cookie in the > subject can be used to match incoming email to the right issue. > > Someone, somewhere has probably already written this in Python. > > (Hm, maybe we should stop cross-posting to marketing-python?) > > --Guido van Rossum (home page: http://www.python.org/~guido/) > _______________________________________________ > marketing-python mailing list > marketing-python@wingide.com > http://pythonology.org/mailman/listinfo/marketing-python > > -- Be well, Bryan J Richard Conference Director QuarterPower Media +(310) 648 0252 voice brichard@clusterworldexpo.com From altis at semi-retired.com Fri Apr 11 17:44:47 2003 From: altis at semi-retired.com (Kevin Altis) Date: Fri Apr 11 19:42:00 2003 Subject: [Pydotorg-redesign] case-insensitive URLs? Message-ID: Should we attempt to have case-insensitive URLs? It would be interesting to see how many of the 404 errors in the logs are due to people mis-typing URLs and missing the case. For example, trying to use usergroups.html instead of the correct CamelCase version of the URL. http://www.python.org/UserGroups.html I don't think this is a big deal, but I wanted to bring the point up in case we want some URL standards for python.org. ka From altis at semi-retired.com Fri Apr 11 17:47:13 2003 From: altis at semi-retired.com (Kevin Altis) Date: Fri Apr 11 19:44:20 2003 Subject: [Pydotorg-redesign] fixing error pages Message-ID: The stats for March 2003 http://www.python.org/wwwstats/usage_200303.html show a fairly large number of 404 errors (not found), 301s (moved permanently) and 403s (forbidden). Is there already a summary list of the URLs with referer page info for the errors that we can use to get the pages fixed? If not, I can work up a simple script if I can get access to the raw files. Perhaps this is already on the to do list of the pydotorg maintainers? ka From sholden at holdenweb.com Sat Apr 12 10:39:38 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Apr 12 09:42:13 2003 Subject: Fw: [Pydotorg-redesign] pytdotorg-redesign notes from PyCon OpenSpace session Message-ID: <00bc01c300f8$f8424d50$5a00000a@holdenweb.com> ----- Original Message ----- From: "Anna Ravenscroft" To: "Kevin Altis" ; "Mats Wichmann" ; "Fred L. Drake, Jr." Cc: "Pydotorg-Redesign" Sent: Friday, April 11, 2003 3:25 PM Subject: Re: [Pydotorg-redesign] pytdotorg-redesign notes from PyCon OpenSpace session > On Friday 11 April 2003 13:57, Kevin Altis wrote: > > > From: Mats Wichmann > > > > > > At 10:54 AM 4/11/2003 -0400, Fred L. Drake, Jr. wrote: > > > >Mats Wichmann writes: > > > > > If people with /requests/ did the entering into the tracker it > > > > > might work. > > > > > > > >Of course, if there were a tracker that created issues from incoming > > > >emails, that would work like a charm. > > > > > > > >I'm certain this has been done before. ;-) I'm not familiar with > > > >what trackers are available that work like this, much less how to set > > > >them up, though. > > > > > > I've seen it work fine with several systems > > > if people follow a submission template. I > > > suppose something could just snarf up a piece > > > of email to webmaster and save it as the > > > body of the issue without processing, but I > > > think without enforcing a template it's going > > > to be pretty tough for it to be useful. And > > > I don't see any way to enforce a template, > > > "webmaster" is like "postmaster", it's an > > > address that's expected to be there and > > > people just send to it, free-form. > > > > [Note that we probably shouldn't continue cross-posting to > > marketing-python, so I've taken that list off of this reply.] > > > > A typical help desk system would have some stock email reply templates with > > FAQ answers, links to the FAQ page, tutor list, and other places to get > > additional help. A web interface to the pending emails should allow any of > > the people on help desk duty to send a stock reply with a single click. A > > basic email can go out right away with some of the stock answers and an > > issue tracking number. > > > > If the person who sent the original email requires a follow-up, the issue > > tracking number in the reply can be used to look at their original > > question. > > > > If we expand the Help page http://www.python.org/Help.html to include a > > form then a bulleted list of say the top 10 questions and answers can be on > > the page. We can try that for a few months and see whether it reduces the > > incoming email burden. To some extent that's what the current Help page > > tries to do. > > > > Are the questions that come in actually answered on the Help page? Is there > > an online archive of old messages that can be scanned to look for common > > questions...? > > > > Is there an off-the-shelf solution we can use? I don't know. Anyone want to > > volunteer to do a bit of research? We have to accomodate the straight > > emails to help@python.org or webmaster@python.org... as well as submissions > > via a web page. > > AB Strakt has a helpdesk app that would probably handle this, programmed in > Python. It's possible they'd be willing to do something like this... Someone > would have to check with them - I'd suggest asking Laura Creighton > about it. > > cordially, > Anna Ravenscroft > Until we have something that stops us [webmaster@python.org] tripping up over each other to do stuff and communicate with non-spam enquiries, anything else is a YAGNI. The help-desk app might do this, I suppose. I therefore propose that someone write a program that receives messages and stores each one as a row in a relational database with status "unclaimed". A CGI script can easily display all unclaimed messages, and another could allow any user to claim a message. We could trust the community, Wiki-like, to report their own name, or we could more paranoidly require authentication. Until the list of uncliamed messages grows beyond what's reasonable to view in one page we might get away with very little else. I suppose a "completed" indication would be nice, and possibly timestamps on both status changes. Once you claim a message you don't have to own the task forever: simply forward it to the input mailing address again, with your added comments to assist the next claimer, and you're done. Who will do this work? Some YoungTurk [I'd do it as an OldFart, but us OldFart s get tired quickly, and must husband our resources to annoy mailing lists]. The first part shouldn't be too difficult. If someone with a bit of time could create a mail stream and put this in as a filter, all they otherwise need is a MySQL database with the foillowing table defined in it: +---------+---------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +---------+---------+------+-----+---------+----------------+ | id | int(11) | | PRI | NULL | auto_increment | | msg | text | YES | | NULL | | | claimed | int(11) | YES | | NULL | | | handled | int(11) | YES | | NULL | | +---------+---------+------+-----+---------+----------------+ Of course, what else the database might reasonably contain is the subject of another YAGNI discussion, so I'm not planning to take any further part in the debate until somebody (besides me) is succking these things into a database. -- 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/ From sholden at holdenweb.com Sat Apr 12 11:23:45 2003 From: sholden at holdenweb.com (Steve Holden) Date: Sat Apr 12 10:25:57 2003 Subject: [Pydotorg-redesign] pytdotorg-redesign notes from PyCon OpenSpacesession References: <00bc01c300f8$f8424d50$5a00000a@holdenweb.com> Message-ID: <00e501c300ff$21e6f330$5a00000a@holdenweb.com> Forgot: msgfilter.py: import email import sys parser = email.Parser.Parser() msg = parser.parse(sys.stdin) out = file("/tmp/emlog", "a+") msgtxt = str(msg) import MySQLdb cn = MySQLdb.connect(host="localhost", db="test") cu = cn.cursor() cu.execute("INSERT INTO mt (msg) VALUES(%s)", (msgtxt, )) cn.close() regards -- Steve Holden http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/pwp/ Did you miss PyCon DC 2003? Would you come to PyCOn DC 2004? ----- Original Message ----- From: "Steve Holden" To: "Laura Creighton" Cc: ; Sent: Saturday, April 12, 2003 9:39 AM Subject: Fw: [Pydotorg-redesign] pytdotorg-redesign notes from PyCon OpenSpacesession > ----- Original Message ----- > From: "Anna Ravenscroft" > To: "Kevin Altis" ; "Mats Wichmann" > ; "Fred L. Drake, Jr." > Cc: "Pydotorg-Redesign" > Sent: Friday, April 11, 2003 3:25 PM > Subject: Re: [Pydotorg-redesign] pytdotorg-redesign notes from PyCon > OpenSpace session > > > > On Friday 11 April 2003 13:57, Kevin Altis wrote: > > > > From: Mats Wichmann > > > > > > > > At 10:54 AM 4/11/2003 -0400, Fred L. Drake, Jr. wrote: > > > > >Mats Wichmann writes: > > > > > > If people with /requests/ did the entering into the tracker it > > > > > > might work. > > > > > > > > > >Of course, if there were a tracker that created issues from incoming > > > > >emails, that would work like a charm. > > > > > > > > > >I'm certain this has been done before. ;-) I'm not familiar with > > > > >what trackers are available that work like this, much less how to > set > > > > >them up, though. > > > > > > > > I've seen it work fine with several systems > > > > if people follow a submission template. I > > > > suppose something could just snarf up a piece > > > > of email to webmaster and save it as the > > > > body of the issue without processing, but I > > > > think without enforcing a template it's going > > > > to be pretty tough for it to be useful. And > > > > I don't see any way to enforce a template, > > > > "webmaster" is like "postmaster", it's an > > > > address that's expected to be there and > > > > people just send to it, free-form. > > > > > > [Note that we probably shouldn't continue cross-posting to > > > marketing-python, so I've taken that list off of this reply.] > > > > > > A typical help desk system would have some stock email reply templates > with > > > FAQ answers, links to the FAQ page, tutor list, and other places to get > > > additional help. A web interface to the pending emails should allow any > of > > > the people on help desk duty to send a stock reply with a single click. > A > > > basic email can go out right away with some of the stock answers and an > > > issue tracking number. > > > > > > If the person who sent the original email requires a follow-up, the > issue > > > tracking number in the reply can be used to look at their original > > > question. > > > > > > If we expand the Help page http://www.python.org/Help.html to include a > > > form then a bulleted list of say the top 10 questions and answers can be > on > > > the page. We can try that for a few months and see whether it reduces > the > > > incoming email burden. To some extent that's what the current Help page > > > tries to do. > > > > > > Are the questions that come in actually answered on the Help page? Is > there > > > an online archive of old messages that can be scanned to look for common > > > questions...? > > > > > > Is there an off-the-shelf solution we can use? I don't know. Anyone want > to > > > volunteer to do a bit of research? We have to accomodate the straight > > > emails to help@python.org or webmaster@python.org... as well as > submissions > > > via a web page. > > > > AB Strakt has a helpdesk app that would probably handle this, programmed > in > > Python. It's possible they'd be willing to do something like this... > Someone > > would have to check with them - I'd suggest asking Laura Creighton > > about it. > > > > cordially, > > Anna Ravenscroft > > > > Until we have something that stops us [webmaster@python.org] tripping up > over each other to do stuff and communicate with non-spam enquiries, > anything else is a YAGNI. The help-desk app might do this, I suppose. > > I therefore propose that someone write a program that receives messages and > stores each one as a row in a relational database with status "unclaimed". A > CGI script can easily display all unclaimed messages, and another could > allow any user to claim a message. We could trust the community, Wiki-like, > to report their own name, or we could more paranoidly require > authentication. > > Until the list of uncliamed messages grows beyond what's reasonable to view > in one page we might get away with very little else. I suppose a "completed" > indication would be nice, and possibly timestamps on both status changes. > > Once you claim a message you don't have to own the task forever: simply > forward it to the input mailing address again, with your added comments to > assist the next claimer, and you're done. > > Who will do this work? Some YoungTurk [I'd do it as an OldFart, but us > OldFart s get tired quickly, and must husband our resources to annoy mailing > lists]. > > The first part shouldn't be too difficult. If someone with a bit of time > could create a mail stream and put this in as a filter, all they otherwise > need is a MySQL database with the foillowing table defined in it: > > +---------+---------+------+-----+---------+----------------+ > | Field | Type | Null | Key | Default | Extra | > +---------+---------+------+-----+---------+----------------+ > | id | int(11) | | PRI | NULL | auto_increment | > | msg | text | YES | | NULL | | > | claimed | int(11) | YES | | NULL | | > | handled | int(11) | YES | | NULL | | > +---------+---------+------+-----+---------+----------------+ > > Of course, what else the database might reasonably contain is the subject of > another YAGNI discussion, so I'm not planning to take any further part in > the debate until somebody (besides me) is succking these things into a > database. > > -- > 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/ > > > > > _______________________________________________ > Pydotorg-redesign mailing list > Pydotorg-redesign@python.org > http://mail.python.org/mailman/listinfo/pydotorg-redesign > From aahz at pythoncraft.com Sat Apr 12 22:11:12 2003 From: aahz at pythoncraft.com (Aahz) Date: Sat Apr 12 21:11:16 2003 Subject: [Pydotorg-redesign] Issue tracking In-Reply-To: <00bc01c300f8$f8424d50$5a00000a@holdenweb.com> References: <00bc01c300f8$f8424d50$5a00000a@holdenweb.com> Message-ID: <20030413011112.GA6520@panix.com> On Sat, Apr 12, 2003, Steve Holden wrote: > > Until we have something that stops us [webmaster@python.org] tripping > up over each other to do stuff and communicate with non-spam > enquiries, anything else is a YAGNI. The help-desk app might do this, > I suppose. My take is that we should use Roundup, to help speed the day when we get off SourceForge. A limited group of beta testers is precisely what Roundup needs. Supposedly Roundup has an e-mail interface; haven't made the time to check it out. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ This is Python. We don't care much about theory, except where it intersects with useful practice. --Aahz, c.l.py, 2/4/2002 From richard at mechanicalcat.net Mon Apr 14 23:24:14 2003 From: richard at mechanicalcat.net (Richard Jones) Date: Mon Apr 14 11:00:17 2003 Subject: [Pydotorg-redesign] Re: Kevin Altis blog move In-Reply-To: References: Message-ID: <200304142224.15594.richard@mechanicalcat.net> [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@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 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) 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) 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. Richard From sholden at holdenweb.com Mon Apr 14 12:27:31 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Apr 14 11:29:56 2003 Subject: [Pydotorg-redesign] Re: Kevin Altis blog move References: <200304142224.15594.richard@mechanicalcat.net> Message-ID: <059e01c3029a$62f5a230$5a00000a@holdenweb.com> ----- Original Message ----- From: "Richard Jones" To: "Kevin Altis" Cc: 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@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/ From richard at mechanicalcat.net Tue Apr 15 08:47:25 2003 From: richard at mechanicalcat.net (Richard Jones) Date: Mon Apr 14 17:47:37 2003 Subject: [Pydotorg-redesign] webmaster email handling In-Reply-To: <059e01c3029a$62f5a230$5a00000a@holdenweb.com> References: <200304142224.15594.richard@mechanicalcat.net> <059e01c3029a$62f5a230$5a00000a@holdenweb.com> Message-ID: <200304150747.26843.richard@mechanicalcat.net> 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 From sholden at holdenweb.com Mon Apr 14 19:00:25 2003 From: sholden at holdenweb.com (Steve Holden) Date: Mon Apr 14 18:02:13 2003 Subject: [Pydotorg-redesign] webmaster email handling References: <200304142224.15594.richard@mechanicalcat.net> <059e01c3029a$62f5a230$5a00000a@holdenweb.com> <200304150747.26843.richard@mechanicalcat.net> Message-ID: <071a01c302d1$41cdc290$5a00000a@holdenweb.com> ----- Original Message ----- From: "Richard Jones" To: "Steve Holden" ; "Kevin Altis" Cc: 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/ From richard at mechanicalcat.net Tue Apr 15 09:31:18 2003 From: richard at mechanicalcat.net (Richard Jones) Date: Mon Apr 14 18:31:32 2003 Subject: [Pydotorg-redesign] webmaster email handling In-Reply-To: <071a01c302d1$41cdc290$5a00000a@holdenweb.com> References: <200304150747.26843.richard@mechanicalcat.net> <071a01c302d1$41cdc290$5a00000a@holdenweb.com> Message-ID: <200304150831.20436.richard@mechanicalcat.net> On Tue, 15 Apr 2003 08:00 am, Steve Holden wrote: > 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. *blush* sorry, my irony detector didn't come online until 8am this morning, so that smiley slipped through :) > 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. I'm a little concerned by the use of "nightmare" and no smiley :) What, specifically, do you see as the nightmarish problems? > > 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. Hurm. I'm guilty of assuming knowledge of Roundup, again. To clarify (I hope): - Roundup stores off issues with associated message spools (messages are stored on disk if other systems need access to them) - each issue also includes a "nosy" list - the original author and assigned user are automatically placed in this list. New assigned users are also included. People on the nosy list automatically receive a copy of any message added to an issue's spool (if they haven't already received one via email cc'ing). I will be adding (trivial) code that automatically closes an issue when an "assignable" user submits a message to the spool and reopens an issue when an external user submits a message. - email messages are managed such that Roundup is kept in the loop by being the reply-to address of messages it sends, and by including a marker in the subject line indicating the issue of interest. New messages for an issue are added to the spool (and sent to the nosy list). New messages not relating to an issue create one. I would set this tracker up so that it owned the webmaster address - all email to it goes into the tracker, and all email from the tracker will have the webmaster address. The web form would be an alternative access point if we really want it. HTH, Richard From aahz at pythoncraft.com Tue Apr 15 13:34:51 2003 From: aahz at pythoncraft.com (Aahz) Date: Tue Apr 15 12:34:55 2003 Subject: [Pydotorg-redesign] Switching to Roundup In-Reply-To: <200304142224.15594.richard@mechanicalcat.net> Message-ID: <20030415163451.GA9226@panix.com> [I'm switching this to pydotorg rather than pydotorg-redesign, because this is now a current almost-active issue. I'm cc'ing pydotorg-redesign so people there not on pydotorg know that this hasn't been dropped. Richard, you're on pydotorg, so there's no need to cc you directly.] [I've read the whole thread to date, but I'm going back to the beginning to clarify with a complete summary.] [Summary for pydotorg'ers not on pydotorg-redesign: we're now making a push to have Roundup be the issue tracker for webmaster issues, both to simplify managing the web site and to serve as beta testers for Roundup to get off SourceForge.] On Mon, Apr 14, 2003, Richard Jones 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 > 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) > 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) > 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. So the current plan is actually: * Create new issues either with web form interface (non-public?) or with e-mail to webmaster alias (along with "jobs" and "events" aliases). * New issues are not assigned. Form letter is sent to user with /dev/null Reply-To: (and From: also?). We use different form letters depending on which alias is used. * If a Roundup user responds to the issue by e-mail, the issue is assigned to that user and closed. The issue gets re-opened if the original submitter responds, staying assigned to the same Roundup user. The Roundup user sends e-mail to Roundup, which then sends a form letter to the original submitter. * Standard Roundup functionality is available through the web interface, including the ability to pluck issues from another user's queue. The original submitter does not get changes of assignment (unless the submitter is a Roundup user). * Weekly status reports on all open issues are sent by e-mail to all Roundup users. How much of this is correct, Richard? Any complaints/suggestions from other pydotorg people? -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ This is Python. We don't care much about theory, except where it intersects with useful practice. --Aahz, c.l.py, 2/4/2002 From altis at semi-retired.com Tue Apr 15 10:42:46 2003 From: altis at semi-retired.com (Kevin Altis) Date: Tue Apr 15 12:40:02 2003 Subject: [Pydotorg-redesign] FW: [marketing-python] More on the white paper idea Message-ID: White papers sound like a good idea to me. I'm forwarding Skip's message because my comments mostly have to do with redesign ideas. We have a handful of Topic pages and some are better than others. http://www.python.org/topics/ There is definitely overlap with the SIG pages and much of the content of various SIG pages would be good for topic pages (eg. edu-sig -> Python in Education). I'm not sure I like the idea of replacing the better pages like the Python and Scientific Computing topic with a white paper and a set of links at the bottom of that, but Skip may have an example white paper in mind to use as a model for the organization. http://www.python.org/topics/scicomp/ This is definitely an area where it would be good to get feedback from the "scientific computing" customers about whether the pages are useful to them. ka -----Original Message----- From: Skip Montanaro Sent: Tuesday, April 15, 2003 7:44 AM To: marketing-python@wingide.com Subject: [marketing-python] More on the white paper idea Following up on my note from yesterday suggesting topic-specific white papers/web pages, I think we could solicit white papers from people in specific disciplines to provide short, readable overviews of how Python and its supporting libraries can be used in those disciplines. Here are some possibilities: Scientific Computing Eric Jones XML Uche Ogbuji Data Visualization/3D Graphics Prabhu Ramachandran or Michel Sanner Web Services Mark Pilgrim Relational Databases Andy Dustman or Federico di Gregorio Such white papers could serve several different purposes: * They'd be valuable source material for people considering Python in specific problem domains. They'd be written by someone who's an expert in a particular field, so their expertise would lend credibility to the argument that Python is an appropriate language for that task. * The collection of white paper pages would provide useful structure (better than the current topics, sigs and psa pages) and convenient places to hang pointers to a handful of related links (without trying to supplant Parnassus or PyPI). * An initial set of white papers would probably generate white paper proposals and submissions in areas we haven't considered. Skip _______________________________________________ marketing-python mailing list marketing-python@wingide.com http://pythonology.org/mailman/listinfo/marketing-python From guido at python.org Tue Apr 15 15:25:14 2003 From: guido at python.org (Guido van Rossum) Date: Tue Apr 15 14:36:00 2003 Subject: [Pydotorg-redesign] Re: [Pydotorg] Switching to Roundup In-Reply-To: Your message of "Tue, 15 Apr 2003 12:34:51 EDT." <20030415163451.GA9226@panix.com> References: <20030415163451.GA9226@panix.com> Message-ID: <200304151825.h3FIPEm28999@odiug.zope.com> > [Summary for pydotorg'ers not on pydotorg-redesign: we're now making a > push to have Roundup be the issue tracker for webmaster issues, both to > simplify managing the web site and to serve as beta testers for Roundup > to get off SourceForge.] +1 --Guido van Rossum (home page: http://www.python.org/~guido/) From mats at laplaza.org Tue Apr 15 13:46:38 2003 From: mats at laplaza.org (Mats Wichmann) Date: Tue Apr 15 15:03:15 2003 Subject: [Pydotorg-redesign] Re: [Pydotorg] Switching to Roundup In-Reply-To: <20030415163451.GA9226@panix.com> References: <200304142224.15594.richard@mechanicalcat.net> Message-ID: <5.1.0.14.1.20030415124616.01ff48b8@mail.laplaza.org> >How much of this is correct, Richard? Any complaints/suggestions from >other pydotorg people? I'm happy with it. Oh, okay: +1 From skip at pobox.com Tue Apr 15 15:12:35 2003 From: skip at pobox.com (Skip Montanaro) Date: Tue Apr 15 15:13:34 2003 Subject: [Pydotorg-redesign] Re: More on the white paper idea In-Reply-To: References: Message-ID: <16028.22947.565228.601527@montanaro.dyndns.org> Kevin> There is definitely overlap with the SIG pages and much of the Kevin> content of various SIG pages would be good for topic pages Kevin> (eg. edu-sig -> Python in Education). I'm not sure I like the Kevin> idea of replacing the better pages like the Python and Scientific Kevin> Computing topic with a white paper and a set of links at the Kevin> bottom of that, but Skip may have an example white paper in mind Kevin> to use as a model for the organization. Kevin> http://www.python.org/topics/scicomp/ Kevin> This is definitely an area where it would be good to get feedback Kevin> from the "scientific computing" customers about whether the pages Kevin> are useful to them. More in line with what I'm interested in is, what information would a person considering using Python for scientific computing need to know? The scicomp page is essentially a lot of links with very little motivation about why Python would be a good choice for scientific computing and no case studies. A white paper in this area would ideally speak about things like * How is Python integrated with existing Fortran libraries? * Is there a Python interface to LAPACK? * How does performance compare to applications written completely in Fortran? Much of that can be inferred by doing a fair amount of clicking and reading, but it's not all there for one easy gulp. In particular, for the technical guy wanting to plop a three- to four-page synopsis on his boss's desk which supports his claim that Python is a good choice for this area, there's nothing. I'm including Eric Jones on this thread so he can provide some specific feedback on what he feels a technical/project manager considering Python in a scientific computing context would look for. Unless he begs off, please make sure your replies include him, as I don't believe he's on either list. Let's focus on just scientific computing for the moment. I suspect we will find many of the questions people would ask will be similar across disciplines. Eric, the general context in which this thread occurs is marketing Python more effectively. Kevin Altis (I think) stated a desire to increase the usage of Python - however crudely you might measure that - by about 10x in about two years (the clock started yesterday ;-). Since there is no "marketing arm" for Python, that means the website must subsume many of the tasks of a traditional marketing group. In concrete terms, a change in focus of this sort implies a significant change in the organization of the website. I suggested one way we could organize part of the site is to have a series of topic-specific white papers. In Kevin's note, he focused on one of my suggested areas, scientific computing, and pointed to the current /topics/scicomp page on python.org. If we can solve the problem of developing a good white paper for Python+scientific computing, I think we can generalize much of what we've learned to other disciplines. That's where you come in. ;-) Skip From mwh at python.net Tue Apr 15 22:09:19 2003 From: mwh at python.net (Michael Hudson) Date: Tue Apr 15 16:19:02 2003 Subject: [Pydotorg-redesign] Re: [Pydotorg] Switching to Roundup In-Reply-To: <20030415163451.GA9226@panix.com> (Aahz's message of "Tue, 15 Apr 2003 12:34:51 -0400") References: <20030415163451.GA9226@panix.com> Message-ID: <2mn0irplow.fsf@starship.python.net> Aahz writes: > So the current plan is actually: Excuse me if I've missed this, but how do people find out about new issues? Mail goes to all the people currently on webmaster? Cheers, M. -- That being done, all you have to do next is call free() slightly less often than malloc(). You may want to examine the Solaris system libraries for a particularly ambitious implementation of this technique. -- Eric O'Dell, comp.lang.dylan (& x-posts) From richardjones at optushome.com.au Wed Apr 16 09:25:08 2003 From: richardjones at optushome.com.au (Richard Jones) Date: Tue Apr 15 18:27:04 2003 Subject: [Pydotorg-redesign] Re: [Pydotorg] Switching to Roundup In-Reply-To: <20030415163451.GA9226@panix.com> References: <20030415163451.GA9226@panix.com> Message-ID: <200304160825.10488.richardjones@optushome.com.au> On Wed, 16 Apr 2003 02:34 am, Aahz wrote: > * Create new issues either with web form interface (non-public?) or with > e-mail to webmaster alias (along with "jobs" and "events" aliases). Yes. And the jobs/events aliases could be flagged in some way if need be. > * New issues are not assigned. Form letter is sent to user with > /dev/null Reply-To: (and From: also?). We use different form letters > depending on which alias is used. I'd automatically pick a random assignee - this would forward the message to them, which enables them to respond to the issue. If they don't respond within a few days, then the issue is automatically reassigned. > * If a Roundup user responds to the issue by e-mail, the issue is > assigned to that user and closed. The issue gets re-opened if the > original submitter responds, staying assigned to the same Roundup user. > The Roundup user sends e-mail to Roundup, which then sends a form letter > to the original submitter. Almost. The Roundup user responding only closes the issue (since they're already assigned). Also, their response is sent to the original submitter, not a form letter. > * Standard Roundup functionality is available through the web interface, > including the ability to pluck issues from another user's queue. The > original submitter does not get changes of assignment (unless the > submitter is a Roundup user). No messages are generated for changes of assignment, therefore no emails are sent (except to the new assignee, who gets a copy of the most recent message). > * Weekly status reports on all open issues are sent by e-mail to all > Roundup users. No problem there, though I'm not sure it's needed given the auto-reassignment. Richard From aahz at pythoncraft.com Tue Apr 15 21:15:25 2003 From: aahz at pythoncraft.com (Aahz) Date: Tue Apr 15 20:15:29 2003 Subject: [Pydotorg-redesign] Re: [Pydotorg] Switching to Roundup In-Reply-To: <200304160825.10488.richardjones@optushome.com.au> References: <20030415163451.GA9226@panix.com> <200304160825.10488.richardjones@optushome.com.au> Message-ID: <20030416001525.GA2920@panix.com> On Wed, Apr 16, 2003, Richard Jones wrote: > On Wed, 16 Apr 2003 02:34 am, Aahz wrote: >> >> * Create new issues either with web form interface (non-public?) or with >> e-mail to webmaster alias (along with "jobs" and "events" aliases). > > Yes. And the jobs/events aliases could be flagged in some way if need be. They should be, at least WRT to the "type" field in Roundup. >> * New issues are not assigned. Form letter is sent to user with >> /dev/null Reply-To: (and From: also?). We use different form letters >> depending on which alias is used. > > I'd automatically pick a random assignee - this would forward the > message to them, which enables them to respond to the issue. If they > don't respond within a few days, then the issue is automatically > reassigned. Your later message indicates you've read the rest of the thread, but I just wanted to emphasize that we really DON'T want auto-assignment. We can revisit the issue when we start getting "a lot" of overlap; we currently don't have a problem, and trying to do that will likely result in less overall work being performed (certain people are more likely to respond to different types of messages; automating that is *way* more trouble than it's worth). -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ This is Python. We don't care much about theory, except where it intersects with useful practice. --Aahz, c.l.py, 2/4/2002 From aahz at pythoncraft.com Tue Apr 15 21:19:02 2003 From: aahz at pythoncraft.com (Aahz) Date: Tue Apr 15 20:19:08 2003 Subject: [Pydotorg-redesign] Re: [Pydotorg] Switching to Roundup In-Reply-To: <200304160825.10488.richardjones@optushome.com.au> References: <20030415163451.GA9226@panix.com> <200304160825.10488.richardjones@optushome.com.au> Message-ID: <20030416001902.GB2920@panix.com> One point I forgot: On Wed, Apr 16, 2003, Richard Jones wrote: > On Wed, 16 Apr 2003 02:34 am, Aahz wrote: >> >> * If a Roundup user responds to the issue by e-mail, the issue is >> assigned to that user and closed. The issue gets re-opened if the >> original submitter responds, staying assigned to the same Roundup user. >> The Roundup user sends e-mail to Roundup, which then sends a form letter >> to the original submitter. > > Almost. The Roundup user responding only closes the issue (since > they're already assigned). Also, their response is sent to the > original submitter, not a form letter. What I meant by "form letter" is that Roundup adds a standard footer about how to continue with the issue (and also to emphasize that people respond to Roundup, not to the submitter directly). -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ This is Python. We don't care much about theory, except where it intersects with useful practice. --Aahz, c.l.py, 2/4/2002 From aahz at pythoncraft.com Tue Apr 15 23:04:06 2003 From: aahz at pythoncraft.com (Aahz) Date: Tue Apr 15 22:04:10 2003 Subject: [Pydotorg-redesign] Re: Python FAQ (Was: Re: Confusion: assignments create object references.) In-Reply-To: <20030415124403.A030F4953C@mail1.panix.com> References: <3E970241.483698C7@engcorp.com> <20030415124403.A030F4953C@mail1.panix.com> Message-ID: <20030416020406.GA24332@panix.com> [I'm cc'ing Robin Munn, who answered on c.l.py, and pydotorg-redesign, which is the mailing list for people who are working on short-term design fixes plus medium- to long-term wholesale changes (concentrating more on the latter; the pydotorg mailing list is for the day-to-day maintenance issues). I encourage both Robin and Alex to subscribe to pydotorg-redesign if they haven't yet. http://mail.python.org/mailman/listinfo/pydotorg-redesign ] On Tue, Apr 15, 2003, Alex Martelli wrote: > > [i'm answering by email only...] > > Aahz wrote: > >> In article , >> Robin Munn wrote: >>> >>>In fact, the Python FAQ needs some trimming, IMHO. With the "Programming >>>in Python" section containing over 100 questions, few are going to have >>>the patience to sit down and read the entire list to see if their >>>question is on the list. Thus we get the same questions over and over in >>>the newsgroup. The FAQ is not serving its purpose. >>> >>>I am not suggesting we get rid of the information currently contained >>>in the FAQ, but we should probably refactor the FAQ into two levels: one >>>for the truly frequently-asked questions, and one for "Here are more >>>questions that crop up from time to time; look through this for useful >>>nuggets of information." I think a shorter FAQ would be read a lot more >>>often. >> >> "What 'we', white man?" >> >> The python.org webmasters would love for someone to do this work. Any >> volunteers?.... > > What task, exactly? Editing and restructuring the FAQ into two > parts, one about questions that ARE indeed asked frequently (say > 1/3 or less of the current entries), one with the rest (for those > who are not asked all that frequently)? Depending on what deadline > you need for that, I could volunteer for this reorg/editing task. We're happy for anything and everything. If you and Robin want to go off and talk privately for a bit, that's fine, if you two want to talk about it publicly on pydotorg-redesign, that's fine, too. If either of you want CVS access to www.python.org, send e-mail to webmaster@python.org. Just to be clear, there's no deadline; it's all based on what time/energy y'all have available. We're about to start making the pydotorg team run on Roundup, so you'll have an issue tracker available if you want. Once you two (and anyone else who volunteers) are ready to start making changes, please post a summary of the plan to pydotorg@python.org. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ This is Python. We don't care much about theory, except where it intersects with useful practice. --Aahz, c.l.py, 2/4/2002 From Nicolas.Chauvat at logilab.fr Wed Apr 16 12:17:00 2003 From: Nicolas.Chauvat at logilab.fr (Nicolas Chauvat) Date: Wed Apr 16 09:55:54 2003 Subject: [Pydotorg-redesign] Re: [marketing-python] Re: More on the white paper idea In-Reply-To: <16028.22947.565228.601527@montanaro.dyndns.org> References: <16028.22947.565228.601527@montanaro.dyndns.org> Message-ID: <20030416091700.GK2275@logilab.fr> On Tue, Apr 15, 2003 at 02:12:35PM -0500, Skip Montanaro wrote: > Eric, the general context in which this thread occurs is marketing Python > more effectively. Kevin Altis (I think) stated a desire to increase the > usage of Python - however crudely you might measure that - by about 10x in > about two years (the clock started yesterday ;-). Since there is no > "marketing arm" for Python, that means the website must subsume many of the > tasks of a traditional marketing group. Couldn't the Python Business Forum be used for that? This is one of the goals it was created for. (not syaing it has to, just that it could). -- Nicolas Chauvat http://www.logilab.com - "Mais o? est donc Ornicar ?" - LOGILAB, Paris (France) From richardjones at optushome.com.au Wed Apr 16 20:57:33 2003 From: richardjones at optushome.com.au (Richard Jones) Date: Wed Apr 16 09:56:07 2003 Subject: [Pydotorg-redesign] Re: [Pydotorg] Switching to Roundup In-Reply-To: <20030416001902.GB2920@panix.com> References: <20030415163451.GA9226@panix.com> <200304160825.10488.richardjones@optushome.com.au> <20030416001902.GB2920@panix.com> Message-ID: <200304161957.34179.richardjones@optushome.com.au> On Wed, 16 Apr 2003 10:19 am, Aahz wrote: > One point I forgot: > > Almost. The Roundup user responding only closes the issue (since > > they're already assigned). Also, their response is sent to the > > original submitter, not a form letter. > > What I meant by "form letter" is that Roundup adds a standard footer > about how to continue with the issue (and also to emphasize that people > respond to Roundup, not to the submitter directly). OK, except that Roundup's behaviour is to indicate the author of the response in the From line by name, even though the From address is the Roundup address. That is, something like: From: Richard Jones This would be difficult, but not impossible to change. Richard From aahz at pythoncraft.com Fri Apr 18 22:02:24 2003 From: aahz at pythoncraft.com (Aahz) Date: Fri Apr 18 21:02:27 2003 Subject: [Pydotorg-redesign] Roundup field list Message-ID: <20030419010224.GA3613@panix.com> I'm starting this on pydotorg-redesign, then I'll move the discussion back to pydotorg when things settle down a bit. I'm proposing a list of fields (plus what would be handled as a linked table in a DBMS) for the python.org Roundup-based issue tracker. I'm not familiar with what's "standard" with Roundup. Please feel free to comment (especially Richard): Issue Number Urgency Importance Default sort should be Urgency. (After many years in tech support, I really want this to be two separate fields.) Status New/Open/Review/Closed -- others? Type This field should have defaults (webmaster, event, job, design, bug, task, etc.), but should also allow free-form entry (but any non-default values should require confirmation from the Roundup user). All Roundup users can add/edit the defaults. Submitter Do we need a separate field for e-mail address, or is an RFC-822 field good enough for both? Should there be a separate Creator field for Roundup users (defaults to "Roundup" when created by e-mail)? Owner The Roundup user handling the issue, can be blank. Reviewer We don't need this now, but I'd expect we'll need it once we start really moving forward with a site redesign. Datetime Created Datetime Last Modified Event Log (optional) Dunno how hard this is to do with Roundup (or if it's already there), but I'd prefer there to be a log of all changes to issues. That way we can see if an issue has been re-opened or never closed, we can see who the various owners have been, we can see what urgencies it's had, and so on. This will become an absolute requirement for moving Python off SF, so we might as well start moving on this now. -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ Why is this newsgroup different from all other newsgroups? From richard at mechanicalcat.net Thu Apr 24 15:03:43 2003 From: richard at mechanicalcat.net (Richard Jones) Date: Thu Apr 24 00:04:06 2003 Subject: [Pydotorg-redesign] Roundup field list In-Reply-To: <20030419010224.GA3613@panix.com> References: <20030419010224.GA3613@panix.com> Message-ID: <200304241403.49935.richard@mechanicalcat.net> On Sat, 19 Apr 2003 11:02 am, Aahz wrote: > I'm starting this on pydotorg-redesign, then I'll move the discussion > back to pydotorg when things settle down a bit. No feedback from anyone - I guess that means your design is perfect :) > I'm proposing a list of fields (plus what would be handled as a linked > table in a DBMS) for the python.org Roundup-based issue tracker. Just so we're clear - the purpose of _this_ set of issues is to only track email to webmaster? A Roundup tracker may handle other pydotorg issues (ie. system admin issues) as a separate issue store with its own set of properties and behaviours. From the discussion so far, I envision the tracker having two issue trypes: webmaster - almost no meta-data except open/closed and nosy - lots of automatic behaviour like close-on-webmaster-reply and reopen-on-submitter-reply - once a week summary of open issues sent to webmasters support - all the meta-data you describe below - once a week summary of open issues sent to support people > I'm not familiar with what's "standard" with Roundup. Have a play at http://mechanicalcat.net:8080/demo/ - that's a classic Roundup tracker (ie. what you get when you install the default). Also, if you're feeling a little more enthusiastic, you can check out the current CVS and run "python setup.py demo" which will set up a local demo sandbox for you to play with. Hurm, I think it's about time I updated the online demo to use 0.6 - there's so much cool stuff that's been added to Roundup since 0.5 :) > Issue Number Automatic :) > Urgency > Importance > Default sort should be Urgency. (After many years in tech support, > I really want this to be two separate fields.) No problem here, though I'd recommend the index display _group_ by urgency and sort by activity date like the classic Roundup does. What values would you have for Urgency and Importance? > Status > New/Open/Review/Closed -- others? That's usually enough in practise. > Type > This field should have defaults (webmaster, event, job, design, bug, > task, etc.), but should also allow free-form entry (but any > non-default values should require confirmation from the Roundup > user). All Roundup users can add/edit the defaults. This isn't a Roundup capability at present. This sort of field is handled by selecting options from a list of types. There's a separate edit form for adding new types. As of version 0.6 (to be released sometime this year ;) there's even a neato new popup dialog which helps editing of this sort of field. > Submitter > Do we need a separate field for e-mail address, or is an RFC-822 > field good enough for both? Should there be a separate Creator field > for Roundup users (defaults to "Roundup" when created by e-mail)? Submitters are automatically registered with the tracker - but they're given no permissions for actually accessing it beyond the email interface. This is "creator" (and also "author" of the initial sbumission message) in the classic Roundup schema. > Owner > The Roundup user handling the issue, can be blank. This is "assignedto" in the classic Roundup schema. > Reviewer > We don't need this now, but I'd expect we'll need it once we start > really moving forward with a site redesign. No problem - what automatic behaviours would you see attached to the reviewer property? > Datetime Created > Datetime Last Modified These are "creation" and "activity" in the classic Roundup schema. > Event Log (optional) Automatically generated by Roundup (as an aside: this is where the "creator", "creation" and "activity" fields come from ;) Richard -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature Url : http://mail.python.org/pipermail/pydotorg-redesign/attachments/20030424/e8ffa6cc/attachment.bin