Earlier this year, I ran into a few people who contributed patches to WordPress, then didn’t hear anything about them for years. This experience led them to not contributing anymore. Some of these folks were first time contributors. They felt that if their time and effort to put together a patch that only needed testing was going to be ignored, it wasn’t worth it.
I can see how a contributor would want to see action on their patch within a few weeks of submission. But WordPress has two fire hoses. One blasting out and the other blasting in. Despite the number of people with commit access, there are not enough people to review and test each patch that is submitted. Patches have a pretty good shot at falling through the cracks, especially if those contributions are not tied to anything in the next one or two major releases.
So that’s one scenario. But what if someone contributes a patch to WordPress and it sits around for a few months or years, only to have a sponsored/paid contributor create a similar patch and get the green light to have it committed. The person who submitted the original patch probably wouldn’t feel too good. Unfortunately, this happened to a contributor not once, but at least twice.
On the one hand, the patch was applied to WordPress. On the other, the original contributor is left scratching their head asking WTF?
When it comes to contributing code to WordPress, it can be a full-time job. You not only have to put everything together and submit the patch to SVN or GitHub so it can be tested, but then you have to show up to meetings and continuously advocate for yourself and your code. It’s a tiresome process and one that many people can’t afford to participate in. When the project loses someone like Aurooba from contributing in the future, that’s a problem.
So, what are the solutions here? Hell if I know! That’s why this post is in a series called the Ramblin’ Presser. I suppose in a perfect world, WordPress would have enough people and be caught up on everything to not only focus on upcoming Maintenance and Feature releases, but also review the myriad of patches for all of the other aspects of the project within a reasonable time frame.
The good news is that major WordPress releases are continuing to experience a healthy dose of participation from first-time contributors. What would be good to know is how many of those first-time contributors become second and third time contributors. If they’re not, someone needs to find out why and translate those reasons into actionable items.
People power is a finite resource. Money can only purchase so much.
Sadly, I can relate. I’ve had a patch that’s been approved for years but sits there. Finally, someone told me I have to advocate for it to be included in a release by attending meetings. Wut? I had to advocate for it to even get approved which really felt like an attack.
Why isn’t it someone’s job during a release to go through the approved patches and milestone them?