You’re a WordPress developer and you attend WordCamps?
But I ask you? Have you ever attended a Contributor Day?
The reason I ask is many WordCamps now are actually two-day events. First day is the general conference with speakers and the second day is a contributor day. I have attended the contributor days at WordCamp Seattle for two years now and it’s a great place to learn, talk, discuss WordPress core and how you can contribute back to WordPress. (Hence the name)
Have you working with WordPress and said:
I wish I had time to suggest or submit an improvement to WordPress.
I think this is a bug but I am not sure and I am way to busy at work to investigate.
Why doesn’t the codex have updated documentation on this.
There are a lot of unanswered questions in the forums.
These are all great reasons to go to a contributor day and give back to the community!
You’ll also be able to meet and chat with other developer and often their are core contributors or committers to WordPress in attendance that you can converse with.
So if you love WordPress and want to start contributing but don’t know where to start. Then attend a contributor day and find a way to give back.
Although I went to school for web design I basically taught myself HTML and CSS. I am generally an organized person, so I always kept my CSS neat and organized. So if someone had to pick up where you left of they code without a huge amount of trouble.
Another Vancouver WordPress developer Joey Kudish had done the same for Christine’s blank themes and pickup up a lot of good habits from those two and many others.
This past month I had two examples of how important this truly is!
One site was small but needed to be professional and only had a three week timeline from start to finish. I took Christine’s Bold Headline theme from the WordPress Theme Directory, Changed the font, moved a few things around, added my own footer and a couple other style flourishes. The client love it, deadlines were met everyone was happy. But it all started with Christine’s Bold Headline (which originally started off as a Underscores default theme).
Christine had a good foundation with Underscores and made Bold Headline
I had a good foundation with Bold Headline and made my clients deadline.
The second example was less so.
It was a theme that was purchased from a theme house and I was contracted out to make a number of similar changes to this theme. A font change here, a new footer there and a couple other style flourishes to give the theme it’s own feel.
(Don’t judge a book by it’s cover some theme houses have great code and awesome developers working for them.)
After checking the support forums of the theme developer he didn’t provide any support if a single line of code was changed to his theme. If it wasn’t in the customizer. Don’t try it and if you do I can’t help you with it. Also it was said this theme could be used with the current version of WordPress btw.
I now know why he provides no support to making even slight changes to the theme. The theme’s is a mess of hacked code with no rhyme or reason why it was done. Italics tags with the italics removed, anchor tags with both absolute and relative positions to them (you should never apply a position to a anchor tag anyway) … I could go on but it makes me cringe and nothing was commented…
Now I am not without my abilities and I was able to modify the existing theme to suit the clients purposes and they are happy with there site.
But both themes have left me with two very different feelings on completion.
The first theme I’d gladly work on again. I can adapt change to the clients needs and anyone with WordPress, HTML and CSS knowledge could work on this. They need some plugin that changes the functionality of the site. Shouldn’t be a problem.
The second theme: I never want to see again… Not because the work I did was of poor quality, or I am ashamed of what I did. But because any small amount of code change could completely break the theme. Just to change a icon took over an hour and for no good reason. Who know what will happen if or more likely when you want to add something to the site.
Coincidentally both projects came out to similar prices.
So the moral of this story is to always start with a good foundation or else you’ll be living with a website that feels like this:
When New Year’s comes along we all make a few New Year’s resolutions that are unachievable or broken instantly but this year I made my goals more work orientated that would help me achieve more productivity and make it easier to collaborate with others. ( I actually start writing this post in February. )
One of these goals were met by finding a project management software that actually works for me instead of me working for it. I found that with Asana, It’s is as much of a project management software that I need and when I asked others to start using it there wasn’t a whole lot of backlash and they all started using it. It has cut down on the mass emails with multiple changes.
The other major goal was use of a revision system for larger project. I found that easily accomplished with GitHub.
I found listing the combination of GitHub and Asana extremely useful and productive.
Other achievements were less business-oriented but more community orientated like submitting my first bug report in both WordPress and Firefox. Both of them are confirmed as a bug. It allow me to help other users and other developers showing what I am seeing and moving the project forward it feels good to help out.
While I did join the UI group I found it hard to keep up with the emails and weekly meeting and such when I had project deadlines looming of my work. But also the WordPress UI group merged and for good reason with the WordPress core dev group.
While it’s a short list… It was a journey of sixth months taking me from barely understanding how to submit a trac ticket to actually having css committed into Twenty Thirteen.
While I like Twenty Thirteen there was a couple things I really wanted to change as well. I needed something darker and to keep the post titles above the content. Ever since wp 3.4 (June 2012) child theme were accepted into WordPress theme directory I decided to submit my very first theme to the theme review team.
So if you reading this blog post your actually seeing my first child theme that was accepted into the WordPress theme directory called R2D2.
For a guy who never makes New Year Resolutions I certainly didn’t break this one… In fact I contributed more the WordPress community then I though I was ever capable of…
Funny you ask that… development for the new theme Twenty Fourteen just got started and yup I plan to be involved with this one too… All this open source contributing too… It’s addictive as you get some much back in return.
I was asked by the organizers of WordCamp Vancouver to give a lighting talk on how to submit a proper Trac Ticket for WordPress. Here is the transcript of the talk. Hopefully the video will make it’s way up to WordPress.tv.
After using WordPress for years my First Trac Ticket I submitted was actually only last December and interesting enough it’s still open as of August 2013.
But first… a word from Nacin…
Do not report potential security vulnerabilities in WordPress in Trac as you will be telling the whole world how to exploit the loophole. email WordPress directly at security [at ] wordpress dot org
What is Trac?
Trac is open source software that WordPress uses. It is the place where all of those design / functionality decisions are made. It is part project management, part bug tracking software, part repository (via SVN). It is all of those things at exactly the same time. The only thing it doesn’t do is provide support… but don’t worry that’s what the forums are for…
Check list before submitting a ticket.
a. What version of WordPress are you running?
– If your running alpha or beta make sure you grab the latest build before submitting.
b. Has it been submitted previously?
– Do a query on trac before submitting a new one.
c. Check in various browsers. Is it consistently replicated? Which browser does what?
– Record in the description what you find…
d. If you turn off all of your plugins does still happen?
e. If it’s something visual take screenshots. Annotate if possible.
– You can upload screenshots directly to trac or use something like cloud app.
f. A link to the page or site with the issue.
g. Make sure the code is actually core and no your own.
– eg. If you child themes has code in the function file that overwrites the parent theme then it is your code and not core.
You now have all the details required to complete a useful trac ticket.
2. Description: Explain the issue explain as much as you can. You can also upload screenshots directly to trac. A lot of people use screenshot programs like cloud app. Any service will work as long as it is reliable.
3. Type: Bug, Enhancement or Feature Request
4. Version of WordPress:
– Which version of WordPress are you using to product the bug?
(eg. Trunk is currently in 3.7 and once that is release Trunk will be into 3.8)
5. Workflow Keywords: (couple common ones)
• Reporter Feedback (needs more detail from the actual reporter of the ticket)
• Needs Patch (needs a patch ???)
• Has patch (either you or someone has submitted a patch to this)
A full list of keyword descriptions can be found here.
If you don’t know what the keywords means then don’t apply it. Core committer like Sergey Biryukov who truly have amazing attention to detail in Trac will apply keyword if needed. (If you put enough detail in the description they will be able to figure it out)
6. Priority: Reporters without commit status can’t set this… But they range from:
• Highest OMG BBQ.
“Which means it is as Important as BBQ… Sadly you don’t get BBQ if you close this ticket.” ~ Samuel Wood ( Otto42 ) WordCamp Seattle 2013
7. Component: • Default Themes are called: Bundled Themes as they are bundled with core.
• Post Format are about Post Format’s
• Widgets are about Widgets
If you don’t know where it fits just choose general and those above you on the “Trac food chain” like Sergey will find the proper home…