Olga Gleckler 5:27 pm on March 5, 2025
Tags: test ( 142 )

Test Team Update: 3 March 2025

Test Ticket Queue 🎟

👉🏻 “(change: N)” represents changes from prior week (unless noted).

📊 Current totals (since Feb 24, 2025):

Need testing info: 18 (change: -1)
Need reproduce issue: 2018 (change: +1)
Need patch testing: 205 (change: -8)
Need unit tests: 105 (change: +5)
Need review (have patch and unit tests): 259 (change: -5)

🟢 New/Changed two weeks:

Need testing info: 2 (change: +2)
Need reproduce issue: 4 (change: -7)
Need patch testing: 14 (change: +4)
Need unit tests: 2 (change: +1)
Need review (have patch and unit tests): 21 (change: +8)

🟣 Closed two weeks:

Need testing info: 2 (change: +2)
Need reproduce issue: 21 (change: +18)
Need patch testing: 1 (change: -2)
Need unit tests: 0 (change: -1)
Need review (have patch and unit tests): 8 (change: 0)

To discuss queries used in this report, please comment below, or connect with the Test Team over in #core-test.

+make.wordpress.org/test/

#test

SirLouen 12:24 am on March 8, 2025

@oglekler I was asking today in #coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and it seems that needs-testing-info refers to those tickets than need instructions on how it should be tested so if it means this, its almost like reporter-feedback, its beyond control of the testing team. Maybe you have a different interpretation for this tag? Judging by reading this post https://make.wordpress.org/core/handbook/contribute/trac/keywords/, I can’t really see the meaning there 🙂
- Olga Gleckler 7:43 am on March 8, 2025
  
  Hi @SirLouen, thank you for notice of this. Sometimes we get so used to things that they become obvious to us, and we have no idea that it isn’t so for other people. The needs-testing-info is not about reporter-feedback, but a call to the patch maker or any other person who can figure out how the patch is working and how to test it. The patch maker can do it more easily than anyone else because this person made the patch and checked somehow that it is working already.
  
  This is also a good practice to write testing instructions before actually making a patch because this helps to foresee many possible scenarios that otherwise will be initially missed. Asking “What if? is very useful.
  
  Let’s summarize the description of the needs-testing-info keyword and add it to the list of keywords. @krupajnanda we can do it at the nearest team meeting. And we can also check if anything else needs to be done about keywords as well.
  
  Thank you!
  - SirLouen 10:20 am on March 8, 2025
    
    @oglekler good insight.
    
    For some reason, all the last tickets I was checking the ticket reporter == to the patch creator, this is why I was thinking about the reporter-feedback tag.
    
    From what I can understand from your answer, it’s a tag that it’s dependent on 3rd parties (the patch coder, or any other coder that can figure out this), beyond the testing team. Technically, the testing team can always put a “coding hat” to think and sort the conundrum, but I believe this is not a duty of the test team.
    
    Moreover, I’ve observed something that could be commented in the future meeting.
    
    Some reports, unit-test and patches might have a utility for sure, but without seeing it clearly sometimes patching them could even be detrimental without having the full picture. Understanding the use-case maybe could lead to an alt-way of solving the issue without touching the current code.
    
    So I think there is another tag that I’m missing, that would be something like needs-use-case-info. I found this in two recent reports, so I supposed that could probably very common:
    https://core.trac.wordpress.org/ticket/56992
    https://core.trac.wordpress.org/ticket/53076
    
    I feel that most reports simply don’t include this use-case info by default, and could be hitting negatively on the original purpose of certain functionality (for example, affecting WP performance indirectly by force-brute solving this report) or simply not offering the use-case info, like the report #53076 are a hassle for the test team, that have to build the whole thing that the reporter was a) Working on b) Thinking on. See for example my test report in 53076: Noone had the interest in testing and progressing that patch because it lacked of “use-case”. The testing-info could be pretty straightforward with a use-case (or not) but without the use-case it could not be pushed forward (or it could, if you put again, a “coding hat”).
    
    In a similar fashion, for the 56992 report that we were talking in the last bug scrub day, and you commented that a performance issue could be a risk. No member from the performance team has approached it, and it has been already merged into the trunk. Probably it will be released in 6.8 and might impact the performance of some people with big installations (or not). They could find how suddenly their queries are way slower than they used to be. And from my perspective, the problem here is not the fact that noone in the performance team checked and tested it, but the fact that the patch creator/use-case creator/reporter did not include a use case to check to which extent it was a worthy a solution. Maybe there were other workarounds without touching the original code.
    
    Questions like: Why do you actually want to modify this? What are you trying to achieve and failed that motivated you to post this report?
    
    I commented here:
    https://core.trac.wordpress.org/ticket/56992#comment:11
    
    Without an example of why this could be useful, I’m clueless of why this change is worthy, and despite the patch solves the issue, I’m not sure, if, in first place, there is a issue.
    
    But I still think that a needs-use-case-info tag would make things more clear, specially for patch/unit-test makers that tend to better understand this tagging structure.
    
    Apologies for the long post, but I would like to hear your opinion and @krupajnanda and maybe could be considered for a future meeting.
    
    Regards
    - SirLouen 3:29 pm on March 8, 2025
      
      Another Example:
      https://core.trac.wordpress.org/ticket/41757
      I would say as a rule of thumb, that most new hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same., clearly need a use-case that can be:
      
      1. Either an already ready existing pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party branch that could be willing to use this functionality.
      2. A dummy plugin that showcases this functionality.
      
      But expecting that the test team builds a use-case for each occurrence that a user has is unrealistic + adds a lot of subjectivity to the test because we adapt the expected results to the test and not the other way around. This is why I find useful this needs-use-case-info tag could be very healthy for the testing team progression.
      
      And again, it’s important to distinguish from needs-test-info because some people actually write the unit-tests which help a lot in designing a testing protocol, but similarly with those tests, we could be distorting the expected results before understanding the actual facts that got to that reasoning. Yes, the unit-test works with the patch, the test info makes sense, and we can reproduce and confirm that the patch works, but the question of: “does this thing make sense” remains unsolved.
      
      This can be a little controversial, but to some extent the tracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. sometimes feels a little like a self-service buffet.
    - SirLouen 8:23 pm on March 8, 2025
      
      More ideas:
      
      In the Need patch testing query: I would add
      -needs-testing-info
      
      If it explicitely says that it doesn’t have Testing Info, it cannot be tested.
      
      https://core.trac.wordpress.org/query?status=accepted&status=assigned&status=new&status=reopened&status=reviewing&keywords=~needs-testing+has-patch+-dev-feedback+-2nd-opinion+-close+-needs-refresh+-needs-design+-needs-design-feedback+-needs-testing-info&milestone=!Awaiting+Review&col=id&col=summary&col=status&col=milestone&col=keywords&col=type&col=priority&col=component&col=changetime&desc=1&order=changetime

Test Ticket Queue 🎟

📊 Current totals (since Feb 24, 2025):

🟢 New/Changed two weeks:

🟣 Closed two weeks:

Share this:

Site resources