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 ticket edit in Trac 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 Triage 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:

  1. All tickets closed in the bulk edit due to inactivity will have their resolution changed from wontfix to maybelater.
  2. 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.
  3. 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 Slack 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 API, 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
  • HTTP API: 17
  • Help/About: 6
  • I18N: 28
  • Import: 36
  • Login and Registration: 54
  • Mail: 18
  • Media: 163
  • Menus: 77
  • Networks and Sites: 40
  • Options, Meta 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 API: 5
  • Revisions: 13
  • Rewrite Rules: 37
  • Role/Capability: 17
  • Script Loader: 25
  • Security: 14
  • Shortcodes: 18
  • Taxonomy: 73
  • Text Changes: 13
  • Themes: 73
  • TineMCE: 56
  • Toolbar: 12
  • Upgrade/Install: 80
  • Upload: 25
  • Users: 102
  • Widgets: 59
  • 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