The Category is 'Source Forge Item Tracker'.  The 
possible bug is the redundancy of having both an RFE 
(Request For Enhancement) list separate from the Bugs 
list and a Feature Request Group within Bugs.  Is this 
intentional or an historical artifact that should be 
removed in order to direct feature requests one place or 
another.

Logged In: YES 
user_id=31435

Sorry, we can't do anything about this.  Group names cannot 
be deleted in SourceForge's system, and can't even be 
renamed.  So we'll have a "Feature Request" Group in the 
Bugs tracker forever -- or unless SF changes their system.

When we first moved to SF, RFE trackers didn't exist.  That's 
why Bugs grew a Feature Request group to begin with.

Closing as 3rdParty, WontFix.

Logged In: YES 
user_id=593130

In the meanwhile...
is it appropriate to recommend that requests go in RFE (as I 
somewhat ignorantly and indirectly did today, see #960325) 
or is this a "don't care" issue for the developers (that I should 
ignore)?

Logged In: YES 
user_id=31435

Oh yes!  Overall, we'd rather reduce the mushrooming backlog 
of patch and bug reports than slam in new features, so we 
want to keep feature requests out of the bug tracker.  That's 
why the RFE tracker was added.

Logged In: YES 
user_id=593130

Thanks for the clear directive.

A thought for feature requesters: Conflicts between promise 
(the References) and performance (the CPython 
implementation) are clearly bugs.  So to are sufficiently 
muddled docs.  While a 'missing' feature might look like a bug 
to one who wants it, it might not to a developer looking to 
prune a bloated bug list (>700 today, about double what it 
was not too long ago.)  On the other hand, a feature request 
in the smaller RFE list is only competing with other feature 
requests instead of sometimes serious bugs.

Logged In: YES 
user_id=3066

I will note that not everyone agrees on this.  Having to
look in multiple trackers is quite painful as well.

The separation of the RFE tracker would be less of a problem
if there were no "patches" tracker; a patch should be
attached to a bug report or to a feature request, not separate.

Grr.

Logged In: YES 
user_id=6380

We should switch to RoundUp on python.org. A single unified
tracker that we can modify. Grr.

Logged In: YES 
user_id=21627

fdrake: I deal with the RFE tracker by never (or very
infrequently) looking at it. If Python has 700 bugs, and 250
unreviewed patches, I'm not going to implement features that
people have requested just because they requested them. So I
would be happy if the RFE tracker grew to 700 items, if the
bugs tracker shrank to 150 entries simultaneously. Only at
that point I will wonder what to do next, and look at RFEs.

Logged In: YES 
user_id=593130

loewis: I currently interprete your advice to me as "Yes, 
encourage movement of RFEs to the RFE list so I can focus 
on real bugs" rather than "No, leave them so I can reward 
queue jumpers with attention I would not otherwise give". ;-)

There are people who *have* read and responded to RFEs 
(about half have been closed).  Even those rejected usually 
get more explanation than simply "Not a bug" 

all: I agree that a tracker that we can modify with experience 
to make review and response easier would be great.  I agree 
with fdrake about patch confusion.  I think there should 
either be no separate patch list (but a way to pull out items 
with an open patch), or all patches should be on a separate 
patch list, but linked to a discussion-only item.  I'd like a way 
to select boilerplate responses and check off the presence of 
required patch features.

Logged In: YES 
user_id=21627

Yes, the RFE tracker is a way for me to move things at the
end of the queue (or the bottom of the stack).

I agree that all patches should be in the patches tracker,
i.e. patches should not be attached to bug reports. Instead,
the bug should have a comment "I have created a patch for
this bug at python.org/sf/something", and the patch should
start with "this fixes python.org/sf/somethingelse". I then
process the entire thing by opening two tabs in Mozilla, and
a shell window:

- I download the patch from the patch tab
- I test it in the shell, and commit it
- I run my "sumcvs.py" (attached) to extract the essential
bits from the CVS commit message (files and version numbers)
- I possibly repeat the procedure for release23-maint
- I put a comment in the bug saying that it is fixed with
mentioned patch, and close the bug
- I put the commit info into the patch comment, and close
the patch as accepted

This is a routine procedure, which takes a total of five
minutes administrative action (plus time to actually read
the patch, compile it, etc.)

Logged In: YES 
user_id=31435

Note that since SF doesn't let anyone other than the OP or a 
tracker admin attach a file to a report, someone who wants 
to contribute a patch generally must create a new tracker 
report to do so.  That's the reality we live with here.  It's less 
confusing to put those in the patch tracker than to grow an 
additional "bug report".