We need version information on all bug reports.

You also mention "raised the concern". Is this report against Audit or Differential?

This report is against Differential.

An example of this behaviour can be seen at https://phabricator.kde.org/differential/query/eSo.v6zZDm4i/#R

In T12323#213451, @chad wrote:

We need version information on all bug reports.

Also, we need steps to reproduce. the issue locally. There are setting that affect where revisions go after acceptance. I don't know what your install has those set to.

Sorry, you'll need to provide more detail on what's wrong than repeating your comment. I added the version information to the Task Description.

Well that's my mistake then! I didn't see it initially.

I've now added reproduction steps, including details on customised settings for the Differential application.

Is sticky-accept still set to true then? (I think that's the default).

If sticky-accept is true, then I think the revision is still accepted after the update.

Yes, sticky-accept is True.

If the revision was "Accepted" then shouldn't it show under Ready to Land?

My assumption reading through docs and tasks is that "Other" means... well, other. It's been both accepted and rejected and I think it's important to convey it's not completely in one or the other state. If you set sticky-accept to false, then it will always go back for review. Maybe @epriestley has other thoughts. I would swear this came up recently though, but I can't find an absolute duplicate task.

T9372 is the main "Differential Buckets" task.

Note that these steps depend on who is viewing the page (or, specifically, who "Responsible Users" are). More concise steps are likely:

• Create a revision as Alice.
• Reject it as Betty.
• Accept it as Claire.
• As Claire, view Differential's "Action Required" view.

In this state, the revision is not accepted (Betty has rejected it) and not ready to land. The viewer (Clarie) can not act on it. The revision currently falls through the cracks a little bit and ends up in "Other Revisions".

I think there's a reasonable argument that that's a good place for it, but putting it in "Waiting on Authors" might be a little clearer. The expected next step is for the author (Alice) to address the rejecting user's (Betty) feedback.

Here's the downstream task: https://phabricator.kde.org/T5406

@bcooksley, feel free to mention that you've talked with me about stuff when filing tasks in the future. Like 90% of what shows up here spontaneously is pretty questionable, so unannounced reports get fairly strict scrutiny.

Sorry, yes I am bad cop sometimes. :(

The actual reproduction instructions are slightly more involved:

• Alice creates a revision.
• Betty rejects it.
• Claire accepts it.
• Alice updates it.
• Look at the revision list as Claire.

The revision now needs review by Betty, who has an active reject. Only Betty can move it forward.

Prior to the update, the revision already buckets into "Waiting on Authors", which I think is reasonable.

After the update, it should not go into "Waiting on Authors". I can add a "Waiting on Other Reviewers" bucket, I suppose. I dislike creating more buckets and also dislike conditional buckets, but this state is reasonable and doesn't really fit into the other buckets.

(They could also go into the existing "Waiting on Review" bucket, but I dislike mixing authored and non-authored revisions in that bucket.)