Title: process – Make WordPress Core --- # Tag Archives: process [ ](https://profiles.wordpress.org/ryan/) [Ryan Boren](https://profiles.wordpress.org/ryan/) 5:22 pm _on_ March 4, 2016 Tags: checklists, pitch, process, [release-process ( 27 )](https://make.wordpress.org/core/tag/release-process/) # 󠀁[Release Process Checklists](https://make.wordpress.org/core/2016/03/04/release-process-checklists/)󠁿 The release process is complex and beyond one person. Releasing is an intricate dance that we haven’t been sufficiently capturing. Knowledge siloed in heads needs to be committed to public, institutional memory. The upcoming 4.5 release is an opportunity to capture every step of the dance so that we can iterate process, automate away lingering drudgery, and improve our cognitive net for the stressful task of releasing to 25%. I like using checklists in this cognitive net. They relieve anxiety, make process transparent, and help teams flow during stress. We already have a couple release checklists. We can build on those while adopting a little checklist culture in a manner empathetic to developers and flow. Pitch: ### Checklist cool tricks Checklists… * distribute power. * push power of decision making to the periphery. * provide a cognitive net. * make the minimum necessary steps explicit. * make sure simple steps are not missed. * make sure people talk. * capture and shape real flow. * inspire flow in emergencies and sustain it through the quotidian. * capture flow between teams. * encourage a shared culture around flow. * accessibly capture institutional memory in the context of flow. ### Attributes of a good checklist What makes a good checklist? Checklist shouldn’t be about just checking boxes. Instead of being a chore and an admonishing finger, checklists should fit and assist real flow. [The Checklist Manifesto](http://atulgawande.com/book/the-checklist-manifesto/) offers these suggestions. Ideally, checklists… * are not lengthy. * have clear, concise objectives. * define a clear pause point at which the checklist is supposed to be used. * have fewer than ten items per pause point. * fit the flow of the work. * continually update as living documents. See [this checklist for checklists](http://www.projectcheck.org/checklist-for-checklists.html)) and [this example checklist](http://www.who.int/patientsafety/safesurgery/ss_checklist/en/) for more. ### Stuff to checklist The [major release checklist](https://make.wordpress.org/core/handbook/about/release-cycle/releasing-major-versions/) attempts to use pause points and follow the suggestions above. The major and [minor release](https://make.wordpress.org/core/handbook/about/release-cycle/releasing-minor-versions/) checklists are pretty rough and incomplete and overlap with each other. These and the [things to keep in mind list](https://hackpad.com/Things-to-keep-in-mind-during-various-stages-of-a-WordPress-Release-UBcvCVqeXGP) need love and unification with help from developers who are in the release flow and handling controls on the release train. about.php is…quite the process. It needs the oxygenating powers of a checklist. Checklist [Feature plugin merges](https://make.wordpress.org/core/handbook/about/release-cycle/features-as-plugins/#feature-plugin-merge-checklist). Checklist bundled theme releases so [stuff like this](https://core.trac.wordpress.org/ticket/35270#comment:3) makes it into institutional memory. 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. and 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)](https://make.wordpress.org/core/tag/process/?output_format=md#alpha-beta). releases. Plenty of other stuff. 🙂 Start by capturing. As we walk 4.5 release flows, capture. ### Selected quotes from The Checklist Manifesto Checklists supply a set of checks to ensure the stupid but critical stuff is not overlooked, and they supply another set of checks to ensure people talk and coordinate and accept responsibility while nonetheless being left the power to manage the nuances and unpredictabilities the best they know how. [Continue reading →](https://make.wordpress.org/core/2016/03/04/release-process-checklists/#more-16766) [#checklists](https://make.wordpress.org/core/tag/checklists/), [#pitch](https://make.wordpress.org/core/tag/pitch/), [#process](https://make.wordpress.org/core/tag/process/), [#release-process](https://make.wordpress.org/core/tag/release-process/) [ ](https://profiles.wordpress.org/jenmylo/) [Jen](https://profiles.wordpress.org/jenmylo/) 1:42 am _on_ January 5, 2012 Tags: [3.4 ( 20 )](https://make.wordpress.org/core/tag/3-4/), [dev chat ( 907 )](https://make.wordpress.org/core/tag/dev-chat/), process, [scope ( 4 )](https://make.wordpress.org/core/tag/scope/) # 󠀁[Dev Chat Notes for January 4, 2012](https://make.wordpress.org/core/2012/01/05/dev-chat-notes-01042012/)󠁿 When we talked about process in today’s dev chat, one thing I forgot is that at coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. meetupMeetup All local/regional gatherings that are officially a part of the WordPress world but are not WordCamps are organized through [https://www.meetup.com/](https://www.meetup.com/). A meetup is typically a chance for local WordPress users to get together and share new ideas and seek help from one another. Searching for ‘WordPress’ on meetup.com will help you find options in your area. we agreed that we should post the notes and action items from each dev chat, then review the action items at the beginning of the following week’s chat to keep track of things. So here goes! Today’s meeting focused on the process to be used for the 3.4 dev cycle and the overarching concept of the release scope. To read through it line by line, see the [IRC logs for the January 4, 2012 #wordpress-dev chat](https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2012-01-04&sort=asc#m349775). Core team presence: Jane, Ryan, Mark, Nacin, Koop, Dion. Late arrivals: azaozz, duck_. Absent: westi, matt. Agenda: Review new process proposal that came out of Tybee core meetup, discuss; discuss potential focus for 3.4 release cycle; get statements of interest from people interested in taking more formal contributor role in this release. ### Process At Tybee meetup, I proposed we experiment with our process to try and overcome some of our historical downfalls (lack of good time estimation, resource bottlenecks, lack of accountability, unknown/variable time commitments/disappearing devs, overassignment of tasks to some people, reluctance to cut features to meet deadline), and the core team worked as a group to come to the following process proposal. #### Pairs/Teams * We’ll divvy up feature development in pairs/small teams rather than assigning anything to one person. Will hopefully lead to better code, happier coders, and more accountability. * Each pair/team will ideally have a lead/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. teaming with up-and- coming contributors who want to commit to working on something specific.  Leads, committers, and trusted core contribs will be assigned to a team. Newer contributors can volunteer to work with a specific team but probably won’t be part of the core pair if we’re not familiar with your work yet. This will hopefully make it easier for people to get involved and make connections with the core team instead of lingering unnoticed on a ticketticket Created for both bug reports and feature development on the bug tracker. for months at a time. * Each team is responsible for their feature being delivered on time and meeting interim deadlines (scoping, blogblog (versus network, site) posts, posting patches, etc.). * Each team will only be allowed to claim one feature at a time, and may not claim another until the first is complete. No more claiming multiple features and working on them simultaneously. * If a partner/team member goes MIA, rest of team needs to find out what’s up, and if something is seriously wrong, escalate to my attention. * We’ll have a list of who’s working on what worked into the 3.4 schedule page. #### Schedule * 2-week cycles, no soft edges. Every two weeks there is a bit of discovery, a chunk of development, and a period of testing/fixing within the team. * Overlapping team cycles. The 2-week cycles will start on a rotating basis so that teams will be in different phases at all times, allowing for fewer bottlenecks and a greater ability to weigh in on assorted projects. In between each cycle will be several days dedicated to TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. maintenance/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. fixes and tickets related to that team’s project, so that casual contributions won’t pile up waiting for a committer to take a look.⌊Proposed graduated schedule diagram⌉ * Every week, the pair/team must post a progress report to wpdevelwpdevel Formerly the development updates P2 blog at wpdevel.wordpress.com. It is now **make/core** and resides at [make.wordpress.org/core](https://make.wordpress.org/core/). ( once we have team assignments, we’ll make a schedule for this, like we did with gsoc student posts). * At the end of the two week cycle, team must deliver their scoped deliverable ( generally 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.). If they are late, a warning will be issued. If they miss the deadline on 2 of the cycles, the feature will be reconsidered for inclusion in 3.4. #### Time Commitments, Time Tracking * Each team will estimate how long each feature should take (# hours, # days – estimate both total time working on it, and how long that will be spread over based on team member schedules). * We’ll have some mechanism for reporting time spent on the feature so that we can see how our estimates compare. Not sure if this will be manual or if we’ll use a trac 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/](https://wordpress.org/plugins/) or can be cost-based plugin from a third-party.. Investigating options now. Individual“ it took this long” stats will be private, but the aggregate “this feature took this long” will be public. This will remove any reason to fudge the time reporting out of fear of looking too slow. * Like in any job or volunteer gig, we’ll ask people who are assigned to teams to make a specific time commitment per week to working on core in their team. We understand that circumstances change and the time commitments may need to be adjusted along the way, but this is also intended to help us do a better job of preparing scope and using stats to see how we did. If we’ve scoped features that look like they’ll require a total of x hours per week but we only have y in time commitments, we’ll know up front to start trimming scope. Note: making a formal time commitment will not be necessary for casual contributors, only those assigned as an accountable party in a pair/team. * Each two-week cycle will be another chance to get better at estimating how long things will take, and over time we will improve at this as a group.[](http://xkcd.com/612/) ### Scope 3.3 was in some ways a multi-featured mess without a unifying theme. This meant lots of disparate stuff going on at once, and a number of features getting pulled due to timing. We want to get back to the idea put forth a year ago about having one overarching concept/goal/theme per release, that all new feature development fits into. We agreed that 3.4’s “theme” would be, “Making it easier to make your site look how you want it to look.” Shorthand: Appearance/switching themes. The idea is that a combination of front-end features, dashboard features, and under- the-hood improvements all tied to managing your site’s appearance will be the focus of 3.4. It will also include smaller things that don’t live in the appearance section but are related to the overarching goal, such as making it possible to have links in image captions. Make sense? The individual features will be selected next week, and the proposed list of possibilities will be put up before then in a separate post. We’ll figure out teams, everyone will do their scoping exercises for the features they are interested in working on, and then next week we can hopefully start nailing down who’ll start with what and get the final project plan in place for a dev cycle start the following week. High-level, the features would likely include: a theme-setup wizard that would incorporate an option for configuring all the appearance-related stuff before activating a new theme (speaking of, Twenty Twelve is targeted for 3.4), and then specific improvements around menus, widgets, backgrounds, headers, easier static front pageStatic Front Page A WordPress website can have a dynamic blog-like front page, or a “static front page” which is used to show customized content. Typically this is the first page you see when you visit a site url, like wordpress.org for example. process, 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** appearance management, etc. ### Choosing Teams This isn’t gym class; don’t be scared. This is, as stated before, mainly about accountability for the core team. In this cycle, anyone paired with a lead should hopefully be able to lead a pair/team in 3.5, and on and on, so we wind up with lots of experienced teams in the mix. For now, that list is fairly short, but if you are interested in having an official assignment or team designation: [Fill in this short survey.](https://polldaddy.com/s/71DA381EBACCF9E8) As we divvy up leads and committers we’ll keep your request/offer in mind. If we haven’t seen much code from you, you might want to throw yourself into bug patches over the next week or two so there are some examples of how you approach core code available. Anyone not on a team can work on any ticket and/or bug, and can confer with the appropriate team or with Master Gardener Ryan Boren for assistance as needed.  Tentative teams so far: Nacin/dd32/Sergey on language packs, Mark/Pete Mall on multisite, Koop/ocean90 on wizard framework. People who already expressed interest in working with a team or making a time commitment: DH-Shredder, jkudish, helenyhou, drewapicture, MasterJake, tw2113, trepmal, japheth, sabreuse, jorbin, MarkoHeijnen, josephscott, maxcutler, aarondcampbell. We’ll regroup next week to flesh out the scope. ### Action Items * If you are interested in being on a team and/or making a time commitment, [fill in this survey](http://wordpressdotorg.polldaddy.com/s/3-4-dev-team-assignments)– all devs * Figure out core team pairings – core team * Figure out best time tracking solution – Jane, Nacin * Work out initial possible 3.4 features – Jane (1st draft from meetup notes), core team (catch any misses), everyone (brilliant additional suggestions) In case it escaped you, this is a pretty giant change from how we’ve done development in the past. It’s a risk. It could turn out to be the best thing we ever did, or it could crash and burn. Let’s all try our best to make it super awesome! [#3-4](https://make.wordpress.org/core/tag/3-4/), [#dev-chat](https://make.wordpress.org/core/tag/dev-chat/), [#process](https://make.wordpress.org/core/tag/process/), [#scope](https://make.wordpress.org/core/tag/scope/) [ ](https://profiles.wordpress.org/jenmylo/) [Jen](https://profiles.wordpress.org/jenmylo/) 2:46 pm _on_ September 9, 2010 Tags: [dev chat ( 907 )](https://make.wordpress.org/core/tag/dev-chat/), etiquette, process    # 󠀁[The Purpose of the Dev Chat](https://make.wordpress.org/core/2010/09/09/purpose-of-dev-chat/)󠁿 Every now and then it seems like people forget the purpose of the dev chat, or new community members aren’t clear on it, so I thought this, the beginning of a new development cycle, would be a good time to reiterate the purpose of the dev chat. The dev chat is a weekly product team meeting (see [About the Dev Chat](http://wpdevel.wordpress.com/weekly-developer-chats/)), not a weekly social gathering/town hall/q&a. For anyone who’s ever worked at a software company, an agency, etc., this should be a familiar concept: The team working on a software project meets, everyone gives an update on their part of the project, any roadblocks/red flags are identified and solutions are discussed, and updated assignments are given/confirmed. Each release cycle we remind people that this is the intended use of the dev chat, but somehow along the way we wind up losing track of that, and it turns into a combination of dev chat + ideas forum + wp-hackers live. Because the 3.1 cycle is so short ( feature freeze is little more than a month away!), we need to stay focused this time around. We will be much stricter about staying on agenda, and while anyone is welcome to attend, we will ask people who have questions/suggestions that are not on the agenda to either wait until the dev chat is over or to bring it up in another venue, such as wp-hackers, on a TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker., or in the forums. It’s understandable that many people want a direct line to the lead developers, and knowing they will be in a specific place at a specific time makes it easy to corner them to pitch pet requests, but please respect that these busy individuals are continually prioritizing the pet requests of hundreds of people and millions of users. Hijacking their product team meeting doesn’t help anyone’s cause. “Are you kicking me out?” some people may be thinking to themselves. No. The [#wordpress-dev](https://make.wordpress.org/core/tag/wordpress-dev/) channel is open 24/7, and given the time zone distribution, there’s usually one or more lead developers in there, as well as numerous contributors. Discussion about coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. topics is welcome in the [#wordpress-dev](https://make.wordpress.org/core/tag/wordpress-dev/) channel any time, and questions are usually answered gladly (and let’s face it, [@nacin](https://profiles.wordpress.org/nacin/) never sleeps). The weekly team meeting just needs to stay on target, on schedule, and focused on the actual contributing team. Though most people are volunteers working on WordPress core part-time, contributors are part of a product team, and their time should be treated with the same respect that any corporate product team would receive, if not more. If you are not working on patches for this cycle, please let the core product team get through its agenda. Hang on to your other questions to ask during one of the 167 hours per week in the channel that don’t have a specific agenda/schedule, or ask in another venue (Trac tickets are best, since it’s asynchronous and acts as the permanent discussion record for each feature). A good guideline here would be to think of another piece of software that you use. Let’s say Firefox or Microsoft Word. If you wanted a new feature, or wished they would code something a certain way so you could do something you specifically want to do for your clients, would you interrupt their product team meetings to ask for it? If not, then please grant the same courtesy to the WordPress developers. If you would interrupt them because you found something so major that it really needed to be addressed asap (like a security problem), then please don’t wait for the weekly dev chat! Get in touch with the developers in the channel right away, so that someone can assess the issue. If you’re following along in the dev chat and while the team is discussing a specific feature you think of something about the way they’re approaching it that you feel certain the lead devs/core contributorsCore Contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. [https://core.trac.wordpress.org](https://core.trac.wordpress.org) haven’t thought of yet, you are welcome to speak up (having read the Trac ticket first is a good idea, to make sure you’re not raising something that has already been discussed and dismissed). Maybe your idea is brilliant and everyone will thank you for the suggestion/fresh approach — go you! However, if you make your suggestion and the product team is not inclined to take it, please respect their decision. At that point, the best way to try and convince someone that your suggestion is a better approach is to code the 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. yourself and upload it to Trac. Patches speak much louder than words in this case. Remember, the WordPress motto is “Code is poetry,” and for this particular hour each week, the poets are the main event. Thanks! [#dev-chat](https://make.wordpress.org/core/tag/dev-chat/), [#etiquette](https://make.wordpress.org/core/tag/etiquette/), [#process](https://make.wordpress.org/core/tag/process/) [ ](https://profiles.wordpress.org/jenmylo/) [Jen](https://profiles.wordpress.org/jenmylo/) 10:23 pm _on_ July 1, 2009 Tags: process    # 󠀁[Starting next week, we’ll be attempting…](https://make.wordpress.org/core/2009/07/01/starting-next-week-well-be-attempting/)󠁿 Starting next week, we’ll be attempting to follow an agenda during the Wednesday dev chats. If you would like to propose a topic for the July 8, 2009 dev chat, please submit it in the replies/comments to this post. We’ll post an agenda the morning of the dev chat (i.e., about 8-10 hours in advance). [#process](https://make.wordpress.org/core/tag/process/)