[Pydotorg-redesign] Roundup field list

[Richard Jones]

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