A glossary for contributors
As part of the core contributor handbook, there’s going to be a glossary. Here’s what I’ve put together so far.
Something missing? Leave a comment. Feel free to also weigh in on new and existing definitions, examples, and the like.
a11y: Accessibility, or the act of ensuring that user interfaces are accessible for persons of all abilities and disabilities.
back compat: Backwards compatibility — a desire to ensure that plugins and themes do not break under new releases — is a driving philosophy of WordPress. While it is a commonly accepted software development practice to break compatibility in major releases, WordPress strives to avoid this at all costs. Any backwards incompatible change is carefully considered by the entire core development team and announced, with affected plugins often contacted. It should be noted that external libraries such as jQuery do have backwards incompatible changes between major releases, which is often going to be a greater concern for developers.
backport: A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch.
bleeding edge: The latest revision of the software, generally in development and often unstable. Also known as trunk.
blocker: A bug which is so severe that it blocks a release.
branch: A directory in Subversion. WordPress uses branches to store the latest development code for each major release (2.8, 2.9, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions is collectively referred to as a “branch,” such as “the 2.9 branch.”
commit (noun): An individual change to WordPress, identified by an incremental revision number. Also called a changeset.
commit (verb): To make a change to WordPress. Only committers can commit code, but often the code is contributed by developers without commit access.
committer: A developer with commit access. WordPress has five lead developers and two permanent core developers with commit access. Additionally, there are two developers with commit access for a specific component, and the project sometimes has one or more guest committers — a developer receiving commit access, generally for a single release cycle and for a specific component.
conflict: A conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved.
CSS: Cascading Style Sheets.
dogfood: The practice of using one’s own software, typically bleeding edge (trunk), thus “eating one’s own dogfood.”
i18n: Internationalization, or the act of writing and preparing code to be fully translatable into other languages. See also localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill. 
invalid: 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.
IRC: 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.
JS: JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors.
L10n: Localization, or the act of translating code into ones own language. See also internationalization. Often written with an uppercase L so it is not confused with the capital letter i or the numeral 1. WordPress has a capable and dynamic group of polyglots who take WordPress to more than 70 different locales.
major release: A release, identified by the first two numbers (3.2), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.
make/code: The development updates P2 blog at make.wordpress.org/code. Formerly wpdevel. [todo]
make/ui: The UI working group P2 blog at make.wordpress.org/ui.
P2: A free theme for WordPress, known for front-end posting, used by WordPress for development updates and project management. See our main development blog and the other workgroup blogs.
patch: 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.
PHP: The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.2.4.
point release: A minor release of WordPress, identified by the third number (the 2 in 3.1.2). These releases are for maintenance and security fixes only. Feature development is limited to major releases. Changes to point releases are carefully considered and are only critical or blocker-level bugs and security enhancements, hardening, and fixes are accepted.
priority: The seriousness of a bug report or ticket in the eyes of the project. Generally, severity is a judgment of how bad a bug is, while priority is its relationship to other bugs.
regression: 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.1 regression” would be a bug in 3.1 that worked as intended in 3.0.
severity: The seriousness of the ticket in the eyes of the reporter. Generally, severity is a judgment of how bad a bug is, while priority is its relationship to other bugs.
SVN: Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase.
tag: A directory in Subversion. WordPress uses tags to store a single snapshot of a version (2.8, 2.8.1, etc.), the common convention of tags in version control systems.
ticket: Created for both bug reports and feature development on the bug tracker.
Trac: An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.
triage: The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors.
trunk: 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.
UI: User interface
UX: User experience
wontfix: 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.
worksforme: A resolution on the bug tracker (and generally common in software development) that indicates the bug reported cannot be reproduced.
wpdevel: Formerly the development updates P2 blog at wpdevel.wordpress.com. It is now ‘make/code’ and resides at make.wordpress.org/code. [todo]
Ptah Dunbar 2:42 pm on July 1, 2011 Permalink
This also applies to using one’s own public APIs internally too.
Andrew Nacin 2:43 pm on July 1, 2011 Permalink
Yep.
Andrew Nacin 2:43 pm on July 1, 2011 Permalink
Should include: “Not to be confused with post tags” etc.
John Lamansky 3:06 pm on July 1, 2011 Permalink
It seems to me a commit connotes that a change has indeed been applied to WordPress, while a changeset can refer to potential changes, as in a proposed patch’s changeset. I don’t think the two are synonymous.
Peter Westwood 3:26 pm on July 1, 2011 Permalink
A changeset is a specific thing in the world of Subversion – It is a set of changes which were applied to create a revision in source control.
A patch is not a changeset IMHO
John Lamansky 3:07 pm on July 1, 2011 Permalink
Here are some additional terms you might consider adding:
AJAX
nonce
PHPdoc
PO / POT / MO
salt
WP_DEBUG
XMLRPC/APP
xref
bentrem 3:19 pm on July 1, 2011 Permalink
Sidebar: I just realized that notification by email / subscription includes the entire post. Which, vast majority of the time, is just fine. But …
… maybe I’m paranoid by nature. Does “send the whole” make sense as default?
p.s. vague memory of a working glossary from Moz, shortly after the code was released. IIRC it was never authoritative, but it was a nice slab of verbiage.
bentrem 3:20 pm on July 1, 2011 Permalink
erratum – s/ “make sense as default?” [yes!] / without upper limit make sense as default?
Andrew Nacin 3:25 pm on July 1, 2011 Permalink
Yes, I think it does. I consume a number of blogs through RSS and a number more through email, and the lack of full content is terribly annoying.
bentrem 5:56 pm on July 1, 2011 Permalink
Agreed.
What I pondered is that rare item that is really large. Like, say, a glossary that’s fully fleshed out. NM … #quibble.
Andy Skelton 3:28 pm on July 1, 2011 Permalink
The term “a11y” is ironically inaccessible.
Mark Jaquith 3:29 pm on July 1, 2011 Permalink
I d2′t k2w w2t y2′re t2k2g a3t!
Andy Skelton 3:32 pm on July 1, 2011 Permalink
I f3d t1e f7g s6e u7y r6e.
Andy Skelton 3:32 pm on July 1, 2011 Permalink
(I found the foregoing sentence uncannily readable.)
bentrem 5:58 pm on July 1, 2011 Permalink
When I saw it in email I blew it off as noise. When I saw it here I … just read it. hunh …
Aaron Jorbin 3:29 pm on July 1, 2011 Permalink
Missed: maybelater (since that is a way we close tickets)
Suggest to modify: a11y . I think we should use the language that WCAG uses and say “Accessibility or the act of ensuring a high quality experience for all WordPress users regardless of blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, limited movement, speech disabilities, photosensitivity and combinations of these”
Andrew Nacin 3:36 pm on July 1, 2011 Permalink
I have a whole separate section for keywords, ticket types, and resolutions, though they’ll all probably be cross-listed in the glossary.
Ron 3:31 pm on July 1, 2011 Permalink
include the ticket tags – has-patch, needs-testing, etc.
Mark Jaquith 3:31 pm on July 1, 2011 Permalink
Daryl Koopersmith 3:37 pm on July 1, 2011 Permalink
PAINT IT GREEN.
Peter Westwood 4:03 pm on July 1, 2011 Permalink
BLUE!
Aaron Jorbin 4:37 pm on July 1, 2011 Permalink
RED
Andrew Nacin 4:42 pm on July 1, 2011 Permalink
Red and green is fine, but please more red than green.
Chris Hajer 3:36 pm on July 1, 2011 Permalink
Pinking Shears? http://is.gd/PjjFU9
Andrew Nacin 3:40 pm on July 1, 2011 Permalink
LOL. We use these to trim excess whitespace.
Chris Hajer 3:47 pm on July 1, 2011 Permalink
What command in what editor do you use? Thanks @nacin
Andrew Nacin 3:55 pm on July 1, 2011 Permalink
Typically a quick perl script.
Dougal Campbell 3:46 pm on July 1, 2011 Permalink
AJAX (mentioned already), jQuery, Dashboard, Settings/Options, API, wp.org vs. wp.com?, bbPress, BuddyPress, MultiSite, must-use plugins, drop-ins, MySQL, Roles + Capabilities, Admin/Super-Admin…
Andrew Nacin 3:55 pm on July 1, 2011 Permalink
We sometimes use codenames and acronyms for incoming features. For example, DFW. Can anyone think of others?
Andrew Nacin 3:56 pm on July 1, 2011 Permalink
Crazyhorse.
andrea_r 4:04 pm on July 1, 2011 Permalink
Can’t BELIEVE you forgot alot. Alot is now sadpants.
Also possibly not glossary worthy but maybe a mention somewhere: that devs referece parts of WP by the function names and not what they are called in the admin area.
Some examples:
multisite = network
custom permalinks = pretty permalinks (tho that’s a really easy one, I have a funny story for you)
Jon Cave 4:06 pm on July 1, 2011 Permalink
HEAD
Curtiss Grymala 4:11 pm on July 1, 2011 Permalink
Although you included diff in the definition for patch, you might want to give it it’s own entry that says something like:
Might also want to define hook, callback, action, filter and API. Might not be a bad idea to give definitions of the way WordPress uses common words like priority (i.e., a “higher” priority actually means it occurs later in a process), etc.
Curtiss Grymala 4:12 pm on July 1, 2011 Permalink
Ooh. Also, might want to define the way network, site and blog are used when referencing multisite; and how they differ in the core code.
Andrew Nacin 4:14 pm on July 1, 2011 Permalink
Yeah, a lot of the cross-references aren’t done yet. Good call especially on the plugin API ones.
Brian Layman 4:49 pm on July 1, 2011 Permalink
Debug Mode – Inside wp-config, having define(‘WP_DEBUG’, true); which enables extra messages inside WordPress that allow you to figure out what your code is doing and reveal previously hidden issues. Related to this topic are the constants WP_DEBUG_DISPLAY and WP_DEBUG_LOG
Aaron Jorbin 4:49 pm on July 1, 2011 Permalink
I Would add definitions for the release process stages (Planning meeting, Feature Freeze, Beta, RC) which I imagine you have somewhere else.
One more worth considering:
Nacin – A robot from the future sent back in time to ensure the survival of WordPress. Rumored to be created and programmed by Matt Mullenweg’s Great Great Great Grandson and Ryan Boren’s Great Great Great Great granddaughter.
Curtiss Grymala 5:11 pm on July 1, 2011 Permalink
Yeah. Should probably add a definition for #blamenacin, too.
Brian Layman 4:59 pm on July 1, 2011 Permalink
I’m going back and forth on ones like:
json, serialized, escape, prepare,transient, object cache
Eric Mann 8:08 pm on July 1, 2011 Permalink
I’d agree on “transient” … but the rest seem a bit unnecessary.
bentrem 6:02 pm on July 1, 2011 Permalink
For reference: Master Glossary from CMSCalendar.com
Mario Peshev 10:10 pm on July 12, 2011 Permalink
I would define Unicode/UTF8 as an important thing to know for collaborative work with files including source.
Copyright and Licenses as well.
Test-Driven development and BDD. Methodology and process (beginning to the end)
Probably IDE, backup, refactoring, high quality code, comments, test cases…