this is a german Web-Mirror of PYTHON.ORG powered by Domainunion AG

Differences between revisions 49 and 50
Revision 49 as of 2011-06-19 21:30:49
Size: 12200
Editor: jo137-3-88-172-217-81
Comment: Add link to suggestions
Revision 50 as of 2011-11-23 21:09:49
Size: 10074
Editor: EzioMelotti
Comment: Remove ideas that have been implemented already
Deletions are marked like this. Additions are marked like this.
Line 142: Line 142:
**DONE** in r83896. The "Your Issues" query is confusing (see `#299 <https://psf.upfronthosting.co.za/roundup/meta/issue299>`__ and `#329 <https://psf.upfronthosting.co.za/roundup/meta/issue329>`__).
This is how it could be changed::

  Old menu: New menu:
  # Issues # Issues
    * Create New * Create New
    * Show Open * Search
    * Show Easy * Show Issue |_____|
    * Show Unassigned
    * Show Needing Review # Summaries
    * Show Having Patch * Created by you
    * Search * Followed by you
    * Show Issue |_____| * Assigned to you
                                    * With patch
  # Hello, your.name * Easy
    * Your Issues
    * Your Details # Hello, your.name
    * Logout * Your Details
                                    * Logout

The 'Assigned to you' could be visible to developers only. The unassigned query is useless IMHO because there's plenty of unassigned issues. The "Needs review" is often omitted, so the "Needing Review" query is not so useful too.

----
Line 192: Line 169:
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.
Line 209: Line 178:

Jquery could be used to enhance the nosy list in the following ways:
 1. hide the (list) link;
 2. move the cursor at the end of the list once the user clicks on it;
 3. read the name that the user is typing and use ajax to list possible matches under the nosy list field, showing username, realname, and possibly modules set on maintainers.rst;
 4. add the name at the end of the nosy list when the user clicks on one of the suggestions;

Desired Tracker Features

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.

In the meanwhile the stages could be changed to "needs unit test", "needs patch", "needs review", "resolved".

See also some notes on python-dev

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.

It's not clear what 'refactoring' means in this context; why does it warrant a separate status in the version information? This seems like a feature of the patch itself rather than in what versions of Python it should be considered for. As such, it doesn't need a separate field in the issue, but can reasonably be covered in comments provided when the patch is attached.

The term 'rfe' is more general and can be applied to issues like #9139 or #5609. The difference with 'refactoring' is that it also covers additions that are not necessarily features, whereas 'refactoring' implies an improvement over something that already exists and it sounds more code-centric.

New Field for Module/Package

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
Found this: https://psf.upfronthosting.co.za/roundup/meta/issue78 —merwok
Nice catch. But that's not python-dev requests RDM is referring to. -techtonik
https://psf.upfronthosting.co.za/roundup/meta/issue373

Easier Monitoring

(merwok)

Provide Atom feeds for saved queries to make keeping up with a particular area or component easier. (See https://psf.upfronthosting.co.za/roundup/meta/issue155, which however uses one of the legacy RSS formats.)

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.

Add a stats page that shows stats and graphs similar to the ones included in the weekly summary reports.

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. See #312.

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.

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.

Mails for "unimportant" changes (e.g. nosy changes, files/msgs removed) could be avoided. These changes could still be included in the next message or when enough unimportant changes are collected, making sure that it's clear who changed what. The only problem is that if there's no "next message" the change will pass unnoticed. This is a problem especially for messages that gets removed accidentally. See #279.

Links to msgs (e.g. msg12345) should use anchors (i.e. issue1234#msg12345).

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 https://trac.edgewall.org/wiki/TracWorkflow -- techtonik

System Message: WARNING/2 (<string>, line 187)

Title underline too short.

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

CategoryTracker

DesiredTrackerFeatures (last edited 2017-02-02 19:10:20 by berkerpeksag)

Unable to edit the page? See the FrontPage for instructions.