This post summarizes the dev chat meeting from December 21st (Slack archive).

4.7 Retrospective

• Reviewing comments on 4.7 Retrospective post on Make/Core
• We will go through comments and discuss if there are changes to our process that we should recommend
• Goal is not to second-guess decisions that were made, the goal is to figure out if the process can be improved in future releases
• Things to start doing:
  • “We failed at getting the field guideField guide The field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page. and email to 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 dev out early enough. We have aimed to have that out around 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. 2 and usually end up getting it out around RCrelease 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). the last few releases. This time it came out the day before (field guide) and day after the release (email).”
    • Coming up with some documentation and ensuring that it’s not just owned by one person is a good way to improve it
    • We should also ensure it is included in the release checklist
  • “The posts explaining new features and changes are helpful, but I think that we need more of them. I follow the tracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. feed, and sometimes I know that as a plugin developer a particular ticketticket Created for both bug reports and feature development on the bug tracker. is important for me to take note of, but it can be difficult to unravel exactly what the final decision was just based on the changesets. An example of something that is going on right now is the a11yAccessibility 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) team’s work on removing excessive content from headings on adminadmin (and super admin) screens. Often 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. changes get documented and UIUI User interface changes don’t, but I’m a perfectionist and I like to stay up to date on the latest design/a11y evolutions as well. I can usually figure out what changes I might want to make in my plugins based on the changes in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., but I’m sure that often most plugin developers don’t even know that there was a change, if they don’t read every ticket.”
    • Request here is to have more Dev Notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. and explanations about what is changing
    • It would help to spread the load of writing Dev Notes a bit, sometimes they are time consuming, especially if you’re not much for writing this sort of contextual summary
    • Some components generate a component summary dev notedev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. which is a good practice
    • Should we also maybe reach out to the docs team to see if they want/can help?
    • Anyone have ideas for how we get people involved with drafting the note even if they aren’t leading developers on a feature/component?
    • We do list out every change in the “this week in core posts” (shout out to the team that works on those!) already, so there isn’t anything that goes unannounced
    • The solution suggested is more posts, but the problem appears to be that people aren’t seeing changes that they think might affect them
    • Getting to Trac and subscribing to whatever feed is a little hidden. Even 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/. notifications is hidden. A more public place would be good.
    • The solution could be to push people to the Week in Core posts, they already list every change categorized by components
    • Someone willing to lead a discussion (likely on make/core) on how to improve this?
    • Action Item: wait and see how lack of timed release cycles plays out
  • “We need to collectively review the “feature pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. merge guidelines” listed here. While development in plugins has become less prominent, most of the bigger projects merging into core in 4.7 (I would exclude the 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/. since that’s less user-facing) skipped many of the steps here. A lot of the points don’t apply to most projects – to the point that the checklist is often forgotten entirely. But there remains a need for better quality control and an updated checklist or recommended merge considerations for larger projects should be created accordingly. These written guidelines can better inform merge decisions and assess readiness.”
    • Can we reasonably make full test coverage (covering basic use cases at least) a requirement there?
    • This may be null as feature plugins may not play a significant, or any, role in the future
    • More “wait and see how new process/focus shakes out”
    • Action Item: No more feature plugins
  • “On a related note, clearer procedures about backing out merged features are needed. Particularly if a feature goes through an extensive process to demonstrate readiness and is approved for merge, input on removing the feature during beta/RC should be solicited publicly via make/core posts and scheduled meetings, similarly to the initial merge decision. Otherwise, the decision to remove a feature can seem to ignore the value of the opinions that went into making the decision initially and may not be fully informed about the broader implications with respect to related aspects of a component. If work on a feature seems to stagnate as bugs accumulate during beta and a lead is considering pulling it due to lack of attention, contributors working on the feature should be notified so that they can address the issues or recommend removing the feature based on availability. Perhaps putting more trust in the feature teams and component maintainers that are most intimately familiar with a given project could help ensure that decisions are more broadly considered.”
    • Still a question of who really owns final decision/veto power; @matt as product owner likely
    • Whomever is leading the release has final decision. That’s why they’re a lead. That much should be clear.
    • Action Item: continue to communicate changes clearly and early
    • Release leads and core leads need to be trusted to prioritize based on goals for the release
    • When somebody is unable to solicit feedback, we need to have honest conversations about why this is happening
  • “Add automated acceptance testing for the user flows. If we add these for new features added, we can ensure they work across browsers. And in future releases, these tests can ensure that we don’t break existing flows. Run tests on BrowserStack. See #34693.”
    • Any volunteers to help work on this?
    • Anyone think automated acceptance testing for user flows is a bad idea?
    • It could be difficult to maintain
    • This is done at Automattic: https://github.com/Automattic/wp-e2e-tests
    • Action Item: keep exploring in the ticket
  • “more focus on Trac and tickets, every committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component. should try to follow Trac on a daily basis. Not to know 100% of the details of each ticket but at least to get a sense of what’s going on. Also, the number of tickets on Trac is increasing more and more, there’s the need of some serious ‘Trac Gardening'”
    • A big ask for every committer following Trac on a daily basis
    • Especially since the vast majority of committers aren’t being donated anywhere near full time (and a large number are 100% volunteer)
    • This is why there’s component maintainers, so that we don’t overburden each person
    • Trac Gardening is something anyone is welcome to do, you don’t need to be a committer
    • Trac Gardening would benefit from some mentorship to be more effective
    • If there could be some mentoring for this – an initial joint meeting to get people started might we get some more interest?
    • We could benefit from improved workflows for managing the resources we do have and to reduce the uncertainty in gardening/contributing in non-code ways
    • Trac Gardening can be a thankless task to a novice who comments on tickets, asks for dev-feedback and then nothing further happens for months. Perhaps the dev-feedback tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) needs watching more rather than all tickets.
    • Action Item: generalize 4.7 Bug Scrubs page “to run 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. scrub, announce it here, talk to these people, look at this report in Trac, then pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” people on the tickets listed”
• Things to continue doing:
  • “The combination of a 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/. startup phase and Slack is excellent. At least for the Twenty Seventeen theme.”
    • GitHubGitHub GitHub is a website that offers online implementation of git repositories that 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/ likely helps get new contributors involved, but not sure they stick around
    • GitHub is easier to follow along, post mockups, get feedback, review code
    • GitHub better with searching, labelling, organizing, looking at PRs, realtime updates, making branches and then submitting PRs from branches, plus its app
    • Our current code review process is sub-optimal because there are no workflows to support it (e.g., line-by-line comments on changes)
    • It would be good to separate what is the project management tool vs. 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. method
    • GitHub is sub-optimal when iterating on PRs. In Trac, you can make minor changes to 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. and upload it to a ticket. In Github, depending on permissions patch iteration is not straightforward.
  • “Weekly design meetings.”
  • “On the upside, having clear deadlines for when enhancements need to be merged into core is very helpful for prioritizing time and focussing resources. I hope we will continue some form product calendar in the spirit of “deadlines aren’t arbitrary,” even if they take a different rhythm.”
  • “increase the effort to involve different teams in collaborating on features development, where different skills and knowledge are needed, of course.”
• @jorbin to work on a summary of what was discussed here and post it on Make/Core

General Announcements

• Uncertain if anyone is planning on running a core dev chat next week (or any weeks going forward), so watch for agendas on Make/Core or other notifications in #core

#4-7-1, #dev-chat, #summary