Proposal: Rename “invalid”, “worksforme”, and “wontfix” ticket resolutions

Last year, during the core dev chat of May 29th, 2019, I proposed renaming the 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. and worksformeworksforme A resolution on the bug tracker (and generally common in software development) that indicates the bug reported cannot be reproduced. Trac ticket resolutions to something more friendly and less confusing. The reaction in the chat was unanimously positive, so this is now an official proposal for discussion.

The current interpretation of ticketticket Created for both bug reports and feature development on the bug tracker. resolutions, as per the Core Contributor Handbook:

Resolution: Upon one or more commits to the codebase, a ticket may be closed as fixed. Not all tickets result in a commit, however, and may be closed for other reasons:

  • duplicate: The ticket is a duplicate of an existing ticket, which will be referenced by the contributor closing the ticket.
  • invalid: The ticket is not 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 is a support request.
  • worksforme: The bug reported in the ticket cannot be reproduced. Sometimes, an existing pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party, hook, or feature may render the ticket moot, so the ticket can be closed without further action.
  • 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.: The ticket will not be addressed. Occasionally, bugs are considered to be acceptable edge cases, and will not be addressed further. This is sometimes used when a request for an enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. or feature has been rejected for coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. inclusion.
  • maybelater: Similar to wontfixmaybelater is used for a ticket that, while perhaps not outright rejected, has no current traction.
  • reported-upstream: The ticket is for an external library or component, has been reported in an upstream repository (e.g. GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/), and will be addressed there.

More than a few times I’ve seen someone closing a ticket as worksforme after testing a patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. because, well, it works for them. When that happens, the ticket has to be reopened with a comment that the patch still needs to be reviewed and committed.

Based on the above, I’d like to propose the following updates:

  • invalidnot-applicable
  • worksformenot-reproducible or cannot-reproduce
  • wontfixnot-implemented

On the technical side, any tickets that are currently closed should keep their existing resolutions, while tickets closed after the change is implemented should get the new resolutions. Some links and TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. reports might need an update to account for the changes.

Even if we move away from Trac at some point in the future, we’re not there yet, and I think clarifying these resolutions would be helpful for the time being. Any feedback appeciated!

Props @desrosj and @jeffpaul for pre-publication review.

#meta-tracdev, #trac, #triage, #triage-team

Introducing the WordPress Triage Team

In Matt Mullenweg’s 2018 State of the Word, he detailed 9 projects that he envisioned being tackled by individual teams in 2019. These projects were then posted to this blog for further discussion.

The last item on the list (which was in no particular order) was: “Forming a Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. team to tackle our 6,500+ open issues on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress..”

“We need to do a lot of triaging work. There are over 6,500 open issues in our CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Trac right now. There have been some requests about moving to a different 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. tracker and things like that. I would feel bad about doing that without cleaning up our home first.”

Matt Mullenweg – 2018 State of the WordState of the Word This is the annual report given by Matt Mullenweg, founder of WordPress at WordCamp US. It looks at what we’ve done, what we’re doing, and the future of WordPress. https://wordpress.tv/tag/state-of-the-word/..

As WordPress has grown, the volume of tickets in Trac has naturally increased. While the number of open tickets on its own should never be the sole metric of software health, a large number of open tickets can have many undesirable and frustrating consequences, such as tickets being lost or accidentally glossed over, and contributors not knowing where to focus their (often very limited) time and effort to have the largest impact.

This team will coordinate with component maintainers, releaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software. leads, project leadership, contributors, and other WordPress related projects with issue trackers outside of Trac (such as GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/, new default themes, etc.) to ensure that everyone is empowered to focus on what they are best at: contributing!

With that in mind, let’s meet the new Triage Team!

Initial Team Structure

The following initial team structure was self-organized and was formed based on nominations and interest expressed in the comments of Makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). WordPress Core posts related to this topic. The following people have a strong track record of contributing to WordPress, exhibiting good triaging practices, and being overall good community members. They also represent a range of disciplines to ensure every type of contribution is considered by the team when making recommendations for process changes.

This team structure can be altered at any time as needed and was created with the goal of getting the team to a point where it can be functioning and effective starting today. In addition, more team members are needed in order to accomplish these goals.


Jonathan Desrosiers (@desrosj) – Team Lead

Jonathan has been a consistent contributor to the WordPress project since 2013, lending his time to various components and initiatives (such as Media, 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/., and Privacy), and has been a significant contributor to organizational tasks. He also helps run new contributor meetings where all questions about contributing are welcome. Having worked in such various capacities, he’s thrilled to be able to focus on the organization of the issue tracking tools and processes.

Chris Christoff (@chriscct7) – Process Advocate

Chris has a long history of contributing to WordPress Core, particularly as part of ticketticket Created for both bug reports and feature development on the bug tracker. triage (including over 1,000 tickets triaged in the WordPress 4.4 and 4.5 release cycles). As a part of the team, Chris will be working to ensure that the triage team is meeting its milestone goals, performing ticket triages in an effective way, and working to improve and optimize processes.

Tammie Lister (@karmatosed) – Design Advocate

Tammie has a background in ticket triage, especially as it pertains to designers and design UXUX User experience/UIUI User interface concerns. As Design Advocate, Tammie will be working to ensure the workflow needs and requirements of designers receive proper consideration and are represented in all decisions made by the team.

Sergey Biryukov (@sergey) – Developer Advocate

Sergey is a prolific WordPress contributor with a deep-rooted knowledge of Trac and the needs of developers contributing to the project. As Developer Advocate, Sergey will be working to ensure the workflow needs and requirements of developers receive proper consideration and are represented in all decisions made by the team.

Sheri Bigelow (@designsimply) – Triage Advocate

Sheri has over 12 years experience supporting WordPress developers and users with an extensive background in triage and testing, most recently assisting with Gutenberg triage prior to its release in WordPress 5.0. She has a strong track record as a user and developer advocate and will ensure the team is communicating clearly (without jargon) to everyone to help build a strong, sustainable community of contributors.

Recent Challenges

Here is a list of some recent challenges that the team would like to explore solutions for:

  • Large time burdens on release leads to triage tickets in their release milestone.
  • Punting many issues each release, leading to frustration over poorly-set expectations.
  • Contributors don’t know where to spend time effectively especially when not contributing on a daily basis.
  • Tickets get buried, lost or glossed over.

Here are some metrics related to those problems:

  • The number of issues punted each release.
  • The number of interactions per contributor over time.
  • The number of stale and unactionable tickets left open.

Short Term Goals (First Half of 2019)

After reviewing current day to day Trac practices and considering both public and private feedback about the team, the immediate short-term goal of the team is to start a regular triage process to help maintain properly categorized and actionable tickets. Here are some of the ways that this can be done:

  • Create and execute a plan to work together with component maintainers and other contributors to triage open tickets with an emphasis on the Awaiting Review milestone and tickets that have become “stale”.
  • Provide any needed support to component maintainers in the form of (but not limited to): ticket scrubs, testing, ticket triaging.
  • Help release leads and deputies manage the flow of tickets into and out of release milestones.
  • Define and document WordPress ticket triage processes and best practices, including when to close an issue, requirements for moving an issue into a release milestone, etc.
  • Research and make some small process change recommendations (examples: new ticket resolutions, keywords, or workflows).
  • Sketch ticket flows for visual representations of processes.
  • What are the correct processes for supporting codebases in multiple locations (ie, Trac/SVNSVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase., GitHubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/, etc.).
  • Changes to Trac reports:
    • Which ones are no longer useful or manageable?
    • How do we better direct contributors to reports that require focus?
    • Where are there needs for new reports?

These are areas that require the focus and immediate attention of the team to ensure contributors are not overloaded and fully enabled to do their best work.

It’s important to note that none of the items above will replace the current responsibilities of component maintainers or ticket gardeners. Component maintainers and contributors are still encouraged to scrub tickets for their components in Trac. The Triage Team is not replacing that responsibility, but instead, are here to assist with that responsibility.

Component maintainers have a deep-rooted understanding of the component’s history, past decisions, and feature progression. They are the ones best suited to make decisions that will point the component in the direction they feel best aligns with the overall project goals and priorities. The Triage Team will work closely with component maintainers to expand the efforts around triage, help to improve those processes and ensure that tickets are actionable.

Long Term Goals (2019 and Beyond)

The ultimate goal of the team will be to make triage a scaleable, sustainable part of the WordPress project. Longer term, a roadmap will be established to detail the team’s vision. Here are a few potential long-term goals that have come up in discussions so far.

  • Automated workflow keywords. such as stale  or needs-verification (to make sure the reported bug is still reproducible) for older tickets.
  • Documentation for onboarding new team members.
  • Creating a rotation where interested contributors can donate time to the team as part of fulfilling the 5 for the Future challenge.
  • Ensuring that triage practices and ticket lifespans are agnostic to the ticket tracking software used (keeping in mind the ongoing WordPress + Git conversation).
  • Ensuring new tools and technologies in processes are properly supported (for example, NPM or Composer packages).
  • Creating a deprecation handbook with recommendations for how deprecated or removed parts of WordPress should be supported through tickets (What types of tickets are accepted or considered for how long under what circumstances?).
  • Global ticket triage days.

Staying Updated

Moving forward, the team will post an update every other week to the WordPress Contributor Team Updates blog with a summary of the following:

  • Summaries of the ticket scrubs held the previous week.
  • Priorities and ticket scrubs for the following week.
  • The ticket scrub schedule for the following week.
  • An overall summary of Trac ticket activity.

As changes to workflows are researched and evaluated, change recommendations will be published to the Make WordPress Core blog (and cross-posted where appropriate) for feedback.

Getting Involved

If you have an interest in being a part of this team and helping with its initiatives, please express your interest by commenting below. Feel free to be as specific as you’d like about how you would like to contribute to the team.

You can also attend the first team meeting! The first meeting will be held on Monday March 11, 2019 at 19:00 UTC in the #core room in the Making WordPress Slack.

In the interest of full transparency, the following additional people have also reviewed this post and provided feedback about the structure and priorities detailed in this post: @chanthaboune, @helen, @joemcgill.

#trac, #triage-team

Reverting the Bulk Ticket Closing

Recently, a bulk modification was performed on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. affecting 2,300+ tickets that had not seen any activity in 2 years or more. These tickets were closed and marked as wontfix. To read a more detailed breakdown, check out the previous post on the subject.

After discussing, it has been determined that the bulk action should be reverted, but only for tickets that have not had their status changed or otherwise confirmed via comments that closing is acceptable since the bulk closure. It can be safely assumed that closed tickets updated after the bulk edit have been appropriately groomed and should remain in their current state. A full list of tickets slated to be reopened can be found using this Trac query.

Tickets should only be closed if they have been individually evaluated and it is determined that they are either no longer relevant, have been fully and properly addressed, and any changes have been adequately communicated to the community.

These tickets will be reopened during the week following the 5.1 releaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software. (February 24-March 2) by @jeffpaul and myself (@desrosj). All reopened tickets will be placed in the Awaiting Review milestone so that they can be properly triaged by component maintainers and the Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. Team in the coming months.

#trac, #triage

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:

  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 makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). 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

On WordPress + Git

Can you believe it – we’ve made it through a State of the WordState of the Word This is the annual report given by Matt Mullenweg, founder of WordPress at WordCamp US. It looks at what we’ve done, what we’re doing, and the future of WordPress. https://wordpress.tv/tag/state-of-the-word/. without anybody asking “when is WordPress moving to GitGit Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. Most modern plugin and theme development is being done with this version control system. https://git-scm.com/./GitHubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/?” You may, however, have caught a brief mention of issue trackers in relation to the Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. Team focus for 2019. While it’s very important to makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). the distinction between Git the version controlversion control A version control system keeps track of the source code and revisions to the source code. WordPress uses Subversion (SVN) for version control, with Git mirrors for most repositories. system (VCS) and GitHub the service, as the answer usually goes, it’s understandably a continued area of interest. Many parts of WordPress have been developed using GitHub as the central tool, along with countless plugins and themes and even the WordPress book.

Here’s the tl;dr (but you should definitely keep reading after this): Changing things up doesn’t just mean “let’s make the GitHub mirror at WordPress/wordpress-develop the canonical and migrate TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets over” – it means imagining what kind of change would be a net benefit to the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. development process and eventually the entire .org ecosystem, and then finding the right tools to do it.

To that end, there is a group of people including myself (@helen), @desrosj, and @omarreiss who have been and will continue to be doing more coordinated research and planning around tooling. There is no current planned timeline nor is this a priority on top of the projects already enumerated for 2019, but any potential tooling change is being evaluated as it potentially relates to those projects, especially if it can better support phase 2 of GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ development and the Triage Team.

This is not about chasing the latest and greatest or evangelizing a preference – it’s important to identify the goals we have for the project and what pain points we are experiencing. More specifically than “democratizing publishing”, in the core development process we should be aiming for diverse participation, a faster-but-steady pace of development, predictable and timely feedback cycles, and continuing to build user trust among users of all types. Recent pain points have been merges between branches (especially 5.0 back to trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision.), JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. package updating, and continued participation when projects move from plugins and GitHub into core and Trac.

Roughly, here are some early thoughts on various moving pieces and potential future improvements.

Repositories and Workflows

  • SVNSVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase. repositories would need to remain, essentially flipping the mirroring process to go from Git -> SVN, making SVN (and Git) repos on .org read-only
  • Should the core build process continue to be handled as-is or should we move to something like Travis?
  • Integration of more automated testing – visual regressionregression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5., end-to-end, accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility), performance
  • Identification of the ideal lifecycle of an issue and process for a pull/merge request – design, docs, review, testing, etc.
  • Identification of contribution workflows (contributor documentation, Git branching methodology, etc.)
  • Security tracking and releasing

Issue Tracker

  • Critical for a Triage Team to review existing issues and to remain active going forward
  • Potential for the bulk triage process to include migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. from Trac to another tracker
  • Any issue migration should be determine on a case by case basis by the Triage Team in collaboration with component maintainers; the most automation that should happen is a tool that takes a list of Trac tickets and imports them elsewhere
  • Issue import process needs to take commenter attribution into account
  • Trac would remain in a read-only state
  • How are reports generated and used (i.e. is the built-in filtering capability enough in a given tool or will we need something more robust to support workflows)
  • Is the issue tracker still the best place for feature requests?
  • Implementation of issue templates
  • Identifying existing custom integrations and whether those problems still exist and still need to be solved after a move

Broader Ecosystem (later / bigger question mark)

  • Connectors from GitHub to .org pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and theme repos (GitHub Actions-powered build+deployDeploy Launching code from a local development environment to the production web server, so that it's available to visitors.)
  • Automated testing – sniffers, Tide, unit tests, WP and PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 compat testing, Theme Check
  • Aligning plugin and theme review teams

#git, #trac, #triage

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

Per the schedule, WordPress 4.5 BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 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 releaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software. of Beta 3, I’d like to see this down to 50.

To support this, we’ll run a triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors., 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 Candidaterelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). 1 (two weeks from now).

If you own ticketticket Created for both bug reports and feature development on the bug tracker.(s) on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. in the 4.5 milestone:

  • If your ticket will not be finished in the very near future, please puntpunt Contributors sometimes use the verb "punt" when talking about a ticket. This means it is being pushed out to a future release. This typically occurs for lower priority tickets near the end of the release cycle that don't "make the cut." In this is colloquial usage of the word, it means to delay or equivocate. (It also describes a play in American football where a team essentially passes up on an opportunity, hoping to put themselves in a better position later to try again.) 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 SVNSVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase. and TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. firehose mailing lists to lists.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/, 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 SSLSSL Secure Sockets Layer. Provides a secure means of sending data over the internet. Used for authenticated and private actions.. 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 makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility)./coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. 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 blogblog (versus network, site) is, where to file 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., how to start contributing; and provides some info about IRCIRC Internet Relay Chat, a network where users can have conversations online. IRC channels are used widely by open source projects, and by WordPress. The primary WordPress channels are #wordpress and #wordpress-dev, on irc.freenode.net. and our meetings.

New, simpler new ticketticket Created for both bug reports and feature development on the bug tracker. 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 TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.. 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 TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. 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 Multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site 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 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. — 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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. “Validation” ranged from from validation tickets to XHTML issues. HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. validation issues now belong in the affected component, like “Template” or “Administration.” “Warnings/Notices” contained tickets ranging from PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 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, accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility), javascriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/., 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 ticketticket Created for both bug reports and feature development on the bug tracker. 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 TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.. 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 makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). 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 “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.” 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 Docsinline docs (phpdoc, docblock, xref) 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 Networknetwork (versus site, blog) Adminadmin (and super 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 UIUI User interface 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