WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Tagged: trac Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 8:44 pm on February 5, 2014 Permalink | Log in to leave a Comment
    Tags: , 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.

     
  • Andrew Nacin 9:01 pm on January 27, 2014 Permalink | Log in to leave a Comment
    Tags: , 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.
    (More …)

     
    • Helen Hou-Sandi 9:22 pm on January 27, 2014 Permalink | Log in to Reply

      I am particularly excited about how groups and maintainers will (hopefully) form around components and focuses. Anybody can comment on a Trac ticket or pitch an idea or create a potential roadmap, but there’s a real sense of empowerment when you really feel like you’ve got your head and hands wrapped around a specific area, and are perhaps even recognized for doing so.

      I know for me personally it’s been really gratifying to be entrusted to run with a particular area (what we can now define as the UI focus) and has made me feel more comfortable with interacting and pushing core forward. And not just when it comes to UI development and conception, but in other areas as well. I also might just dare hope that we can stop the worst of the ticket rot, with having both more bodies as well as a clearer idea for hopeful contributors as to where to go for more feedback or help.

    • nofearinc 9:23 pm on January 27, 2014 Permalink | Log in to Reply

      I’m curious about the Query branches of Comments and Users – too many tickets for these types of Queries or plans to extend a lot furthermore?

      Great list though, and the “hall of fame” with notes is awesome.

      • Andrew Nacin 9:28 pm on January 27, 2014 Permalink | Log in to Reply

        I don’t think either is necessarily the case. The idea was to create a specific subcomponent under Users that those focused on Query (in general) could also specifically follow. Same for Comments. So in this case, it’s about granularity, not necessarily roadmap or ticket counts. Query is goofy, as I mentioned in the post — it’s a cross-section that would normally be good as a focus, but it actually covers functional areas of core (there just happen to be a lot of areas).

    • StyledThemes 9:24 pm on January 27, 2014 Permalink | Log in to Reply

      Give me a BIG Pot of coffee and I will ready this shortly…however, I saw the part of Bootstrap which caught my eye as I build my themes with it (well, parts of it). But from what I see in the list, looks interesting overall.

      • Andrew Nacin 9:25 pm on January 27, 2014 Permalink | Log in to Reply

        Bootstrap is not Twitter Bootstrap, it’s the “loading” process of WordPress. I may rename this to Bootstrapping if it’s a problem.

        • StyledThemes 9:34 pm on January 27, 2014 Permalink | Log in to Reply

          ah… how about WordStrap :)

        • nofearinc 9:37 pm on January 27, 2014 Permalink | Log in to Reply

          That’s the initial association of many folks btw, even knowing what Bootstrapping is, the recent popularity of the Twitter’s thing is overlapping actively, just my 2¢

        • jack96161 10:26 pm on January 27, 2014 Permalink | Log in to Reply

          Agreed, Twitter commandeered “Bootstrap” for too many in the community these days — greybeards like me know what a real bootstrap is, but renaming it will eliminate more questions like this in the future. I always liked the “Progenitor Process”, we used in an early operating system at HP, but it will probably end up as something like “startup”, “init”, or other bland 2-syllable invention …

          • jack96161 10:34 pm on January 27, 2014 Permalink | Log in to Reply

            Just noticed on the 3.9 Trac pages that “Bootstrap/Load” is used as a component name — I’ll vote for that one and the Twitterites can just deal with it!

    • Aaron Jorbin 9:52 pm on January 27, 2014 Permalink | Log in to Reply

      One additional focus that may make sense is Unit-Tests. The use case I’m thinking of is a patch that just adds unit tests. It would go in the component that it most directly deals with as I think the test tools component is more focused on the tools of testing rather than the actual tests and receive the focus of Unit-Tests (and optionally the JavaScript focus if it is a javascript unit test)

      • Andrew Nacin 10:07 pm on January 27, 2014 Permalink | Log in to Reply

        Ah, yeah, I forgot to mention this. This is also on my list. I’m still trying to figure out how it overlaps with keywords (needs-unit-tests and has-unit-tests), so I saved it for later. Does needs-unit-tests and has-unit-tests simply trigger the unit-tests focus automatically? If a ticket is opened specifically to provide unit tests for something, is that more of a has-patch situation? etc.

        • Aaron Jorbin 11:27 pm on January 27, 2014 Permalink | Log in to Reply

          I think needs-unit-tests and has-unit-tests should trigger the unit tests focus.

          Has-patch makes sense in the just adding unit tests case since it is fixing the reported issue (not having unit tests) while I think needs-unit-tests and has-unit-tests is more workflow oriented.

    • Jon Brown 12:15 am on January 28, 2014 Permalink | Log in to Reply

      This looks great. You’ve done a great job of making the parents obvious (fwiw, I’d keep bootstrap as bootstrap).

      Two things seemed non-obvious to me, and maybe that’s just unfamiliarity on my part, but worth mentioning.
      First – Formatting-Shortcodes/Charset. This seems non-obvious to me but I’m guessing this is processing raw content, essentially wpautop, it’s brethren and associated filters. Formatting sounds more like CSS to me than filtering/processing content.
      Second – There are separate top level categories for HTTP API & XML-RPC. It seems to me this could be a single top level “Remote/External APIs” component with sub-components for HTTP, XML-RPC, JSON, etc… Maybe that’s makes no sense though though since code wise they’re entirely separate.

      Again, great work sifting all this into these components, these are just comments as I read through and understand what’s group where, why and what each component covers.

      • Andrew Nacin 7:01 pm on January 28, 2014 Permalink | Log in to Reply

        Formatting has been called Formatting, well, for as long as I’ve been around. It also centers around formatting.php. It might not be the best name, but yeah, it’s for processing raw content. We’ll make sure the description and search keywords for it are solid.

        For right now, HTTP and XML-RPC have pretty much zero overlap in form or function. We’ll need to revisit everything here anyway when the REST API comes into core. (Gut reaction would be a component for the server, and a focus to handle APIs specific to another component.)

    • Robert Dall 12:30 am on January 28, 2014 Permalink | Log in to Reply

      I am not sure if we want to confuse the themes & bundled theme anymore then they already are. When I gave a talk on trac and I explained why it is called bundled themes a couple light bulbs went off in the crowd. But yet they knew what default themes meant. It’s all semantics, but now that understand why themes and bundled themes are different.

      What I *REALLY* like is having a subcomponent for each theme in development. We could still use use the title to differentiate between Twenty-Thirteen and Twenty-Fourteen as is the current standard but having this and the easy of use sounds whole lot better and easier for query’s of trac etc…

      • Andrew Nacin 1:12 am on January 28, 2014 Permalink | Log in to Reply

        I’ve got no issue renaming Bundled Theme to Default Themes, and we can definitely nest individual components underneath it for each theme. The issue I see would be that if we added subcomponents for each default theme directly under the Themes component, where would a ticket go that affects more than one theme? (This isn’t entirely uncommon.)

        • Sam Sidler 4:19 pm on January 28, 2014 Permalink | Log in to Reply

          In the main Bundled/Default Theme component? I assume the components are still usable even when subcomponents exist.

          • Andrew Nacin 6:47 pm on January 28, 2014 Permalink | Log in to Reply

            Sorry, I should have been more specific. Option 1, which is totally fine;

            Default Themes

            • Twenty Ten
            • Twenty Eleven

            Option 2, which I’d prefer (and which I thought RDall was hinting at):

            Themes

            • Appearance
            • Widgets
            • Nav Menus
            • Twenty Ten
            • Twenty Eleven

            My point was I’d like to merge “Bundled Theme” (or “Default Themes” or whatever) with “Themes” to make it even less confusing. But then I’m not sure where general default theme tickets (affecting multiple themes) would go — getting dumped in “Themes” means they may get lost.

        • Robert Dall 6:20 pm on January 28, 2014 Permalink | Log in to Reply

          Does it need a subcomponent if it effects all themes? Or are subcomponents required when they exist?

  • Andrew Nacin 6:54 pm on January 24, 2014 Permalink | Log in to leave a Comment
    Tags: , 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.

     
    • Helen Hou-Sandi 7:06 pm on January 24, 2014 Permalink | Log in to Reply

      Really excited to see this happening. I think focuses will give us a really solid place to point new contributors, as not all of them (or perhaps not even many of them) have any idea what components of WordPress they might want to work on, but they do know they’re into UI making or JavaScript. I think it also conceptually just makes more sense – there are functional components of core, and there are concepts that apply to all areas of core and are not fundamentally separate, like accessibility and documentation.

    • Jeremy Felt 7:49 pm on January 24, 2014 Permalink | Log in to Reply

      Many +1s, this is great. Two things come to mind.

      1 – Is it clear (or is it true) that UI focus covers UX as well or should that still be handled via keyword? I assigned a couple to UI focus last night thinking that it would generally cover that.
      2 – We should try to distinguish what belongs in ‘Network and Sites’ vs ‘Network Admin’. I left a bunch that dealt with adding new sites in ‘Network and Sites’, but because it deals with `wp-admin/network/site-edit.php`, it may be better in Network Admin.

      • Jeremy Felt 10:48 pm on January 25, 2014 Permalink | Log in to Reply

        Another thought.

        If a cache issue is oriented around cron, should it be assigned the ‘Cache’ component with no focus, or the ‘Cron’ component with ‘Performance’ focus.

        It seems that many caching issues could be considered performance issues, but not all of them. They are closely related almost always though.

    • Xavier Borderie 12:36 pm on January 25, 2014 Permalink | Log in to Reply

      Piggybacking on a Trac-related post (sorry, and couldn’t figure if it was better suited for make/core or make/meta — since it’s WP-related, I feel it’s best posted here)…

      While talking about background updates and 3.8/3.9 being the only versions to receive any further updates, I’ve been pointed to the Trac roadmap, which still features milestones for 3.5.3 (one open ticket, for backporting reasons), 3.6.2 (one closed ticket) and 3.7.2 (13 tickets total).

      So, what should it be? Would a cleanup be needed in those tickets, or are there really remaining plans for branches 3.5, 3.6 and 3.7?

    • Umesh Kumar 6:34 am on April 17, 2014 Permalink | Log in to Reply

      Is there anyway in Tickets section to show my previous contributions? I can see the current open tickets but not the closed one.

  • Andrew Nacin 5:31 pm on January 10, 2014 Permalink | Log in to leave a Comment
    Tags: reporting, 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?

     
    • Helen Hou-Sandi 5:35 pm on January 10, 2014 Permalink | Log in to Reply

      Candidates for closure. Not 100% sure what this would look like beyond the “close” keyword (perhaps semi-related to “dead” tickets?), but could be a good report, especially for those getting into Trac gardening. Dreaming big!

      • Andrew Nacin 5:39 pm on January 10, 2014 Permalink | Log in to Reply

        I’m not sure what this would look like either, hence this exercise. :-) Closing out tickets that shouldn’t be open any longer is always a fine idea! The keywords “close”, “2nd-opinion”, “reporter-feedback” are all good for this. Some kind of combination of Needs Reporter Feedback / Steps To Reproduce and Suggesting Close / Needs 2nd Opinion (that’s close to 200 tickets right there).

        Not sure what else — yeah, I’d say it’s related to “dead” tickets. Once “Awaiting Review” is under control again, it could be used to identify the oldest tickets still awaiting review.

    • Andrew Nacin 5:35 pm on January 10, 2014 Permalink | Log in to Reply

      An “intelligent” report on a component. For a particular component, group and order tickets in a way that helps keep the component well-maintained. The first group would be “slated for the next release,” for example. Other groups could include “Tickets awaiting review”, “Tickets more than X years old”, “Tickets needing feedback,” “Tickets with patches,” and (if they don’t fit into another group) “Major bugs,” “Minor bugs,” and “Enhancements.” The report should probably also try to render the component’s ticket graph at the top so we can see changes over time.

      A report like this could be a prime home base for a contributor wanting to clean up and be responsible for a component. What other groups would make sense?

      • Jeremy Felt 6:04 pm on January 10, 2014 Permalink | Log in to Reply

        Somewhat out of scope… is there a way to relate a ticket to other components. When a major effort is taken in Administration, then a report of ‘Multisite tickets that could be affected’ would be interesting.

    • Morgan Estes 5:56 pm on January 10, 2014 Permalink | Log in to Reply

      Not sure what to call it, but something for patches submitted for a release but not responded to by the time of the release freeze. I have a couple like this that I’m unsure of the status (realizing that just because it’s submitted doesn’t mean it’s used), and are in Awaiting Review.

    • Jeremy Felt 5:58 pm on January 10, 2014 Permalink | Log in to Reply

      Along the same lines of dead tickets, I wonder if there’s use in a view of all tickets reported against a version X releases old. These should be ripe for verification as they may have been resolved unknowingly along the way.

    • Andrew Nacin 6:00 pm on January 10, 2014 Permalink | Log in to Reply

      A report of tickets that have a patch uploaded to them no one has replied to yet. We’d do this by finding the most recent patch upload for a ticket, then seeing if there were any comments (by someone other than the uploader) that had been posted after.

    • Jeremy Felt 6:02 pm on January 10, 2014 Permalink | Log in to Reply

      Last modified might take care of this, but “Open tickets without a response in 30 days” or “Open tickets without a response in 2 releases”

      • Andrew Nacin 6:08 pm on January 10, 2014 Permalink | Log in to Reply

        The report of “dead” tickets mostly covers this, I think. But taking it further: perhaps “without a response” are the operative words here. Response from whom? How about open tickets where the last person to reply is the reporter? That tells me they are waiting for a reply from someone else.

        • Jeremy Felt 6:10 pm on January 10, 2014 Permalink | Log in to Reply

          Not sure if we can get fancy with roles, but “without response from a lead developer” or “…from active component person” or “…from bug gardener” or “…from committer” could all be interesting.

          • Andrew Nacin 6:15 pm on January 10, 2014 Permalink | Log in to Reply

            I was just thinking about that. Tickets without a response from any of X individuals is interesting. Of course, Sergey and I mostly cover the spread on that. :-) Maybe tickets where the last person to comment is not one of those people.

            We could probably come up with a way to do this on a per-component basis (so, all multisite tickets Jeremy has never looked at).

    • Andrew Nacin 6:05 pm on January 10, 2014 Permalink | Log in to Reply

      I think there are some good opportunities to highlight “extremes”. For example: Which open tickets have the most comments?

      The most votes isn’t that useful of a metric yet (and also, because it’s mostly just long-standing tickets like post relationships), but what about comparing/contrasting votes and comments? It’s really interesting to see a really long ticket that has almost no interest. #22692 has 67 comments yet just one vote, which tells me it’s a bit of an edge case and a time suck. Compare that with 68 comments but 31 votes on #19393.

      High number of attachments is interesting. So could a ratio of comments to attachments? Dunno. Lots of possibilities here.

    • Drew Jaynes 6:28 pm on January 10, 2014 Permalink | Log in to Reply

      From a docs perspective, it would be lovely to have a report that gathers needs-docs, needs-codex, and docs-feedback together. Right now we have:

      • Report 12 (needs-unit-tests/needs-docs)
      • Report 36 (needs-codex)
      • Report 37 (needs-unit-tests)

      Seems like that would also free up the needs-unit-tests duplication between reports 12 and 37.

      • Andrew Nacin 6:52 pm on January 10, 2014 Permalink | Log in to Reply

        Should needs-docs, needs-codex, and docs-feedback all be different groups on this report? What would they be called? “Needs Inline Documentation”, “Needs Codex Documentation”, “Needs Feedback on Documentation”?

        • Drew Jaynes 7:04 pm on January 10, 2014 Permalink | Log in to Reply

          I’d probably group them separately, yes. And ouch on the verbosity, but I guess that’s probably necessary — we can’t expect everyone to understand Docs == Documentation ;)

          It just occurred to me that there also might be room for including tickets on the Text Changes component. Though text changes kind of serve a different master, it’s all documentation in one form or another in the end.

    • Nick Halsey 6:42 pm on January 10, 2014 Permalink | Log in to Reply

      For Twenty Thirteen and Fourteen development we used a verbose custom query along the lines of https://core.trac.wordpress.org/query?status=accepted&status=assigned&status=new&status=reopened&status=reviewing&component=Bundled+Theme&summary=~Fourteen&group=milestone&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=milestone&order=priority (try searching the #wordpress-themes logs for it, it changed a few times too).

      It would be cool if we could create a report that achieves the same effect, allowing us to select a particular bundled theme’s open tickets.

      • Andrew Nacin 6:50 pm on January 10, 2014 Permalink | Log in to Reply

        I wish I had heard about this. We could have made it a saved report with just a few clicks. :-)

      • Robert Dall 6:53 pm on January 10, 2014 Permalink | Log in to Reply

        Nick beat me to the punch on this suggestion. But a total +1 on that.

        We could name it:

        “Current Default Theme Development”

        Or something like that…

    • Eric Andrew Lewis 6:49 pm on January 10, 2014 Permalink | Log in to Reply

      Some reports are also not 100% accurate, because tickets require a human-touch to change keywords. Sorry to go a bit tangential to this topic, but I’d like to suggest we improve report integrity by adding some automation here. There are a few ways we could approach this, I’ll just give one that’s been on my mind for a while, and I’m sure others’.

      Automated patch cleanliness testing, which could automatically toggle ‘has-patch’ // ‘needs-refresh’ keywords via a bot.

      • Andrew Nacin 6:51 pm on January 10, 2014 Permalink | Log in to Reply

        This is doable! We could have a bot go through and apply the latest patch on a ticket. If it doesn’t apply, we could add needs-refresh. Any other ideas along these lines?

        • Jeremy Felt 6:55 pm on January 10, 2014 Permalink | Log in to Reply

          We could have a bot go through and apply the latest patch on a ticket. If it doesn’t apply, we could add needs-refresh.

          +1withmany0s

        • Andrew Nacin 6:56 pm on January 10, 2014 Permalink | Log in to Reply

          If we did this, I feel we’d have this bot do a few other things too. So, apply the patch and run unit tests, for example. (This would need to be sandboxed. Even applying and reverting patches would need to be done carefully.)

          • Helen Hou-Sandi 6:59 pm on January 10, 2014 Permalink | Log in to Reply

            Was going to suggest running unit tests post-patch. +1 to that.

            • Andrew Nacin 7:02 pm on January 10, 2014 Permalink

              I imagine it would not be too difficult to integrate Travis CI into all of this. @bpetty?

            • Bryan Petty 7:15 pm on January 10, 2014 Permalink

              We could potentially trigger patch builds by scripting up automated pull requests. It’d be a bit of work, but I’m pretty sure this would be easier to do from Jenkins CI. @kurtpayne still has a Jenkins CI setup running, it’s a little out of date (I don’t think he’s actually updated it to use the develop repo still), but he probably has a better idea of how we could automate it.

              http://jenkins.kpayne.co:8080/

            • Bryan Petty 7:18 pm on January 10, 2014 Permalink

              Another option might be to setup a copy of Gerrit working off a git mirror.

            • Bryan Petty 7:29 pm on January 10, 2014 Permalink

              For what it’s worth, MediaWiki uses a combination of both Jenkins and Gerrit, and uses Jenkins bot to make several different checks to automatically sign-off patches in Gerrit. Maybe in our case, just Jenkins + Trac is good.

              Good checks to make can include:

              • PHP lint check
              • CodeSniffer with WP rules (this can be iffy though where existing code base isn’t already entirely compliant).
              • Unit tests
        • Morgan Estes 6:57 pm on January 10, 2014 Permalink | Log in to Reply

          That’s excellent! I’ve wondered how needs-refresh gets applied, and this would be a good addition to the “has anyone seen this yet?” status.

          How would it handle multiple patches in a ticket that deals with multiple fixes for a solution?

          • Andrew Nacin 7:02 pm on January 10, 2014 Permalink | Log in to Reply

            It wouldn’t be able to handle multiple patches, because it wouldn’t know the difference between an old patch (that is stale and has been updated) versus an alternate patch. I think that’s OK, this is definitely better than not having it at all.

        • Helen Hou-Sandi 6:57 pm on January 10, 2014 Permalink | Log in to Reply

          Automatically adding has-patch and triggering the notification for that would be good, since uploading attachments doesn’t. Would probably have to be a little smart about what’s a patch vs. not, but could be cool. False positives would be better than missed patches, in any case.

          • Andrew Nacin 7:22 pm on January 10, 2014 Permalink | Log in to Reply

            It could look around for *.patch or *.diff uploaded and have been there for at least an hour. (If the person is going to comment, we can assume it’d be within an hour.) Then we can check if the report has has-patch. If it doesn’t, we can have a bot post a comment and add has-patch.

            Even if the person has commented, it’s possible they didn’t add has-patch. We could still add the comment in that case. That said, it’s possible their comment is to say “Ignore my patch, that won’t work.” How do you differentiate between a user who didn’t add has-patch accidentally, and a user who didn’t add it on purpose?

            So, new approach. Two different angles. One, a bot that goes around and adds has-patch if the user hasn’t commented with an hour. Two, some JS that looks to see if a patch was recently uploaded by the current user. If it has, it Clippy-prompts the user, letting them know to post a comment and add has-patch.

            Or, we could provide feedback after uploading a patch that tells you to post a comment and add has-patch to the ticket.

            “Hey, you’ve uploaded a patch! Be sure to *add a comment to the ticket*.” And that link will not only take them to the new comment form, but it’ll automatically add the has-patch keyword for them.

        • Mike Schroder 12:52 am on January 11, 2014 Permalink | Log in to Reply

          I really like this idea.

    • Andrew Nacin 6:59 pm on January 10, 2014 Permalink | Log in to Reply

      Needs unit tests. Some contributors may just like writing unit tests. We used to say that a ticket would receive needs-unit-tests until they got committed. But now that tests and src are in the same repository, tests in most cases should be committed with the code they are testing. This is good, but means we need to tweak things a bit.

      So what we could do is this:

      • needs-unit-tests is added to an open ticket. This adds it to a report.
      • Someone writes unit tests. The keyword is removed, and it falls off the report. At some point, the tests are committed with the patch on the ticket, and things are good to go.

      And for closed tickets:

      • A ticket is closed, but it could still benefit from unit tests, so the needs-unit-tests keyword is added. This adds it to the same report, under a separate section probably.
      • Someone writes the unit tests. The keyword is replaced with “has-unit-tests”, and it is moved to another section on the same report saying “Tests Ready for Commit” (which would only list closed tickets with has-unit-tests).
      • Once committed, the has-unit-tests keyword is then removed.
    • John Blackbourn 7:44 pm on January 10, 2014 Permalink | Log in to Reply

      Plugin candidates. Open feature requests which have some comments or CCs but no patch or only stale patches. Candidates for someone to build the feature request as a plugin. Might also give us a chance to close the unwanted ones.

    • John Blackbourn 7:51 pm on January 10, 2014 Permalink | Log in to Reply

      Needs dealing with. Open tickets reported against versions more than two versions old that are marked as high or highest priority, or major/critical/blocker severity. Basically these need dealing with.

    • Aaron Jorbin 9:27 pm on January 10, 2014 Permalink | Log in to Reply

      Kind of off the wall, but I would love a report that scanned all patches to see if they add new JavaScript unit tests so that it was easy to review all potential JS Unit tests.

    • Kurt Payne 2:36 am on January 11, 2014 Permalink | Log in to Reply

      Responding to @Bryan Petty … I haven’t kept jenkins up to date. I do, however, have some scripts that may prove usefulf for this. The idea is this:

      • Create a clean development chroot
      • Check out wordpress, create a database, etc.
      • Apply the patch to the source
      • Run the unit tests
      • Display the output
      • Destroy the chroot

      It still takes a few mins to do, but it’s a very good way to get basic feedback on patches like “does it apply cleanly? does it break unit tests?” Let me know if you want to see. It has not been updated with the latest (3.7) svn layout.

      • Bryan Petty 6:25 am on January 11, 2014 Permalink | Log in to Reply

        As far as that goes, it’s way easier than it used to be with two checkouts, and I did get that all written for our Travis CI config. I just figured you’re much more familiar with Jenkins than I am, and might know how to best configure the build configs, and how to trigger Jenkins on Trac patch uploads. :)

        But I can certainly look into it myself too when I have the time.

    • Kurt Payne 7:16 pm on January 11, 2014 Permalink | Log in to Reply

      @bpetty I can help with Jenkins, sure.

      Travis is probably the best way to go for just unit tests.

      Jenkins is going to be more flexible for things like static analysis tools, customizing reports, integrating with other tools (e.g. Sonar is a popular dashboard), triggering downstream builds, potentially scaling by adding build slaves and potentially adding selenium tests (if wordpress ever has them).

      With regards to the “test the patches” script above … we can talk more offline about it … the important question is: Do we want something that automatically tests patches?

    • Sam Sidler 8:17 pm on January 14, 2014 Permalink | Log in to Reply

      A bit late to the party, but I’ve read through all the comments here and it seems like we have a bunch of good reports already that are hard to find. I think we should redo the Reports page to group together specific reports and make it easier to do specific component queries.

      The specific reports in each section might not be quite right in this mockup, but basically this is what I’m thinking: http://i.imgur.com/R7uNrJo.png

      (Even merged needs-docs, needs-codex, and docs-feedback together for a “Needs Docs Team” report.)

      For certain reports that are a combination of reports (like the Needs Docs Team report), we could easily list out what it includes underneath along with links to those specific reports.

      I’d also want to consider adding a “Open tickets by keyword” option on the right side, similar to the component one.

      All of this should be pretty easy to implement, it’s just a matter of deciding how much we want to round the corners of the boxes. ;)

  • Andrew Nacin 10:19 pm on January 9, 2014 Permalink | Log in to leave a Comment
    Tags: notifications, 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.

     
    • Janneke Van Dorpe 10:26 pm on January 9, 2014 Permalink | Log in to Reply

      Awesome! What about notifications that are set on profiles.wordpress.org? :D

      • Andrew Nacin 10:32 pm on January 9, 2014 Permalink | Log in to Reply

        For @-mentions and such? Yeah, I’m going to try to pipe mentions through that. That said, what should the emails look like? Should they be Trac content piped through the HTML emails, or should you receive a Trac email? I think it’ll end up being Trac-style emails for @-mentions but the HTML emails for other string matches… Still trying to figure out how I’m going to tackle it.

        • Janneke Van Dorpe 10:44 pm on January 9, 2014 Permalink | Log in to Reply

          I’d be really nice if they’re all HTML emails, converting Trac’s markdown. But some people probably prefer plain text.

          • Andrew Nacin 10:49 pm on January 9, 2014 Permalink | Log in to Reply

            I just meant they are two completely different templates – mentions emails and Trac emails. Which one to use?

            • Janneke Van Dorpe 9:34 am on January 10, 2014 Permalink

              I don’t know, but I’d use the same one for all kinds of notifications.

            • Mel Choyce 6:59 pm on January 15, 2014 Permalink

              My vote would be for using the current mentions emails for trac, if only because having an email that’s more designed makes it easier to scan and understand.

              (I’d also be game for redesigning the mention emails.)

    • Pippin Williamson 10:29 pm on January 9, 2014 Permalink | Log in to Reply

      Fantastic!

    • keoshi 10:35 pm on January 9, 2014 Permalink | Log in to Reply

      This is awesome! Great work.

    • Jose Castaneda 10:38 pm on January 9, 2014 Permalink | Log in to Reply

      Awesomesauce!!

    • Amy Hendrix (sabreuse) 10:41 pm on January 9, 2014 Permalink | Log in to Reply

      Yay! I’m really liking all of these improvements. Trac is feeling both friendlier and more usable already.

      I’ve pretty much stopped using ticket cc’s since I sacrificed my inbox to the firehose — what you say about using star counts as votes suggests that it might be worth starring to indicate interest even though I’m already notified?

    • Kim Parsell 11:14 pm on January 9, 2014 Permalink | Log in to Reply

      Thank you for all of the hard work – Trac is so much better to work with now. :)

      I’ve got several tickets from a few years ago with CCs for an old email address that will be going away soon. Do you want to remove those CCs so you don’t get the email bounces from them, if there would be any activity on them?

      • Andrew Nacin 11:28 pm on January 9, 2014 Permalink | Log in to Reply

        I managed to map every email address CC to the corresponding user account (took me about five hours to script it then manually go through about 200 unknowns). I then imported all of them into the new notifications system, which is based on usernames. Then I literally emptied every CC field across all tickets. So those old tickets are now linked to directly to your username and profile email. :-)

    • Brad Touesnard 12:33 am on January 10, 2014 Permalink | Log in to Reply

      Well done sir!

    • Lance Willett 3:16 am on January 10, 2014 Permalink | Log in to Reply

      This is really cool—makes Trac even more user friendly and useful for both newbies and veterans alike.

    • Rami Yushuvaev 9:29 am on January 10, 2014 Permalink | Log in to Reply

      Looks great!

    • Marcus 11:50 am on January 10, 2014 Permalink | Log in to Reply

      bravo, removing cc is a welcome feature :)

    • Lance Willett 6:42 pm on January 10, 2014 Permalink | Log in to Reply

      @nacin — Got my first email for Bundled Themes, nice! It was a notification for #26782.

      One question: I noticed the Reply-To is wp-hackers@lists.automattic.com — is that still correct?

      • Andrew Nacin 6:48 pm on January 10, 2014 Permalink | Log in to Reply

        Yeah, Trac emails have always been set up for that. Mostly to prevent replies from trying to go to the wp-trac list, which is announcement only.

        • Lance Willett 6:51 pm on January 10, 2014 Permalink | Log in to Reply

          Cool.

        • Lance Willett 6:51 pm on January 10, 2014 Permalink | Log in to Reply

          Crazy idea: what if an email reply made a new comment on the ticket?

          • Helen Hou-Sandi 6:56 pm on January 10, 2014 Permalink | Log in to Reply

            I thought about asking about that once, and then thought about how often using that feature on Basecamp leads to forgetting and/or ignoring context. It’s also good to actually visit tickets sometimes, as not everybody knows that uploading attachments doesn’t trigger any notifications.

            • Andrew Nacin 7:09 pm on January 10, 2014 Permalink

              GitHub supports this and every once in a while you can tell someone used it because some quoted text sneaks in. I think that ultimately, it’s a pretty edge feature. The cost of implementing this far outweighs the limited benefit.

              It doesn’t look like there are any decent Trac plugins that implement this. Even if they did, it sounds like it’d be a nightmare even just to configure and get working. It’s still a cool idea, of course, just not worth the energy.

    • Robert Dall 6:59 pm on January 10, 2014 Permalink | Log in to Reply

      @nacin When you click on next ticket… It stays in the same report now! Cool!!!

  • Andrew Nacin 7:47 pm on January 6, 2014 Permalink | Log in to leave a Comment
    Tags: 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.
    (More …)

     
  • Andrew Nacin 7:51 pm on January 3, 2014 Permalink | Log in to leave a Comment
    Tags: , trac   

    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.

     
    • Ionel Roiban 7:55 pm on January 3, 2014 Permalink | Log in to Reply

      Sounds good.

    • Ryan Duff 7:57 pm on January 3, 2014 Permalink | Log in to Reply

      Is there an ETA on the time this will be changed?

      I’ll have to update my email filters on my .org acct and would like to have it ready to test so my phone doesn’t blow up some night when I’m sleeping.

      That’s why I used a specific “list” acct ;)

      • Ryan Duff 7:59 pm on January 3, 2014 Permalink | Log in to Reply

        Err wait, this is the notification email, not the list email. I may be fine as I think that goes to the same email on my .org profile already.

        Heads up may still be nice for the handful that will have to adjust though.

      • Andrew Nacin 8:00 pm on January 3, 2014 Permalink | Log in to Reply

        Sometime in the next 1-72 hours.

        Note — you have the same email address in both Trac references and your WordPress.org profile. If you were referring to the firehose mailing list, that’s not affected. I’ve added a note to the bottom of the post.

        • Ryan Duff 8:13 pm on January 3, 2014 Permalink | Log in to Reply

          Yup. I’m using a separate address for the svn/trac mailing lists. When I went to verify email filters I realized that the ones that come through as trac notification went to the email on file for .org.

          This week has been a bumble from the start. At least it’s Friday. Thanks for following up!

    • Andrew Nacin 8:08 pm on January 3, 2014 Permalink | Log in to Reply

      Here is a short list of names I recognize who this will affect: @westi @dd32 @viper007bond @sterlo @coffee2code @chmac @eddiemoya @kawauso @lloydde @mrmist @ptahdunbar.

      In most cases, though, the user updated their WordPress profile but never bothered to update Trac. That’s why we’re doing this!

    • Eddie Moya 7:38 am on January 4, 2014 Permalink | Log in to Reply

      I did use “+trac” in my email address to filter for it, so I really appreciate that you went through the effort of figuring out who might specifically affected by it. Otherwise I would have been confused about why my filters stopped working, since this is something I haven’t touched in a very long time.

      Idk if the list is just really that short of people affected – but maybe it would make sense to send out a blast email on trac to let everyone know that way in case they aren’t lucky enough to be the 11 names you listed. Just a thought.

      Thanks again for the heads up.

  • Andrew Nacin 6:51 am on October 17, 2012 Permalink
    Tags: 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.

     
  • Andrew Nacin 5:31 pm on September 11, 2012 Permalink
    Tags: trac   

    Marking duplicate tickets on Trac just got a bit smarter and easier. Now, when you mark a ticket a duplicate, you specify the other ticket. A comment will be cross-posted there that references the duplicate, so you don’t have to.

    You can optionally include a comment and any other ticket property changes, as before. If your comment doesn’t include a reference to the ticket, it’ll automatically add it.

    A side effect of how the plugin is written (it’s a modified version of this one) is that no email notification is sent for the “#___ was marked as a duplicate.” This is great because it avoids a double-email (that until now would happen manually). On the other hand, if you consume Trac via your inbox like me, you might expect that the next email is the other ticket, floated to the surface again. I’ll leave it as is for now.

     
  • Andrew Nacin 6:58 pm on September 10, 2012 Permalink
    Tags: trac   

    Trac updates and a design refresh 

    Every few months we make a few improvements to Trac. Given how many hours so many of us spend on there, even the smallest changes can make a big difference. Today, a few new changes were deployed.

    The first thing you’ll notice is a design refresh, from @helenyhou and @ocean90. It cools down the colors a bit and places more of our own mark on it (more WP-like, less Trac-y). They also added responsiveness for mobile devices, and made some adjustments to improve readability. See #18211. If you notice any bugs or quirks, please leave a comment there.

    From @iammattthomas, the WordPress logo is now HiDPI.

    If you’re a bug gardener (i.e. you can change milestones, etc.), you can now change the resolution of a closed ticket. This should make @sergeybiryukov happy — no more re-open to re-close.

    Over the last few weeks I’ve given more than a dozen people bug gardener status. We’d like to empower the people we know and trust to make decisions, while making Trac simpler for others.

    For those who aren’t bug gardeners, we’re trying to make it as easy and streamlined as possible for you to create and contribute to tickets. @bpetty has been studying our workflow and recommending changes. One of those is we’ve hidden the ability to change ownership of a ticket (accept/assign/reviewing). A big issue with ownership is it sometimes discourages others from contributing. I hope this change can free us up to using that field for tracking responsibility and accountability.

    Non-gardeners can also no longer label tickets a “task”. Also, once the Version field is set, a user can’t update the field to a newer version, only an older one. (As @sergeybiryukov says, “version number indicates when the bug was initially introduced/reported.” It’s the earliest known affected version for a bug, or the earliest applicable version for an enhancement.)

    And finally, if you add the “has-patch” keyword to a ticket, “needs-patch” will automatically be removed, and vice versa. (It’s the little things.)

    I hope you enjoy this round of changes. If you have any further suggestions, please share in the comments.

    Bonus. A few weeks ago, we added a ticket graph, inspired by jQuery and using their plugin as a base. I hope to add some more functionality to this in the future. For now, a few of us are using it to study trends and come up with some new ideas for how we can best maintain the ticket queues.

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel