It is that time of the year again. We will be holding another WordPress Plugin Competition. The Plugin Competitions held in the past years have generated a tremendous amount of interest in WordPress and our entrants have come up with fantastic plugins such as WP Comment Remix, Manageable, Who Sees Ads and of course OneClick in addition to hundreds of others that were voted upon by readers like you. We have distributed thousands of dollars in prizes, helped popularize hundreds of plugins and have even prompted the adoption of various peices of code into the WordPress core. With WordPress 2.8 around the bend and the Google Summer of Code, I have very high hopes for this year. Here are some links for those that have not yet participated or looked into our past WordPress Plugin Competitions:
- WordPress Plugin Competition 2008 Winners
- WordPress Plugin Competition 2007 Winners
- WordPress Plugin Competition 2005 Winners
- WordPress Plugin Competition Blog
- List of prizes from last year
We are looking for donations (via Paypal) towards the final purse for this years’ competition. WeblogToolsCollection pledges $1000 towards the final prizes.
We will not be removing the past entries from the Plugin Competition blog. Much of the rules and expectations remain the same. They are listed below. The plugins will be judged by a panel of at least three judges.
Some relevant details:
- All code must be GPL compatible
- All Plugin must be compatible with the latest official release available when the competition ends
- All Plugins have to be secure and use secure coding methods. This is very important.
- Plugins must be made available through the WordPress Extend pages
- Plugins must be officially submitted through email and announced and discussed on the Plugin Competition Blog. More details on submissions will be added in the last month of the competition. Release of plugin after competition start does not mean submission. You can submit your plugin way after its release to work out bugs etc.
- Running time for competition = 3 months starting the 1st of May till the 31st of July
- True WordPress plugins only. No manual modifications can be required of users. No editing of core files allowed.
- You cannot submit plugins that have been released already. Modification or re-use of existing code to achieve completely new functionality allowed.
- All plugins require documentation as in the WordPress Extend pages.
- Preliminary support for the plugin has to be provided to the public.
- Any and all prizes/controversies/issues will be judged and decided at my sole discretion.
- Past winners are not eligible for this competition.
Please let us know if we can help answer any questions or if you would like to donate some money to the competition prizes. Your help will go a long way.
YAY
A few days ago I was exactly thinking about this competition, wondering when/if 2009 edition would start. Best moment in the plugin year.
One question: “Past winners are not eligible for this competition”. Am I eligible or not? 🙂 (got 4th spot in 2007)
I hate to lose you as a participant but would love to gain you as a judge! 😛
Count me in as a judge then 🙂
You got it. Thank you!
Awesome! Looking forward to it!
Me too! I couldn’t live without some of the plugins I currently use.
Do you guys have a date this will start yet? Can’t wait to start working on this.
Running time for competition = 3 months starting the 1st of May till the 31st of July
=== You cannot submit plugins that have been released already. === this sentence is not very understandable for non-english spoken developers = must the plugin be a very new one ?
You can only submit plugins that have been written for this competition and have not been released publicly before the start of the competition.
So I should not of released my plug-in until the competition was ready!!
I would like to be able enter.
I feel that it would be fairer if this was open to any plug-in release after the close of the last competition. Not just if your project just happened to fall into the right 3 month slot.
paul
“publicly” is – on the wp plugin repository – or also as alpha on our own dev site –
In any case, it’s a shame when all we know the long road of development and testing…
Best regards
Since we cannot monitor everything and will have no clue if you released your plugin on your blog and then promptly removed it, this rule can only be enforced if it was released on the WP Plugin Repository. However, as far as the rule stands, it says that only new code will be eligible.
Hi,
sorry to say that, but I think this is a bad rule.
I just released version 1.0 of a plugin (on my website and in the WP Plugin Directory) a week ago (on the 21st).
Now this means, that I won’t be able to participate in the competition because I released 9 days to early, (and although the plugin development took (and takes) the same hard work for bugfixing, support and so on…)
My suggestion is to allow all plugin released since the beginning of this year (as “2009” is the year in the plugin competition title) to participate.
Best wishes!
Tobias
We appreciate your feedback Tobias and understand your predicament but a rule is not for one but for everyone. Allowing older plugins to enter the contest might take away from the flurry of new activity in plugin development and WordPress brainstorming that surrounds every Plugin Competition.
Of course I understand that this rule is for everyone and afterall it’s your competition so you are free to make the rules.
But I don’t see the decrease in activity towards the creation of new plugins, just because you allow those plugins released in past few weeks to participate.
In fact those developers had to go through the same development process and should be allowed to get some attention through the competition. It just doesn’t seem fair to “punish” those that released plugins already in the weeks before the competition. And wouldn’t more participants lead to even more attention for the competition, even better plugins and a way better WordPress?
(I’m not saying this because I’m affected by the rule or because I’m mad or anything like that! I really like and support the idea of the competition!)
Tobias
But you do realize how difficult “past few weeks” would be to enforce considering the above dialog and allowance from the beginning of the year or since the last competition is going to take away too much from new development.
Yes, I know. Unfortunately “past few weeks” is hard to define.
It just somehow hurts to see some good plugin ideas “wasted” (from the point of view of the developer, because the won’t get as much of the attention they might be worthy of).
Of course they would not get that attention if there wouldn’t be a competition in the first place, so I guess that’s life then 🙂
Tobias
Hello Mark,
The rule can be easily relaxed to application that have not passed 1,000 downloads, which are probably quite new and could use the exposure.
We would rather not implement any such arbitrary rule.
Awesome to see you’re doing this again Mark. Last year brought us some great plugins which WP Comment Remix happened to be my favorite. Looking forward to seeing what happens this year and the creativity shown by plugin authors. If things go well for WPTavern throughout next month, I plan on contributing to the prize pool a little bit 🙂
Have i to be of age to partecipate?
As long as you can write code and have a Paypal account for the winnings (if you do win), we have no age limits in mind. If you are underage, you have to have your parents’ permission to participate.
“Past winners are not eligible”? Bummer.
Could i partecipate with a buddypress set of plugins ?
As long as they work on a fresh WordPress install, you can participate.
they work on wordpress if buddypress is installed,
a plugin for bp means a plugin for mu
Is it okay to create the Plugin at WordPress extend, but not release it before the end of the competition? I just want to use the svn for delopment.
Yes of course, as long as you follow all the rules of WordPress extend and of the competition and its submission requirements.
Is there a rule regarding multiple submissions?
Multiple submissions are welcome!
I am excited to see what comes from this year’s competition. It always amazes me some of the new ideas that these competitions produce! Good luck to you all.
Ed
Hey,
Really excited about the competition this year, had a plugin in mind for a while and this provides just the motivation needed to start on it.
One question, what’s happening with the competition site, the rules page is 404’ing aswell as many others and there doesn’t seem to be anything happening to indicate any life in the competition?
Cheers
DyasonHat
Very cool, Hope to hear more about it in the coming weeks. So I am to understand that you will start accepting submissions toward the end of the competition?
By when should we post to the pluginblog? Is it okay to do that right now, or should we wait until the last couple weeks when we send the emails?
post now. The earlier, the more visibility and chance that someone gives feedback you get.
Okay. It’s already starting to gain some momentum since it made it into the WordPress repository late last night. Once I fix a couple of quick bugs, I’ll go and write up a post over there.
Quick question: when you say “All plugins require documentation as in the WordPress Extend pages”, do you mean inline documentation of the code itself, or do you mean a README file and such, as discussed on the WordPress Extend page you’re linking to? (If it’s the latter, then I guess any plugin which is accepted for the plugin repository automatically qualifies, since that’s a pre-requisite for the plugin repository?)
Thanks!
Readme files and such.
I’ll go a step further: readme files and such, *and* code documentation. Definitely. As a judge, I will definitely pour my wrath on poorly documented code 🙂
(Mark, I’ll be allowed to do so, right?:)
Code documentation is not required as part of the requirements for the competition. However, the judges have complete freedom to use their own yardsticks to measure and judge the presented code.
I leave the judging to the judges but set limits on what disqualifies entries. A plugin without inline code documentation will not be disqualified while one without a readme file will be.
🙂
So, just to be clear: the official rule says simply to provide end user documentation, while an official judge has just indicated he plans to pour his wrath on anything that doesn’t also provide code documentation.
Is there some way to make this all a bit more official, so that plugin authors aren’t left trying to second guess whether they should be writing for actual users, official rules, or special de facto rules created by the individual preferences of particular judges?
Thanks!
Greg, each judge will have their own criteria. One might be more intransigent regarding phrasing in the admin panel, while one will pay more attention to the general usability.
As a plugin user, I never run one that has poorly commented code. Here I’m not asking for superb PHPdoc style comments, just the basic stuff that will explain what functions are for, etc..
Howdy Ozh,
Yep, point taken on the value of commenting from the standpoint of a plugin user.
From the standpoint of a contest participant, though, it would be nice if the actual judging criteria that make the difference between a “good” plugin and a “bad” plugin were put on the table for everyone to see. Otherwise, plugin authors quite literally have no idea at all how their work is going to be judged and thus whether it is even worth the bother to participate.
(And while one might assume that sensible phrasing and good usability are no-brainers, code commenting is actually not at all analogous to phrasing in the admin panel or general usability: it is guaranteed that all users of a plugin experience the latter two, while only a minority ever check to see how code is commented.)
As of this moment, the only people who have any idea that code commenting will be weighted as hugely significant are you and the minority of folks who scroll through acres of comments just in case an important feature of the contest might be revealed there. To me, hiding such an important fact about judging deep in the comments on this post seems disrespectful to hard-working plugin coders everywhere.
And for myself — one of those fortunate few who discovered this hidden judging criterion — I wonder just what other hidden criteria might be waiting to bite me in the butt.
Just asking for transparency, that’s all. Some folks might say that knowing the criteria on which a contest is going to be judged is a bit like knowing what a plugin function does. Is that unreasonable? Am I just being silly for wanting to know whether there are any other hidden judging criteria?
Greg,
The thing is, commenting code is by no means a competition rule. This is just good practice. Like, using the right function for the right task, or paying attention to extra SQL queries, or paying attention to security risks if applicable, etc…
From a user point of view, commented code is cool, at least for the few that will read the source. But from a contestant, ie a coder, this totally goes without saying!
You can’t ask for transparency about everything because, well, it’s just not possible. Commented code, no useless extra query, no typo in the doc, no ugly image, no blink tag, no white text on light grey background… If it’s not stated in the rule, it’s either common sense or good practice.
As for me specifically, read this if you want to know what kind of stuff I care about:
Hi Ozh,
Was there supposed to be a link at the end of your comment?
You’ve said I can’t ask for transparency about everything, because it’s just not possible.
However, I didn’t ask for transparency about everything; I asked about a specific characteristic which is apparently not an official requirement yet which if absent will result in your “pouring wrath”. “Pouring wrath” sounds like an entry-killer to me, the sort of thing that would have made it in retrospect a complete waste of time for a plugin author to have entered the contest, if they didn’t know about that unstated criterion in advance.
Nor, incidentally, did I dispute that commenting code is good practice — but lots of programmers comment their code and then strip those comments prior to distribution. So the fact that it’s good practice from a programmer’s perspective doesn’t quite make it something that “totally goes without saying”, does it?
Anyway, I feel like I’m banging my head against a brick wall. How about just actually saying it out in the open for all plugin authors to know about, rather than hiding these things in blog post comments — or, worse, just assuming that everyone who matters thinks the same way and so they ought to be able to figure it all out for themselves?
Oops, link missing indeed. It was supposed to be this: http://planetozh.com/blog/2008.....-part-one/
I’ll probably post something on my blog with a few hints and advices about what to expect from me as a judge.
Thanks for the links to the previous years winners, some useful plugins in there. Going to browse and see which ones would be useful. Also looking forward to see who wins this year ! 🙂