If you're a developer and/or contributor, take a few minutes out to read this. Nice quote: "User trust isn’t something you earn and then just get to keep forever. It’s a maintenance relationship."
Helen Hou-Sandi, in response to someone suggesting a large rewrite in slack wrote this: Your plan as I understand it disregards a couple of core WordPress philosophies/practices: striving for maintenance of backwards-compatibility, and that an X.0 release is no more significant than X.1 or Y.9 (this is closely related to maintaining back-compat, in that something like semantic versioning is less meaningful for WordPress core).
Generally, the most successful refactorings in core have been done in support of features being built, whether that’s a user- or dev-focused feature. It’s not that core code can’t be improved (clearly it can), it’s that better decisions regarding back-compat and, more importantly, forward-compat for an API or other bit of code can be made when one eye is on practical application.
As a user centric project, WordPress chooses philosophies that put the user first. There is also an unwritten philosophy point that many committers talk about which is that User Trust Matters. What that means to me is that users trust WordPress for running businesses, sharing content, and engaging with their own users. User trust must be maintained in order to
What if we had a twenty sixteen theme idea session and that the theme could be released with ReactJS and WP-API?
Aaron Jorbin compiles some interesting stats for 2016. Example: The total number of commits is down from 5106 to 2967.
I’m sharing these stats with the duel caveat that commits aren’t a great measure of impact and that commits only represent one type of core contribution. When I talk about employers it’s with the caveat that some people change jobs. Also not everyone works on donated time. Now that I have looked at these numbers for two years I think that it’s interesting to see the trends. In 2015 31 people with 16 unique employers committed to WordPress core. In 2016 it’s 37 people with 20 employees.
The employer with the highest percentage of commits in 2016 remains Automattic at 14.66%. This is down from 20.37%.
The individual with the greatest number of commits is @ocean90 at 360. Last year it was @wonderboymusic.
The total number of commits is down from 5106 to 2967. While that number is big I don’t think it’s necessarily bad.
For props this year 750 individuals got props with 396 for the first time. This is up from 721 total and 379 first timers in 2015. 91 people contributed to every release in 2016 vs 94 in 2015.
"If you contribute to one release, there is a 46% chance you will contribute to the next release. "
I posted a graph of new WordPress contributors per release and Brian Krogsgard had some questions that I decided to look into. Mostly he wanted to know how well WordPress did at maintaining contributors. So I made some more graphs. In general, past contributions as a predictor of future contributions are pretty consistent across releases. If you contribute to one release, there is a 46% chance you will contribute to the next release. Overall, 44% of individuals who have contributed, have contributed at least twice. While on its head, that means 56% of people only contributed once, digging in I was able to find that from 3.2 to 4.3, if you contribute, there is a 70% chance you will contribute again.
A total of 12 individuals contributed to all 14 versions analyzed and 57 contributed to 10 or more versions.
What does this mean? Mostly that we need to continue watching for change in this regard. Outside of 4.4, WordPress has remained consistent. Adding the git mirrors didn’t change anything. Switching to including the build tools and tests in the repo didn’t either. As the WordPress contribution process continues to evolve, it will be interesting to see what if anything moves
A funny - and useful - read for WordCamp organizers and attendees.
Last year, the WordCamp US organizing team asked me to assist them with putting all the selected talks into the grid. It was a lot of fun and a challenge, but I was able to do it because I had a set of personas ready. Personas are regularly used in web design to make sure that you are solving your users. Usability.gov describes effective personas as having these five characteristics:
Represent a major user group for your website
Express and focus on the major needs and expectations of the most important user groups
Give a clear picture of the user’s expectations and how they’re likely to use the site
Aid in uncovering universal features and functionality
Describe real people with backgrounds, goals, and values
When looking through the attendee list from previous WordCamps, looking through pictures from those camps, and drawing on the dozens of WordCamps I have attended, I came up with ten personas that I used. My goal was to make sure whenever possible, each persona would want to attend only 1 session per slot (minimize FOMO), If there was nothing in one slot for a persona, there absolutely was something in the session that followed.
Adjusting usabilities Persona guidelines
New features to the grunt-patch-wordpress which adds 2 cool features: GitHub URL Support and uploading patches from command line.
Today I released an update to grunt-patch-wordpress which adds 2 cool features. GitHub URL support. You can now use grunt patch:https://github.com/aaronjorbin/develop.wordpress/pull/3 with any copy of WordPress on GitHub. No longer will you need to download the patch manually. Works for both core and develop mirrors on GitHub. This feature was suggested by Helen 侯-Sandí
Upload patches directly from the command line. No longer will you need to create a patch and manually upload it to trac. grunt upload_patch:20000 will upload a patch to the appropriate ticket after a user enters a WordPress.org username and password. This is limited to users with the appropriate XML-RPC privileges in trac (right now, that is just bug gardeners). You still need to manually add the `has patch` keyword. This feature was added by Eric Andrew Lewis. Thanks Eric!
Full changelog: https://github.com/aaronjorbin/grunt-patch-wordpress/compare/0.3.0…0.4.0
Thanks to the following additional people for contributing to this release: Stephen Edgar and Michael Beil. Further enhancements to make it easier to work with WordPress Trac are always welcome. Also, I would love a logo or wapuu for grunt-patch-wordpress,
A great idea! "I wouldn’t be surprised to find out that WordPress runs on well over 100,000 different stacks."
So this is a half-baked idea. Well, maybe 3/4 baked since I’ve mentioned it to a few people. Right now, Automated testing in WordPress is based on Travis CI. Which works pretty well. Tests are run on 1 OS vs 8 versions of PHP (plus hhvm, but those don’t pass) which based on my completely unscientific estimates covers less than 0.1% of the actual WordPress userbase. If WordPress really wants to do quality automated testing, we need to rely on the people hosting sites to test vs their stack. To do that, Core needs to provide an infrastructure that both encourages and enables easy automated testing.
It’s not that the current test matrix is bad, but it currently is only covering a small corner of the true test matrix.
What I would like to see is an API that hosts (both shared and dedicated) could use to register their unique setups for automated testing. Using PUBSUBHUB, WordPress Core would signal that a change has taken place. Then, the hosts could run their setup(s) vs the new version of trunk. They could run both a plain version of trunk, but also perhaps the version that includes everything they install as a part of a new site and whatever “one click installer”