The devguide documents the 'accepted' resolution as follows:

     Submitted patch was applied, still needs verifying (for example by
     watching the buildbots) that everything went fine. At that point the
     resolution should be set to fixed and the status changed to closed.

I've never run into this usage while working with the tracker.  I *have* seen people set 'accepted' when they want to indicate that the issue is considered valid to be fixed, or that a feature request has been accepted but there's no patch ready for commit yet.

Formally I believe that the 'accepted' resolution is for committed feature requests (since "fixed" doesn't make English sense in that context).  Any other use is creative license :)

> Formally I believe that the 'accepted' resolution is for committed feature requests

That's what I also thought originally.

Perhaps this should be discussed on Python-Dev to see what people think it should mean?

I say just  go ahead and change  it. I was probably just thinking how I wish we would use it when I wrote that.

I propose that we remove 'accepted' as the meaning seems ambiguous and
it is of little practical (/tracking) use.

It is not ambigous.  As I said, bugs are fixed, feature requests are accepted.

I thought "fixed" was enough. A kind of binary state where we say, okay we have it and otherwise no, we don't. I know for feature requests the terminology does not make sense, but I believe I have worked with bug trackers where fixed was the ultimate state where a particular change (be a bug-fix or a feature request) was in the code.

Well, as long as it is helpful, I am fine with it, but too many options can confuse (just as 'accepted' did) and it will be helpful to prune down some.

The "Accepted" Resolution was copied from SF. I recall seeing documentation on SF for the resolutions, but can't find that anymore.

I also recall that on SF, the "accepted" resolution was used to indicate that a patch was accepted (be it a bug fix or a feature request), and also in combination with the "open" status (in the sense of an "approved" resolution, also).

Adding a feature 'fixes' the deficiency of its absence. I personally have no use for 'accepted' and find it ambiguous. My best understanding is what David has seen (accepted in principle).

Terry J. Reedy wrote:
> Adding a feature 'fixes' the deficiency of its absence. I personally
> have no use for 'accepted' and find it ambiguous. My best
> understanding is what David has seen (accepted in principle).

Ditto.

Having separate resolutions for bugs and features makes it harder to
find all issues that have been closed as "bug fixed or feature
accepted", because you cannot select multiple resolutions when
searching.

With one resolution, you can simply search for "fixed" issues. If you
only want to find feature requests that were accepted, search for
type=feature and resolution=fixed.

FWIW that would be fine with me.  Even if there's nothing broken in a feature request, "fixed" applied to feature could mean "the lack of this feature has been fixed".
If the issue is valid, one can say so in a message without marking it as 'accepted'.

Well, as long as 'accepted' is under 'resolution', I'm likely to keep using it for feature requests, I suppose because I'm too much of a precisonist.  If someone wants to re-engineer the interface, that would be fine with me :)

I personally don't mind other uses, nor do I find myself searching on resolutions.

R. David Murray wrote:
>  If someone wants to re-engineer the interface, that would be fine with me :)

Does that mean, that if vote for removing the 'accepted' keyword it
becomes an issue for the meta-tracker?

I think we've moved from discussing a documentation issue to discussing a procedural issue in the development process.  I'm not sure what forum that belongs in, though I believe in the past we have used tracker-discuss for that.

That said, I'm really fine with whatever is decided, and don't think it is that big a deal in any regard.

When we’ve talked about that a few times these last months on the ML or on IRC, the outcome was that accepted means patch is accepted, not bug report is valid.  I’ve never seen accepted used to mean that a feature request is closed; I use fixed for solved bugs and added features alike and don’t see a problem with it.

"patch accepted" can be marked with the "commit review" stage.
That should mean "the patch is ready to go in, after a last quick review by the committer that will apply it", even though I've seen it used as "I made the commit but I'm leaving this open until I'm sure everything still works".

Changing the dev guide, which I think is definitely needed, is an issue for this tracker. Changing the tracker is an issue for the meta-tracker. Discussing a change might be an issue for python-dev.

I was under the impression once that the tracker fields were going to be reviewed last summer, before the dev guide was written. This could still happen any time.

RDM, yes, unfortunately the direction of the discussion changed from
documentation issue to a process one. Instead of diverting further
into catch all discussion about process/tracker, it would be good idea
to settle this one. Your points definitely counts as you raised
the issue and have experience in dealing with tracker states. What
would you suggest?

I would say I find "accepted" little useful in practice. Removing it would avoid the confusion with its various (intended or not) meanings.

+1

Martin, should we convert all the "accepted" to "fixed" before removing it?

Only if the issue is closed, so that it actually means 'fixed'.
Otherwise, just delete it.

The following data suggests to me that 'accepted' is a de facto synonym for 'fixed' and therefore useless and might as well be removed.
N     Issue category
3290  fixed
    68  open
  3219  closed
     354  feature request (and closed)
     302  behavior
     126  other type
    2437  type not specified
       346  documentation component (and type not specified)
       679  library component

The type field has been, at least in the past, greatly underused. But of the last 679, only 27 were in the last 3 years.

> Martin, should we convert all the "accepted" to "fixed" before removing it?

That's not strictly necessary. It would only be retired (roundup does
not support true removal), and as such would then still show up in
issues that currently use it, but not show up elsewhere anymore.

OK, I removed the resolution and its documentation from the devguide in 3f4710b6baf9.