[Pydotorg-redesign] Roundup field list

[Aahz]

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.

[Richard Jones]

Post by Aahz
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 :)

Post by Aahz
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

Post by Aahz
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 :)

Post by Aahz
Issue Number

Automatic :)

Post by Aahz
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?

Post by Aahz
Status
New/Open/Review/Closed -- others?

That's usually enough in practise.

Post by Aahz
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.

Post by Aahz
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.

Post by Aahz
Owner
The Roundup user handling the issue, can be blank.

This is "assignedto" in the classic Roundup schema.

Post by Aahz
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?

Post by Aahz
Datetime Created
Datetime Last Modified

These are "creation" and "activity" in the classic Roundup schema.

Post by Aahz
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

[Aahz]

[After a long delay....]

Post by Richard Jones

Post by Aahz
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
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'd rather have all the metadata available to webmaster issue types so
that they can be converted to support issues if needed.

Post by Richard Jones

Post by Aahz
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.

Hrm. I think activity date should be tertiary after urgency and
importance.

Post by Richard Jones
What values would you have for Urgency and Importance?

Low, Normal, High, Critical. Or we could use the SF system of 1-10,
with 5 being "normal".

Post by Richard Jones

Post by Aahz
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.

Oh, well. All right, let's give all the pydotorg admins access to the
type edit form.

Post by Richard Jones

Post by Aahz
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.

Okie-doke. How does an auto-user get a password?

Post by Richard Jones

Post by Aahz
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?

Gets treated as owner for now (in terms of notifications). Yes, we
could just keep changing assignedto, but my experience is that makes it
harder to read for people not directly in the loop.


Here's the complete list of proposed fields:

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

Summary
Short description

Description
Long description

Reason
Optional text field, used as a post-summary (e.g. YAGNI)

Type

Submitter

Owner
The Roundup user handling the issue, can be blank.

Reviewer

Datetime Created
Datetime Last Modified

Event Log

[Richard Jones]

Post by Aahz
[After a long delay....]

:)

Post by Aahz

Post by Richard Jones

Post by Aahz
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.

Okie-doke. How does an auto-user get a password?

They visit the tracker and use the "forgotten password" form.

Post by Aahz

Post by Richard Jones

Post by Aahz
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?

Gets treated as owner for now (in terms of notifications). Yes, we
could just keep changing assignedto, but my experience is that makes it
harder to read for people not directly in the loop.

[snip]

So, where to from here?



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/20030809/684fa8f8/attachment-0001.bin