Patch and Test Tracking

Instead of the 'needs test' and 'needs patch' stages, it would be better to have a checkbox grid something like this:

            NA      needs patch     has patch
docs       ( )          ( )           ( )
tests      ( )          ( )           ( )
code       ( )          ( )           ( )

We could then have a 'patch incomplete' stage instead of the 'needs' stages, where the checkboxes would make clear what things were missing.

Instead of radio boxes we could have three drop-down inputs like:

docs   [____________[▼]
tests  [____________[▼]
code   [____________[▼]

With "not needed", "needed", "provided", "committed" as possible values. The stages could be something like "discussing" (when no patch has been provided yet), "in progress" (when there is some patch), "committed" (when all the patches have been committed). The stage field could also be removed altogether and replaced by these 3 fields; the additional details can be provided by the 'status' and 'resolution' fields.

Python Version Tracking

Instead of a multi-selection list for python versions, perhaps we could have a list of versions like this:

        confirmed   will apply  committed
3.3        ( )         ( )      [      ]
3.2        ( )         ( )      [      ]
3.1        ( )         ( )      [      ]
3.0        ( )         ( )      [      ]
2.7        ( )         ( )      [      ]
     ...

This would allow the tracker to record which versions a bug is present in, even if it doesn't get fixed in that version, and also allow us to track the progress when more than one version needs to be patched. We might perhaps want to add a stage 'committing' when a patch has been committed to one branch but not all. (Note: for feature requests 'confirmed' would be left blank). 'will apply' would be checked when someone determines that the patch, whether it exists or not, should be applied to the given branch. 'committed' would be the revision in which the patch was committed. Ideally this would be auto-filled by the change management system based on tags in the commit message.

If the above is deemed too complex, then we should at least have a way to mark issues as accepted regardless of whether or not they have a complete patch. This is to differentiate between issues that just need work, and issues where we haven't even decided that we are going to accept it.

Another alternative is using drop-downs, e.g.:

3.1  [____________[▼]
3.2  [____________[▼]
3.3  [____________[▼]

With values like 'unaffected', 'affected', 'committed', 'to be ported'.

• Waiting for the switch to Mercurial before writing code for auto-linking between bugs and changesets (thanks to the interhg extension, shipped with Mercurial) and such things (using a hook to automatically close bugs) may be smart. —merwok

• Using checkboxes instead of multi-value select elements is a huge usability win.(No references handy, just memory.) —merwok

  Checkboxes could be used for versions, like:

  [ ] 2.5   [ ] 2.6   [ ] 2.7
  [ ] 3.1   [ ] 3.2   [ ] 3.3

  or:

  [ ] 2.5   [ ] 3.1
  [ ] 2.6   [ ] 3.2
  [ ] 2.7   [ ] 3.3

  the '3rd party' value could IMHO be removed, since there are only 3 issues opened that use it.

This doesn't need a patch, but is noted here so the idea doesn't get lost: it has been suggested that an additional type of 'refactoring' be added.

Instead of refactoring it could be rfe.

New Field for Module/Package

withdrawn

When I want to find all bugs related to one module or package, I have to use the plain text search, which could give false positives and leave out valid results. For some packages I can use a component, e.g. Distutils, but not for all. I suggest a new field that would allow selecting what module(s)/package(s) a bug apply to. This would provide reliable and discoverable URIs for people who want to monitor particular modules or packages.

This has been suggested and rejected a number of times on python-dev. --RDM

This information is not useful. Can you list the arguments? -- techtonik

No, but it would be great if you would search the archives and post links to the threads here. --RDM

I tried with no luck. It would be useful to find the threads for future reference, but your memory is enough for me to withdraw my feature request. –merwok

Easier Monitoring

(merwok)

Provide Atom feeds for saved queries to make keeping up with a particular area or component easier.

Add OpenSearch support to allow browsers to get search suggestions (completion) and scripts to get search results as easily-parsable feeds (see Wikipedia’s OpenSearch file for an example). It means adding one simple XML file, and returning search results as Atom feeds with some OpenSearch elements.

Allow any user to set her/himself as auto-nosy for some criteria.

Allow any user with developer status to set her/himself as auto-assignee for some for some criteria.

Files

(merwok)

Warn the user if they send an inappropriate file (zipfile, .exe, Microsoft office formats).

Attach files to emails sent to nosy if they have a sane mime type and size (possibly with a user option).

Misc

When an issue is closed stage should be automatically set to 'committed/rejected'.

• confusing, 'fixed' issue is neither 'committed' nor 'rejected' at all times -- anatoly techtonik
• related: we don’t have to use confusing sourceforge fields forever, so at least having two values for committed and rejected would be sensible. —merwok

There should be a field in which you can enter an issue number of an issue of which this issue is a duplicate, and submitting it should

1. merge the nosy list from this issue into the specified issue
2. set the resolution to duplicate

3. close the issue (setting stage to committed/rejected per above)

   • duplicate would be better -- anatoly techtonik

There should be an anchor at the top of the page linked to the last message and other links to go back to the top of the page. This is especially useful when there are lot of messages.

It would probably be better if the default search returned results from closed bugs; this should cut down on the number of bug reports for things that have already been fixed but not released. See #311.

When a user adds a file there should be a note among the messages (or even inside the message) with a link to the added file. This would avoid confusion if the user says "This patch ..." and there are several files attached.

The tracker should be in some way integrated with maintainers.rst. It should be possible to map at least some of the "Components" in the tracker with the "Interest areas" (e.g. "Unicode", "Windows") in maintainers.rst and/or provide a way to consult the file while adding/editing an issue. Another option is to add fields like "maintainer of" or "interest areas" to the users, but it will probably be hard to keep it in sync with maintainers.rst.

Emails can contain useful links like "remove me from nosy" and also link directly to the message using an anchor (i.e. .../issue1234#msg12345).

Removing someone from nosy via a link, IOW modifying state with a GET request, is a proved bad idea. Ok for a link that would open a page with a form that sends a POST request to remove oneself from nosy. —merwok

Assignment should be open to anyone with an account. Assignment suggests responsibility. Many issues may be worth fixing, but not interesting enough to someone with tracker privileges to fix.

There might be an 'assigned to' field open to everyone is working or wants to work on the issue and a 'reviewer/committer' field for a core developer that can review and commit the patch once it's ready.

Ability to make groups of related issues, i.e. issue7833, issue8870 and issue8871 are independent, but related and will be interesting for developer of any of them. -- techtonik

Ability to link/track status of issues from external trackers. -- techtonik

Consider Trac 0.12 as an alternative to Roundup http://trac.edgewall.org/wiki/TracWorkflow -- techtonik

CategoryTracker