Making WordPress.org

Opened 5 weeks ago

Last modified 5 days ago

#7935 accepted defect (bug)

Core Trac Workflow Keywords Issue

Reported by: sirlouen's profile SirLouen Owned by: dd32's profile dd32
Milestone: Priority: normal
Component: Trac Keywords: needs-patch
Cc:

Description

This affects all tracs, but more specifically Core one
There a 4 keywords that have conflicting names:

  • needs-testing and needs-testing-info
  • has-design and has-design-feedback

Where is the problem?

Searches in the Custom Query are made whith a "contains" query filter. This means that searches are not based on exact matches. This means that if you search for either needs-testing or has-design you will receive results with needs-testing, needs-testing-info or the two. Same for has-designwith has-design-feedback

Solution

Simply modify this two keywords a little bit

For example, instead of:

needs-testing-info => needs-test-info or needs-info-tesing
and
has-design-feedback => has-feedback-design

The first one, the needs-testing one is specially important because both are conflicting and render queries of very poor quality.

Change History (9)

This ticket was mentioned in Slack in #core-test by sirlouen. View the logs.


4 weeks ago

#2 follow-up: @dd32
3 weeks ago

  • Priority changed from high to normal

Changing these to be less human readable isn't an ideal solution, I believe some of the reports have something akin to keywords LIKE needs-testing and keywords NOT LIKE needs-testing-info - perhaps the solution is to use existing built reports rather than freeform queries.

This needs to be discussed in #core and a direction formalised before any action can be taken on this ticket though.

#3 in reply to: ↑ 2 @SirLouen
3 weeks ago

Replying to dd32:

perhaps the solution is to use existing built reports rather than freeform queries.

This needs to be discussed in #core and a direction formalised before any action can be taken on this ticket though.

The problem with this, is that it doesn't provide the opportunity to check for certain types of tickets around needs-testing which happens to be a "key" keyword. For example, I was willing recently to review tickets that had both needs-testing and needs-testing-info at the same time specifically and was completely impossible.

In fact, I have to admit to you that this happens to be the most critical combination of keywords. The other one, I put as an example, was just another case of this inconvenience, but not as problematic as these two.

There are 2 solutions from my perspective:

  1. Repairing the Trac query system, either by adding exact matches with quotes or the liking, or by just considering each exact keyword for each match between spaces
  1. The simplest one that requires less coding: renaming either needs-testing or needs-testing info to avoid having them contained in each other. Just a little change like need-testing-info will also do the trick and I feel that I will not be less human-readable.

This ticket was mentioned in Slack in #core by sirlouen. View the logs.


3 weeks ago

This ticket was mentioned in Slack in #core-test by sirlouen. View the logs.


6 days ago

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


5 days ago

This ticket was mentioned in Slack in #core-test by pavanpatil1. View the logs.


5 days ago

#8 @joemcgill
5 days ago

@dd32 After discussion in a few dev chats, this seems like a good change to make to support the workflows our test team uses to triage tickets, since the existing Trac query filters don't allow for showing needs-testing without also showing needs-testing-info.

It looks like both needs-testing-info and has-testing-info were added in https://meta.trac.wordpress.org/ticket/5634.

We'd like to see these two custom keywords adjusted to the following:

  • needs-testing-info => needs-test-info
  • has-testing-info => has-test-info
  • needs-testing => No change.

Once these changes are made for the workflow keywords list and the associated JS that was added in https://meta.trac.wordpress.org/changeset/12154 to automatically remove keywords when others are added, I can handle transitioning any existing uses of the previous keywords on open tickets to the new versions (unless that's an easy thing to handle on your side).

P.S. Let's not change the design related keywords for now.

Last edited 5 days ago by joemcgill (previous) (diff)

#9 @dd32
5 days ago

  • Owner set to dd32
  • Status changed from new to accepted

Thanks @joemcgill - I'll see if I can take a look next week at what's needed here.

Note: See TracTickets for help on using tickets.