Jonathan Desrosiers 8:33 pm on January 14, 2019
Tags: core ( 561 ), trac ( 58 )

Follow Up on Recent Trac Bulk Edit

Update: More up to date information was detailed in a more recent post, Reverting the Bulk Ticket Closing.

On January 4, there was a bulk ticketticket Created for both bug reports and feature development on the bug tracker. edit in TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. that affected approximately 2,300 tickets spanning all components that had not been modified in at least 2 years. The bulk action performed was setting the ticket status to closed with a resolution of wontfix.

A full list of the tickets closed can be viewed using this Trac query.

Follow Up Discussion

During last week’s devchat, there was a productive discussion about what happened and how to move forward from there. Listed below are some of the main takeaways:

Context
- The bulk edit was not related to the recent Short Term Trac Milestone Ticket Triage Proposal.
- A goal of the new Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. Team will be to establish better processes for performing updates to tickets, including bulk updates if any are warranted.
- Bulk actions spanning multiple components should be communicated ahead of time.
- Each component having hundreds of open tickets makes it difficult for new contributors to see where they can help most.
- Many tickets take a lot of institutional knowledge to identify the best paths forward.
Hurdles
- Component maintainers and Trac gardeners need clear expectations for how to treat those closed tickets. Triaging tickets that are closed is hard.
- The wontfix keyword may not have been appropriate here. “Won’t fix” sounds like an active decision based on the lack of merit for a ticket. This may not be the case for most of the tickets closed.
- Perhaps older tickets are getting lost in the reports currently offered on Trac.
Suggested Solutions
- wontfix needs to be re-evaluated. maybelater is a resolution that fits this scenario better.
- Define or agree on what constitutes “no activity”
- A “stale” designation may help. Stale notices could remain open but be hidden from standard reports.

Proposed Path Forward

After the conversation in devchat, it was decided that this post would be a better place to continue discussion and reach a final conclusion.

Below is the process moving forward that is being proposed after taking into account all of the feedback received so far:

All tickets closed in the bulk edit due to inactivity will have their resolution changed from wontfix to maybelater.
Component maintainers are free to reopen tickets closed as a result of this bulk action, as long as they have a plan to triage the list within a reasonable amount of time.
Just like component maintainers are free to reopen the tickets closed, they are also free to leave them closed. But, the closed tickets should be scrubbed to make sure that no important tickets were closed accidentally.

Those in the component maintainer role would discuss these options in their component meetings or SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. rooms and reach a decision of what path works best for them.

The actions chosen for each component should be communicated in the component’s weekly meeting summary and in the comments below. The plan should also be clearly communicated in the form of a comment in Trac if the tickets are reopened.

If a component wants to reopen their tickets but needs help scrubbing the list, include that in your comment below and a plan can be created for going through the list. The three components without active maintainers (Filesystem APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways., Pings/Trackbacks, Rewrite Rules) will have the closed tickets scrubbed by myself (@desrosj) and other members of the Triage Team (once it is fully formed) to ensure nothing important was closed.

The correct way to reopen tickets for the components that wish to do so will be communicated once it is determined. The best way forward will depend on the feedback on this post and from component maintainers. But, this could be one of the following:

Bulk edit to reopen component by component.
Trac database query to reopen, remove resolution, comment.

More Details

Below is a summary of the number of closed tickets grouped by component:

Administration: 118
Autosave: 7
Bootstrap/Load: 18
Build/Test Tools: 27
Bundled Theme: 10
Cache API: 16
Canonical: 30
Charset: 6
Comments: 63
Cron API: 11
Customize: 49
Database: 34
Date/Time: 11
Editor: 76
Embeds: 12
Emoji: 2
Export: 24
External Libraries: 13
Feeds: 17
Filesystem API: 24
Formatting: 100
Gallery: 16
General: 172
HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. API: 17
Help/About: 6
I18Ni18n Internationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill.: 28
Import: 36
Login and Registration: 54
Mail: 18
Media: 163
Menus: 77
Networks and Sites: 40
Options, MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. APIs: 40
Permalinks: 53
Pings/Trackbacks: 15
Plugins: 53
Post Formats: 4
Post Thumbnails: 4
Posts, Post Types: 151
Query: 69
Quick/Bulk Edit: 24
REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/.: 5
RevisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision.: 13
Rewrite Rules: 37
Role/Capability: 17
Script Loader: 25
Security: 14
Shortcodes: 18
TaxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies.: 73
Text Changes: 13
Themes: 73
TineMCE: 56
Toolbar: 12
Upgrade/Install: 80
Upload: 25
Users: 102
Widgets: 59
WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ Site: 3
XML-RPC: 27

Feedback

Do you have more to add to the discussion? Concerns with the proposed plan above? Please share them below!

#core, #trac

JJJ 8:54 pm on January 14, 2019
- The only reason to close a ticketticket Created for both bug reports and feature development on the bug tracker. is because the feature is complete, or the issue is invalidinvalid A resolution on the bug tracker (and generally common in software development, sometimes also notabug) that indicates the ticket is not a bug, is a support request, or is generally invalid..
- The open ticket count is just one number out of infinite. It means nothing negative. It isn’t a queue to work through. It isn’t supposed to be zero. It does not represent anything good or bad. It’s just a number.
- TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. gives us an equally infinite number of ways issues can be filtered, including or excluding open and/or closed.
What I’m reading here are reporting issues, that should be solved with software. We should not be changing the status of thousands of tickets just to clean up reporting.

Consider a piece of software like Akismet. If you trashTrash Trash in WordPress is like the Recycle Bin on your PC or Trash in your Macintosh computer. Users with the proper permission level (administrators and editors) have the ability to delete a post, page, and/or comments. When you delete the item, it is moved to the trash folder where it will remain for 30 days. a comment instead of marking it as spam, Akismet doesn’t get to do it’s job. By closing issues instead of leaving them open, contributors don’t get to do theirs.

Instead, contributors need to guess at why an issue was closed. Identify the correct component maintainer. Hunt them down in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.. Figure out when the team meeting is. Lobby for the issue to be reopened. Maybe or maybe not communicate that clearly enough to get it opened. Etc…

^– All of that is new work we are inventing for ourselves by invoking a policy of closing issues just-because.
closed tickets should be scrubbed to make sure that no important tickets were closed accidentally

This is everything I don’t like about bulk-closing tickets: rework on top of rework.

The open/close/open dance of whether or not something matters enough to whomever was hard enough when everyone was doing not enough.

Adding component maintainers and a triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. team who are looking to open and close issues, that another team mistakingly closed or opened without enough momentum, will only result in more email chatter, more conflictconflict A conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved., more Trac activity (and activity in wporg profiles) and more debate about tickets that aren’t causing any harm as is.

It does not produce more patches.
It does not welcome more contributors.
It is not less work.
It is not easier.

I’m a big huge -1 on all of this. Leave it as-is, and fix reporting instead.
- Jonathan Desrosiers 8:58 pm on January 14, 2019
  
  fix reporting instead
  
  Can you detail this a bit more? What changes to reporting would you propose? What are new reports you would like to see? Reports you feel don’t work?
  - JJJ 9:01 pm on January 14, 2019
    
    I’ve been using TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. for a long time, and I’ve never felt its reporting to be lacking. Maybe that’s because I’m fluent and comfortable with it?
    
    What I’m saying, is that it sounds like (from the meeting notes) other people have issues using the reporting tools to narrow the results down to what they want to see (if open/closed is producing too many tickets.)
    
    Sorry for not making that more clear.
    - Jonathan Desrosiers 9:03 pm on January 14, 2019
      
      Thanks for clarifying!
- Ian Dunn 8:06 pm on January 20, 2019
  
  I agree with John here. Tickets are opened because someone experiences a bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority., or has an idea for an improvement. Those bugs still exist, and those ideas are still potentially useful, but now they’re less likely to be acted on.
  
  The choice of `wontfixwontfix A resolution on the bug tracker (and generally common in software development) that indicates the ticket will not be addressed further. This may be used for acceptable edge cases (for bugs), or enhancements that have been rejected for core inclusion.` was also very unfortunate, because it’s not accurate, and will lead to people feeling dismissed without even a polite explanation as to why.
  
  If the problem caused by having lots of open tickets is that it makes it harder for new contributors to find `good-first-bugs`, then I think a better solution would be to leave tickets in the `open` status, but add a `stale` keyword automatically. Then, we can modify the saved reports to hide `stale` tickets by default.
  
  That will keep new contributors for being overwhelmed, but it’ll still be easy for experienced contributors to run queries that don’t include that filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output.. Keeping the tickets open would avoid the negative side effects that come with closing tickets that aren’t actually resolved.
  
  Another idea would be doing a better job of promoting the existing good-first-bugs report, and onboarding new contributors in general.
  - Ian Dunn 8:23 pm on January 20, 2019
    
    Er, I just noticed that the tickets do have a comment with a friendly and helpful explanation for why they were closed. I hadn’t noticed that before because the email notification never went out.
    
    I still think that `maybelater` is a much better choice if we’re going to leave them closed, though.
Andrew Ozz 10:27 pm on January 14, 2019

wontfix needs to be re-evaluated. maybelater is a resolution that fits this scenario better.
…
A “stale” designation may help. Stale notices could remain open but be hidden from standard reports.

Thinking that a stale “closing” status would fit there even better than maybelater.

Also, there were several “talks” over the years to auto-close stale tickets, perhaps it’s time to finally bite the bullet? 🙂 Of course everybody is free to reopen any closed ticketticket Created for both bug reports and feature development on the bug tracker. providing a good reason.
Stephen Edgar 2:15 am on January 18, 2019

There were 2 tickets closed in the Build/Test Tools component that I plan on reopening, my plan of re-opening those is to delete the “comment” that was added in the bulk closing of tickets, this will restore those two tickets to their previous state and to my mind that is the best option for these two tickets rather than re-opening with further comment to restore them to their previous state.
Joe McGill 11:26 pm on January 18, 2019

Personally, I have felt the cost to having too many open issues without any movement for long periods of time, so I think some sort of regular purging of stale tickets makes pragmatic sense. However, I agree that `wontfixwontfix A resolution on the bug tracker (and generally common in software development) that indicates the ticket will not be addressed further. This may be used for acceptable edge cases (for bugs), or enhancements that have been rejected for core inclusion.` is the wrong resolution in these cases. I think `maybelater` is a perfectly valid resolution, since it indicates that the issue might be reopened if/when there is reason for that issue to be prioritized in the future.

If others come across the same issue in the future, they should find the previous ticketticket Created for both bug reports and feature development on the bug tracker. and feel free to reopen the issue.
Ian Dunn 8:26 pm on January 20, 2019

This is a useful report for anyone who wants to check which of the closed tickets are ones they’ve participated in:

https://core.trac.wordpress.org/report/54?sort=modified&asc=0&USER=iandunn&page=1

Replace the `USER` param with your username, then look for ones closed on January 4th.
Ian Dunn 8:56 pm on January 20, 2019
The Security component doesn’t have any maintainers (it’s not even listed on the page), so I went ahead and re-opened the following:
- #20140
- #24907
- #29429
The rest seemed ok to leave closed at first glance, but I changed the resolution to `maybelater`. That’s more accurate, and will also notify people that the ticketticket Created for both bug reports and feature development on the bug tracker. has been closed, since the original batch modify didn’t send email notifications.
Garrett Hyder 1:06 am on January 24, 2019

One thing I feel frustrated many people was the limitation in TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. for notifications on such bulk scale. Many users aren’t even aware their tickets were closed, and still aren’t. It sounded like re-open was a direction to go down, which I support, and if it goes that way may I suggest chunking up the bulk within a smaller threshold so the system has a better chance of successfully notifying users. I am unaware of the limit but if we can stay within it and notifications are successful there would probably be more stakeholders coming to take action on their forgotten tickets.
- Garrett Hyder 1:08 am on January 24, 2019
  
  Another issue with the bulk email was the mass list of numbers which breaks part way leaving confusion. Would be nice to replace all that with a single link to a custom query on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. for the bulk report.
Gary Jones 11:21 am on February 5, 2019

> Each component having hundreds of open tickets makes it difficult for new contributors to see where they can help most.

Along with the good-first-bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority., could the priority help here? https://core.trac.wordpress.org/tickets/good-first-bugs doesn’t even have a priority column.