The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA 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.?Create a ticket in the bug tracker.
Great software should work with little configuration and setup. WordPress is designed to get you up and running and fully functional in no longer than five minutes. You shouldn’t have to battle to use the standard functionality of WordPress.
We work hard to make sure that every release is in keeping with this philosophy. We ask for as few technical details as possible during the setup process, as well as providing full explanations of anything we do ask.
Many end users of WordPress are non-technically minded. They don’t know what AJAX is, nor do they care about which version of PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher they are using. The average WordPress user simply wants to be able to write without problems or interruption. These are the users that we design the software for, as they are ultimately the ones who are going to spend the most time using it for what it was built for.
When making decisions, these are the users we consider first. A great example of this consideration is software options. Every time you give a user an option, you are asking them to make a decision. When a user doesn’t care or understand the option, this ultimately leads to frustration. As developers, we sometimes feel that providing options for everything is a good thing, you can never have too many choices, right? Ultimately these choices end up being technical ones, choices that the average end user has no interest in. It’s our duty as developers to make smart design decisions, and avoid putting the weight of technical choices on our end users.
The coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. of WordPress will always provide a solid array of basic features. It’s designed to be lean and fast, and will always stay that way. We are constantly asked “when will X feature be built” or “why isn’t X pluginPluginA 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 integrated into the core”. The rule of thumb is that the core should provide features that 80% or more of end users will actually appreciate and use. If the next version of WordPress comes with a feature that the majority of users immediately want to turn off, or think they’ll never use, then we’ve blown it. If we stick to the 80% principle, then this should never happen.
We are able to do this because we have a very capable theme and plugin system, and a fantastic developer community. Different people have different needs, and having the sheer number of quality WordPress plugins and themes allows users to customize their installations to their taste. That should allow all users to find the remaining 20% and make all WordPress features those they appreciate and use.
We’re never done with simplicity. We want to make WordPress easier to use with every single release. We’ve got a good track record of this; if you don’t believe us, then just take a look back at some older versions of WordPress!
In past releases, we’ve taken major steps to improve ease of use and ultimately make things simpler to understand. One great example of this is core software updates. Updating used to be a painful, manual task that was too tricky for a lot of our users. We decided to focus on this, and simplified it down to a single click. Now anyone with a WordPress install can perform one click upgrades on both the core of WordPress, and plugins and themes.
We love to challenge ourselves and simplify tasks in ways that are positive for the overall WordPress user experience. Every version of WordPress should be easier and more enjoyable to use than the last.
Deadlines are not arbitrary, they’re a promise we make to ourselves and our users that helps us rein in the endless possibilities of things that could be a part of every release. We aspire to release three major versions a year because, through trial and error, we’ve found that to be a good balance between getting cool stuff in each release, but not too much that we end up breaking more than we add.
Good deadlines almost always make you trim something from a release. This is not a bad thing, it’s what they’re supposed to do.
The route of delaying a release for that one-more-feature is, literally, a rabbit hole. We did that for over a year once, and it wasn’t pleasant for anybody.
The more frequent and regular releases are, the less important it is for any particular feature to be in this release. If it doesn’t make it for this one, it’ll just be a few months before the next one. When releases become unpredictable or few and far between, there’s more pressure to try and squeeze in that one more thing because it’s going to be so long before the next one. Delay begets delay.
There’s a good rule of thumb within internet culture called the 1% rule. It states that “the number of people who create content on the internet represents approximately 1% (or less) of the people actually viewing that content”.
So while we consider it really important to listen and respond to those who post feedback and voice their opinions on forums, they only represent a tiny fraction of our end users. When making decisions on how to move forward with future versions of WordPress, we look to engage more of those users who are not so vocal online. We do this by meeting and talking to users at WordCamps across the globe. This gives us a better balance of understanding, and ultimately allows us to make better decisions for everyone moving forward.
WordPress is licensed under the General Public License (GPLv2 or later) which provides four core freedoms, consider this as the WordPress “bill of rights”:
The freedom to run the program, for any purpose.
The freedom to study how the program works, and change it to make it do what you wish.
The freedom to redistribute.
The freedom to distribute copies of your modified versions to others.
Part of those licensing requirements include licensing derivative works or things that link core WordPress functions (like themes, plugins, etc.) under the GPLGPLGNU General Public License. Also see copyright license. as well, thereby passing on the freedom of use for these works as well.
Obviously there are those who will try to get around these ideals, and restrict the freedom of their users by trying to find loopholes or somehow circumvent the intention of the WordPress licensing, which is to ensure freedom of use. We believe that the community, as a whole, will reward those who focus on supporting these licensing freedoms instead of trying to avoid them.
The most responsible use of WordPress community resources would therefore be put to best use by emphasizing high quality contributions that embrace the freedoms provided by the GPL.