I say no to a lot of pull requests on code.
This is because I write plugins, not something massive and monolithic and used on a million websites. I’m a sole developer for my code, for the most part, and while pull requests are always welcome, the main reason I reject them is because I eat my own dogfood.
Back in March of 2015, I decided to start using CloudFlare because we, at DreamHost, parter with them, so I should, you know, use them. It’s the same reason I use PageSpeed so much. And WordPress. I use what I use because I need to use it to be good at it.
You cannot possibly be expected to write code for WordPress and support it if you don’t use it.
I say this over and over again when I’m training people on WordPress. If you want to get good at supporting and fixing WordPress, then you need to use it and fix it. A lot. Every day. You need to use it so you know where everything is and can recognize what it should and should not do. You need to fix it so you know how to make it go back to looking like it should.
If you’re writing code for WordPress, you need to do that too.
Here’s my bottom line. If I’m writing a plugin, it’s going to be because I need what it does. If I’m writing a plugin, it’s because I’m going to use it. If there’s a feature I disagree with, I won’t add it in. If it’s something I will never use, it’s not going in. If it’s code I cannot test, I will never, ever, add it.
That last one gets people mad at me a lot.
The reality is that if I add in a feature for you and it doesn’t work, I can’t fix it because I don’t have the access needed. I cannot reproduce the error. If I can’t do that, how can I possibly fix it? I’ll have to work with you, via posts and emails, if you can’t fix it yourself.
Pull requests are a wonderful thing, but if you’re making a pull for a new feature that’s something I can’t validate and test, then you’re also taking on the responsibility I did for the community. You’re promising to help me test it, develop it, future proof it. You’re promising to be there when I want to release a new version for everyone else. You’re promising to help support it and help others debug it.
Are you ready for that?
Comments
4 responses to “Coding My Own Dogfood”
Do you use the Plugin API to create extension points in your plugin? I am going to do a presentation on this and I’m curious of you are and people are still offering pull requests or if you aren’t and they are offering pull requests for the express purpose of extending or changing your code.
I should tweet the YouTube video later. Presentation is almost done. It is going to be a long one.
@Jacob Santos: Extension points, like adding in filters and hooks, always accepted. If they don’t change the BASE functionality of the plugin and just add in things that people can apply on their own, I don’t see it as quite the same as the oft requested “Can you re-code this whole section to work with multiple servers?” (If I can’t TEST that, I’m real scared about applying it…)
@Ipstenu (Mika Epstein): That part I definitely understand and agree with. There are Continuous Integration online tools that allow testing on Windows. I think the amount of available environments is limited. Probably not going to allow IIS for proper WordPress testing. I know of other browser testing online services, but I don’t believe they work like Appveyor or TravisCI.
It could be possible to setup environments on Azure and create a service for testing WordPress plugins on various environments. That might be a cool service. Of course, you work for a competitor, so I’m not sure how that factors in.
Dreamhost supports OpenStack right?
@Jacob Santos: Oh yeah, IIS is it’s own special hell. And yes, DreamHost does support OpenStack … That’ll end up on my wish list for “The world where Mika has more free time!”