I always feel like I’m somehow betraying the WordPress community every time I speak the truth. The issue is that, when Matt speaks or any of the core developers, it is all happy joy, no problems here. It limits my credibility greatly to come back and say, “Well, no, it has this problem and this problem.” Who are people going to believe? The guy(s) who actually has access to the source code or some guy no one knows or cares about?
I’ll give you a second or two to guess.
EDIT: In summary, I’ll be happy if this was on the front page of trac, albeit without the sarcasm and cursing, of course: “Warning: If your patch for a ticket has not been addressed after a week, then join IRC and talk to Peter (westi) or Ryan (rboren). Then like, shit, it will be committed within a day or two (psst, if you catch them at the right time, within several minutes). So not fret, because WordPress developers do care, they just need to know that your patch exists. No guarantee they won’t reject your patch.”
I think for me, my biggest problem is that the issues aren’t being addressed that I talk about and I’m thinking more and more about developing a new alternative. Not just a library which WordPress can use, but an whole another application that works off of WordPress tables. The issue is again, not that the library wouldn’t be developed in any short amount of time, but developing of a whole application, oh god, I can’t imagine that.
It won’t fix the issues I have with Trac and writing patches for the core of WordPress. You see, I don’t write many plugins (nor do I really maintain the plugins I have written) or themes, so I have no visible presence in the community. Therefore, the question I have to ask myself is who am I speaking to? If I’m speaking to the other contributors, then they already know the pains and hurdles, because they’ve lived it. If I’m speaking to the entire community, then they really don’t care, nor do they know who I am exactly.
Who am I, a nobody, to question the Great One and point out the flaws. I think I’m shouting into the wind. The problems I’ve put forward are being ignored by those capable of doing anything about it.
The main problem I have always had was that I don’t think I should have to complain to the core developers that I have a patch which needs to be committed. Then again, I’m happy when they get around to committing the patch. So on one hand, I don’t want to alienate the core developers and have them ignore my patches intentional (which would be a WTF?) and on the other hand I don’t want others who don’t want to deal with bullshit when submitting patches and won’t go the extra mile to get their patch committed.
I still remember my first patch, which was a huge WTF? one for TDWTF. I don’t think it should take three weeks to get a patch into the core. Actually, the only real reason it did get into core was by working with a few other community members and testing the patch and jumping on the core developers back to get it committed. I totally expected that I would submit the patch, some guy would test it and then it would be committed. Nope. You have to jump through hoops to get patches for a lot of the lesser known or lesser issues committed.
I think that is one of my main concerns. Even 18 months and coming on to 2 years, I’m still facing a lot of the same problems. I’ve learned that, if you want to get patches committed, you have to keep on it. However, how many are really going to do that. I don’t want to be an activist for patches. It is hard enough to keep track of all of the patches I’ve created and complain to have them reviewed and committed. Having to go through and find other patches that should be committed. Hell, that shouldn’t be my job.
It is also hard work. Doing something like that would be a full time job. Now, it is that way, because not only do I have to apply the patch, test it, and then fix any issues with the patch, but then the core developer has to look at it, apply the patch, test it, and then commit the patch. It is not an easy process. One of the reasons Trunk is relatively stable 99% of the time. The process is repeated.
I’ve called Matt Mullenweg to task to get more core developers to just do this. That is all they will do, test and commit patches by developers. I think that it is probably a temporary position, it would take a few months tops to finish all of the tickets that have patches that weren’t committed and clean up patches that aren’t worthy of being committed so that they can be.
I don’t think contributing to a project should be one big WTF? after WTF? and I think as my work moves past WordPress as a platform, my involvement will decline to the point where it will disappear altogether. Then again, I use WordPress and it works fine for me.
I’m starting to think past WordPress to Yii and how I can use it. My project task list is being fragmented with browser game projects on one hand and wish list projects on the other. The browser game projects are what I would call, higher priority. I do think I’ll attempt the Yii Blog platform based on the WordPress table structure and code base.
I like the fact that using Yii will decrease the amount of the code base that will need to be maintained. I will most likely be contributing to the Yii code base to patch issues and add additional features as I see them. I think that I’ll be out of the WordPress scene for the next few months, the question is whether I’ll come back. If I can create the Yii clone of WordPress, I don’t think I will because I’ll be spending most of my time working and improving that code base as well as the browser game projects.
If I do leave the WordPress community, then I think the run was an highly educational one, better than I could have received at any school. I learned a lot that I couldn’t exactly focus on while developing code bases and always wanted to. I’ll appreciate the education in documentation and writing test cases. However, I’ve learned what I needed to where I now focus completely on inline documentation and writing test cases while I’m writing code. I no longer have the mind set, “I should do this, but it can be done later.” I now think, “Okay, now for inline documentation and writing the test cases to ensure that the code works.”
I’m writing test cases and inline documentation as I write code and not after. I would be doing so more for WordPress, if the process wasn’t such a WTF? to get test cases committed in the Automattic WordPress Tests repository.
I fear, I will not remember WordPress fondly. I just hope the next generation that join the community will have better experiences than I had. Well, there are those who work on higher priority tickets that have no problem getting patches committed. Then again, those have issues too. (Not to mention the whole WTF? in 2005 and 2006 when Matt and other core developers mentioned that there would be no way in hell inline documentations would be part of core. Good thing their minds were changed on that.)
I make this pledge, if I have a project that has as much support as WordPress, I’ll be damn sure to commit as many patches as I can. If it is impossible for me to do so in any given day or week, then I’ll try to get more people working on the project and give commit access to those who are contributing. Another thing I’ve learned from WordPress is that bullshit should not be uttered when talking about contributing to a project.
Possibly Related Posts:
- WordPress Plugin and Theme Scope
- What I’ve Learned From WordPress
- PHP5 Straw Man Argument
- WordPress 2.7 Changes Class for Plugins
- Web Application Versioning Alpha Release
I think people people who matter know who you are.
Posting a ticket is just one part of the multi-modal communication that happens with all people involved with WordPress, including myself. A ticket without context isn’t useful, and there is enough noise to make good things get lost, as you’ve experienced.
But I think you’ll find being multi-channel enjoyable. All of the developers have direct IMs, talk to them! Keep doing IRC and the mailing lists. Write on your blog, or on wpdevel. (Want an account there?) Champion an idea. It’s part of the process which separates ideas with conviction behind them from ones tossed like bottles in the ocean.
Yeah, I will continue doing that for as long as I’m contributing to WordPress. I just like that when I submitted a bug to another kind-of open source (license is strange BSD-ish with some clauses that were interesting), I got a response in two days letting me know that my “patch” wasn’t acceptable with a forum link to the acceptable solution.
I was impressed. If I hadn’t joined WordPress, then I’ll had expected a quicker response. But you know, when you have a project that doesn’t get a lot of tickets and patches, you can do stuff like answer them in quick enough time.
My problem is that I have difficulty with the legitimacy of my own argument. I understand, sort of, the difficulty when you have many tickets a day created, but I mean, there aren’t that many patches created. A simple query for has-patch pulls up no more than 100. I have difficulty understanding how it would take more than a week going through them all.
I’ve thought about doing just that, going through all of the patches, cleaning them up, resubmitting them, then I think, “Yeah, I just created a lot of work for Ryan and Westi, which is going to take a while for them to go through my patches.”
You know, Ryan has his stuff, Peter has his stuff, so it is great that they take the time to even commit patches as they do. That is great, which is why I don’t want to burden them with the responsibility. I guess that is why I feel like an asshole, is because I feel like I’m betraying them. Here they are doing a great thing and every time I mention this topic I feel like I’m stabbing them in the back and pushing the dagger in deeper, (“Are we not doing enough for you?” they’ll ask. “Yes.” I’ll reply.)
Open source is difficult to meet expectations and WordPress should not be any exception. When you have a community effort, every community effort, no matter the priority of the ticket should be addressed, hopefully in a timely matter. I have a higher level of fortitude, I just hate for someone with less to go through my same experience.
“Warning: If your patch for a ticket has not been addressed after a week, then join IRC and talk to Peter (westi) or Ryan (rboren). Then like, shit, it will be committed within a day or two (psst, if you catch them at the right time, within several minutes). So not fret, because WordPress developers do care, they just need to know that your patch exists. No guarantee they won’t reject your patch.” <—- Needs to be on Trac front page (without the sarcasm and cursing).
If it was, it would go a long way with cutting the crap. If you expect something, then it goes a long way to improving the amount of bullshit you’re going to receive. If I knew back then, that hey, I had to join IRC to get patches committed, then by damn I would have. No, I went from wp-hackers to IRC, after I realized wp-hackers was getting my no where.
Plus, I see it much like complaining, “Why (the hell!) hasn’t my patch been committed (inaudible screaming out of frustration)” or begging, “Please, master, commit my patch, I’ll love you forever (but like a brother, since neither of us are ‘that way’).”
Part of working with any community is working with the community and being a part of the community. Being a team player means playing along with the rules of the team, whether you like them or not. Often those rules are set by the group long before you arrive, and you have to live with them, or slowly, and politely, change them.
You are a valuable part of the WordPress Community and your contributions have been very welcome. Keep the postive attitude and creative energies flowing and keep up the great work, no matter where your path leads.
Yeah, I mean, when I joined the community back in August of 2007, it was an eye opener. It pretty much flipped what I thought open source communities were. The experience has been quite an educational one. I think that is what I enjoy the most. I got to do things with WordPress that I didn’t have time to do with my past projects.
Therefore, the inline documentation and playing around with the Codex has been interesting. When you are building projects from the ground up with no previous foundation, then you sort of lose sight of the small things. Also when you are working alone or with a few people, documentation often takes goes to lower priority verses coding.
However, if my open source projects get to the point where people are submitting patches, I plan on making the point to look over them and apply them as fast as possible.