Hanging out in the #WordPress irc channel or on the wp-hackers mailing list, a question that comes up from time to time is “How do I get a bug patched”. I recently had a patch committed, so I thought I would detail the process from start to finish to help others get an idea of the process. I can’t guarantee that others will have the same experience, or that even I will have the same experience next time, but this was how I had my first substantial patch committed to WordPress.
The process for me started by seeing a post by Jane Wells talking about a few UX enhancements she wanted to see handled during the recent patch sprint. One that I noticed hadn’t received any attention was Showing the status of an admin attempts an e-mail change under the new multisite configuration. I took a quick look at the relevent code and figured this was something I could patch.
Lesson 1: Make it easy for coders and non-coders to see the change
After I wrote my first iteration of a patch, I hopped into #wordpress-dev and Andrew Nacin recommended that I add a screenshot to make it easier for Jane to see the change. I couldn’t agree more that this was a great idea. After all, why should you need to apply my patch & test it, or understand the code behind it just to comment on it.
Lesson 2: Just because you write the patch, doesn’t mean others don’t have good ideas for it
I then waited till I was in #wordpress-dev at the same time as Jane and brought up the ticket. This led to a conversation between Jeremy Clarke, jane and myself about the best way to let users know. During this time I went thought a few other iterations and shared those on the ticket. We didn’t come to a firm conclusion, and the next morning Nacin commented with a suggestion on the ticket.
Lesson 3: Sometimes one small change leads to another
The next day I once again headed to #wordpress-dev where Jane, Nacin, and I took another stab at it and decided that an inline warning box would give the proper notification without being distracting. While writing the final version of the patch I noticed that all warning boxes automatically moved to the top of the screen. Nacin took ownership of fixing this, made a few minor changes to my patch and committed changeset #13446. Now not only will users be able to see pending admin e-mail changes, but developers can use the existing UI warnings inline.
Overall, the process to fix this UX bug took four people and multiple iterations. I want to thank all three others for assisting me. While there are times that errors make it into the released version of WordPress, I hope this story gives you the idea of the effort that the core development team takes to make sure only the highest quality code and user experience for users.
Pingbacks
This Article was mentioned on brid.gy
This Article was mentioned on brid.gy
This Article was mentioned on brid.gy
This Article was mentioned on brid.gy
This Article was mentioned on brid.gy
This Article was mentioned on brid.gy
This Article was mentioned on brid.gy
This Article was mentioned on brid.gy