Beta 3 is Coming: Trac Ticket Owners, Please Update Your Tickets

Per the schedule, WordPress 4.5 Beta 3 will be released in the hours following today’s weekly dev meeting, which is at March 9, 2016 at 1pm PST.

There are currently 72 tickets in the milestone remaining. This is great movement from last week (thanks!), but before the release of Beta 3, I’d like to see this down to 50.

To support this, we’ll run a triage, starting after status reports in the dev meeting, extending afterwards for as long as folks want to stay to work on the milestone.

For next week — by Beta 4 — let’s target no more than 25 tickets in the milestone.
As a reminder, the report needs to be entirely clear before Release Candidate 1 (two weeks from now).

If you own ticket(s) on Trac in the 4.5 milestone:

  • If your ticket will not be finished in the very near future, please punt it to Future Release.
  • If your ticket will be finished in the very near future, please add an update as to what is left as a comment on the ticket, including an estimated completion timeframe if possible.

Thanks to everyone for your help!

#4-5, #trac

We’ve moved the SVN and Trac firehose mailing…

We’ve moved the SVN and Trac firehose mailing lists to lists.wordpress.org, from the legacy lists.automattic.com. If all goes well, we’ll move the rest of them over as well.

The one side effect is this is likely to break your existing mail filters. The new mailing list emails are wp-trac@lists.wordpress.org and wp-svn@lists.wordpress.org. If you’re using Gmail’s mailing list filters, those would now look like list:wp-trac.lists.wordpress.org.

For those of you who use Gmail, I’ve also added basic styling to the SVN commit emails. Hooray for reading diffs with red and green. (For those who don’t use Gmail, you’ve already been seeing styling that Gmail strips out.)

Just a reminder you don’t *need* to use the Trac firehose. You can also subscribe to individual tickets, milestones, components, focuses, new tickets, etc.

Another note: WordPress.org is now forced SSL. Announcement and details here.

gmail-diffs

#mailing-lists, #notifications, #svn, #trac

Fine-grained Trac notifications

Some housekeeping items to share so I don’t need to cover it in the meeting today:

New notification preferences are live. On the notifications page, you’ll be able to subscribe to activity from all tickets in a particular milestone, component, or focus. You can also subscribe to only new tickets, in case you want to then selectively watch tickets as they come in.

New greeting on make/core. Look up. Or if you’re viewing this post directly, check out the homepage. Right now the “Get Involved” menu item leads you to there, but it’d been tough to know where to go from there. This serves to introduce new people and get them information quickly: what this blog is, where to file a bug, how to start contributing; and provides some info about IRC and our meetings.

New, simpler new ticket form: I simplified the new ticket form, cleaning up the warnings, text, and chrome (it had a lot of borders and fieldsets and such). It looks much less intimidating now.

New ticket reports and component pages. These went live late last week — here and here.

Create a new ticket This was also helpful because we shifted around where you can go to create a new ticket. You can now do it from search results, all ticket reports and the main reports screen, component pages, the icon in the navigation, and now from the make/core homepage. The new reports screen is a new entry point for Trac. You’ll note it actually duplicates the content of Trac’s home page (new ticket button there too), which you’ll have trouble finding a direct link to anywhere.

Focuses/components: Component and focus triaging is pretty much done. (More than one thousand open tickets — 30% — have been modified in the last two weeks alone.) Still have some decisions to make about the Administration component, but I’m not worried.

And with that, I actually have no more changes planned for core trac. Except for ticket smashing. It’s now time to start clearing these two reports: Tickets without a response and Tickets that are ancient and inactive. Who is with me?!

Thanks also @ocean90 for replacing every last icon in Trac with a Dashicon. Love it.

#housekeeping, #trac

Proposed Trac component reorganization

Warning, this long. tl;dr: I propose a reorganization of our Trac components. 34 top-level components with two dozen subcomponents. New tree at the bottom. First, an overview of some of our problems.
Continue reading

#components, #trac

Continuing the Trac component re-organization with "focuses"

Based on triaging a few hundred tickets in the General and Multisite components, we’ve added five components:

  • Bootstrap/Load — applies to wp-settings.php, ms-load.php, load.php, ms-settings.php, etc.
  • Login and Registration — useful for multisite, but applies to single-site too
  • Options and Meta — option.php, meta.php, etc.
  • Script Loader — WP_Scripts, WP_Styles, and script-loader.php
  • Networks and Sites — multisite only

We also removed two components that (poorly) described the problem rather than the affected area of core. “Validation” ranged from from validation tickets to XHTML issues. HTML validation issues now belong in the affected component, like “Template” or “Administration.” “Warnings/Notices” contained tickets ranging from PHP warnings to providing feedback to users. The open tickets were moved to more appropriate components. Additionally, the remaining tickets in “AtomPub” were wontfixed and the component was removed.

A new concept: Focuses

We’ve also added seven new “focuses”ui, accessibility, javascript, docs, multisite, performance, and rtl. Focuses are about broad concepts and help break tickets down by specialties and skills, rather than functional areas of core. Multisite and RTL are widely general “modes” for WordPress, and each have contributors who focus strongly on those areas, but they are not well-contained “components” of core. Accessibility isn’t an area of core — it permates the entire user experience. A ticket about inline documentation should still receive the attention of developers for that area of core (say, comment.php), while those who focus on inline documentation should still be able to do so.

“Focuses” is a new field in Trac. They’re like tags, and more than one can be assigned to a ticket. It can be queried using custom queries. And they have their own reports which we hope to properly expose and make better really soon — https://core.trac.wordpress.org/focus/accessibility.

Guidelines to help with the transition

The corresponding components for the new focuses have been removed. The “ui-focus” keyword has also been converted over. Overall, we gained five components but lost eight.

This has the potential to be confusing at first and we’ll surely need to make some adjustments. Also, the component cleanup is not done yet — this is just the beginning. Here are some guidelines for how to use the new focuses.

  • The old RTL component — use the rtl focus and assign a relevant component. If it’s RTL issues with the media library, use the “Media” component. If it’s about the RTL build tools, then use the “Build Tools” component. If it’s more general, then use the “I18n” component.

  • The old Accessibility component — use the accessibility focus and assign a relevant component. For issues with the media library, use “Media.” For issues with activating a theme, use “Themes.”

  • The old Inline Docs component — use the docs focus and assign a relevant component. Hook documentation for user.php belongs in the “Users” component.

  • The old Multisite component — use the multisite focus and assign a relevant component. If it’s related to users, use “Users.” If it’s related to the loading process of multisite (choosing a site based on domain and path, etc.), use “Bootstrap/Load.” If it’s related to the installation process, use “Upgrade/Install.” network_admin_url() goes into the “Permalinks” component. get_site_option() is “Options and Meta.” The Network Admin still has its own component. (Choosing that component or “Networks and Sites” automatically assign the “multisite” focus for you.) @jeremyfelt recategorized about 110 tickets into about 15 different components.

  • The old Performance component — use the performance focus and assign a relevant component. Improving the performance of WP_Query belongs in “Query,” improving the performance of get_option() belongs in “Options and Meta,” etc.

  • The old Graphic Design component — use the ui focus and assign a relevant component. (This is probably going to be “Administration”, at least for now.)

  • The old ui-focus keyword — This has been removed. Simply use the ui focus.

  • The old JavaScript and UI components — these have not existed for some time. Use the corresponding focus and assign a relevant component.

We may add more focuses over time. For example, the “Text Changes” component would probably make a better focus, for our wordsmiths.

Any questions, suggestions, or comments?

This is a summary and addendum of one section of this Wednesday’s weekly developer meeting. Logs.

#components, #trac

Brainstorming ticket reports

One thing I’d like to work on is improve our reports on Trac with the hope we can better manage the ticket queues. We currently have about 50 reports on Trac. Many of them were created in a push 5-6 years ago to build reports around keywords. A number of others are one-offs created in the last few years for specific use cases. In reality, few of these are ever used on a day-to-day basis.

I checked the access logs to get an idea of the most popular reports. Besides the first six reports (my favorite “home base” is report 6), they are report 16 (“Needs Patch”), report 18 (“Blockers for Releases”), and report 21 (“Latest Tickets”).

What I’d like to do is brainstorm all sorts of new reports we should have. How can we make what we have better? I’ll then go to work about implementing them. Dream big — if the data’s there, I’ll figure out the gnarly SQL required. We can also think about how we can improve columns, grouping, ordering, etc. If you have a concept for a report but aren’t sure how we’d query for those tickets, toss the idea out there and maybe someone will add to it.

I’l probably design a new /report screen so it’s not just a list ordered by something random like when the report was created, and so we can highlight important reports, group similar reports together, and put less emphasis on some of the more specialized ones.

Here are some half-baked ideas, to start us off:

  • Open tickets without a response. Find all tickets where no one has commented, or where only the reporter has commented. This would create a punchlist of tickets to review. (Ideally, the report should always be empty.) The ability to group or filter this by component would be helpful, for contributors who specialize in and want to take responsibility for different areas.
  • Report of “dead” tickets. Tickets that haven’t been modified in four years are ripe for action and/or closure. We should empty a report of this nature, then reduce it to 3.5 years, then 3 years, etc.
  • Good first bugs. A report of all tickets marked as a good first bug. (None yet, as the keyword is new.) Next steps: How can we best identify these kinds of tickets?
  • Report of “untriaged” tickets. Our milestones have gotten out of hand, which is something we should discuss. Tickets should immediately leave “Awaiting Review” once they’ve been initially reviewed, but then not forgotten about if they are shifted to “Future Release”. Let’s figure out metrics for what makes a ticket “untriaged”. We could create a simple UI to filter by component for a report like this. We currently have Tickets Awaiting Review which groups tickets by the “Version” they were reported against — maybe this is a good start.

What’s your idea?

#reporting, #trac

New Trac notifications feature

Monday’s long list of improvements to Trac was just the first course. Introducing per-ticket notifications.

Just above the comment box, you’ll see a new notifications pane. Here, you can watch/unwatch tickets.

This means Trac’s terrible email address CC feature is gone. (Last night, I migrated over about 15,000 CCs going back nine years.) Old comments that are just CCs are now hidden via JS, which makes a few of the busier or popular tickets easier to skim.

You can also click the star next to the ticket number at the top:

Screen Shot 2014-01-09 at 4.38.22 PM

Watching a ticket adds it to some new reports: open tickets I’m watching and all tickets I’m watching. Now your list of starred tickets are all in one place.

Coming soon: You’ll be able to watch/unwatch a ticket directly from a report, like starring conversations in a Gmail inbox (edit: added). You’ll also be able to subscribe to entire components and milestones (here’s a sneak peek). And, @-mentions will let you add someone to a ticket.

A note on how this is implemented: isn’t just subscribe/unsubscribe. “Watch” can also be thought of as “Vote” or “Star” or “Favorite”. We’ll soon add a star count to reports (next to the new Comments column — edit: added). If you’re watching a ticket, you’ll always get notifications. If you’re not, you might still get notifications if you reported the ticket, or are subscribed to that ticket’s component or milestone, or if you’ve been mentioned (and the notifications box will tell you that). From there, you have the option to actively “Watch” the ticket, passively continue to receive notifications, or specifically mute/block notifications coming from that ticket.

Follow-up question from @sabreuse, about watching/voting/starring/favoriting: If you subscribe to the “firehose” (wp-trac mailing list) and receive all notifications anyway, should you star tickets anyway as an indication of interest? Yes, I’d say so! (If you receive the mailing list to the same email address as your WP.org profile, you’ll only receive one email. It’s possible your mail client could ascertain you received it as a BCC versus just via a mailing list, though I’m not sure.)

Feedback, ideas, suggestions are very much appreciated. Also, all of this code is open source (a lot of it is a WordPress plugin).

Edit, bonus: @ocean90 converted most icons on Trac into Dashicons.

#notifications, #trac

Lots of improvements to Core Trac

Over the holidays, I was sick for two weeks (boo). While resting and recovering, I took to working on our tools (yay). Specifically, Trac. Here’s an overview of the added features, enhancements, and bug fixes. There’s a lot (and more on the way), so I’ll try to keep each point brief. If you have any questions I’d be happy to elaborate in the comments.
Continue reading

#trac

The email used for notifications on Trac is…

The email used for notifications on Trac is currently specified in Trac preferences. I’m changing this to pull automatically from your WordPress.org profile. After this change, there will not be a way to have a separate email address for Trac and any manually specified email address will be overridden.

We need to make this change because, very simply, it’s a better user experience. By killing this extra user preference, it’s one less step users need to set up in order to receive notifications. (And a tighter feedback loop could possibly boost engagement.)

That will affect about a thousand users we have in the system, probably incidentally for most. But, about 50-100 users might have been deliberately declaring a separate email address; for example 50 users had “trac” appear specifically in their email. Even without a dedicated email, it is trivial to filter Trac emails; you just might need to make some adjustments.

As you may have noticed, this is part of a series of changes I’ve been making to Trac. I’ll be doing a summary post in a few days outlining everything that has changed.

NOTE: This does not affect wp-trac@lists.automattic.com. If you subscribe to the “firehose” this is not affected.

Edit, 20:23 UTC. This is now enabled. For the moment, the email address will sync when you next visit Trac. Please find me if you have any questions.

#housekeeping, #trac

Trac email issues are fixed

Unfortunately, the Trac mailing lists for WordPress Core and BuddyPress were missing many tickets and comments over the last few days. (From about October 15, 12pm ET to about October 17, 2am ET, an hour ago.)

I OK’d a change to the Trac configs, but forgot about the restrictive mailman rules designed to block spam on these read-only lists. My bad.

Many of us of course rely on these mailing lists, to the point where if it fails, we miss comments or entire tickets. To explain why you may have gotten some emails, but not all: You would have gotten it directly from Trac (rather than the mailing list) if you were already participating on a ticket.

I’ve added support for ticket comments directly in the Trac timeline across all Trac instances on wordpress.org. Here are links to days with missing time periods:

Note that the “From” email for these mailing lists is now noreply@wordpress.org. Rather than something@lists.automattic.com. You may need to adjust Gmail filters as appropriate (there hasn’t been a spam issue on these lists for some time; consider targeting list headers).

Let me know if you have any lingering issues or questions.

#trac