Also also posted to our new P2 at make.wordpress.org/plugins: what this means for developers. @otto42, @coffee2code, and I go through the changes in detail. They include:

• The new Developers and Support tabs for plugins
• Subscribing to commit emails (Hint: see the Developers tab)
• Following and managing support threads
• How the new support statics are calculated

(Sidebar: We hope to use make.wordpress.org/plugins for announcements and resources for plugin developers. This blog will also move to make.wordpress.org soon. More to come.)

The guidelines still encourage use of “GPLv2 or later,” the same license as WordPress. However, we understand that many open source libraries use other licenses that are nonetheless compatible, such as GPLv2 only, GPLv3, and Apache 2.0.

Now may be a good time for plugin authors to review their plugins to ensure a license is specified. You can add License and License URI headers to readme.txt and the plugin’s headers. (You may also wish to include a copying permission statement.) For example:

License: GPLv2 or later
License URI: http://www.gnu.org/licenses/gpl-2.0.html

You can see this used in the sample readme.txt.

This change brings the guidelines in line with the themes directory, which has for some time accepted GPLv3-compatible code. (Probably a good time to note that Creative Commons licenses are still incompatible with the GPL, and the theme and plugin directories.)

As an experiment we’ve turned on custom headers for the plugin directory. If you’d like to try out this feature:

1. Make a 772×250 pixel jpeg or png. (No animated GIFs. )
2. Check it in to your plugin’s SVN directory with the path assets/banner-772x250.(jpg|png). Note that the assets directory is added to your plugin’s root directory, not trunk.
3. On the next plugin directory refresh (every 15 minutes or so) you should see your image start showing up on the page.

For an example of this in action, check out Hello Dolly, natch. Our goal is to mainly see how people use them, so if you try this out leave comment below with a link to your plugin!

Final note: this is just an experiment, and there is a 98.254% chance the dimensions, placement, and text overlay for this header will change in the future, or the idea might not work at all. But I think it’s a nice toe in the water for letting authors really make their plugin pages shine.

First, on the extend plugin directory, you may notice some new pie chart fun on the stats tab for each plugin. This shows a percentage breakdown of the versions being actively used by that plugin’s users. Only slices greater than 1.0% are shown.

Secondly, since data kept in a box is not very useful, there’s a new API for getting this data. Usage is fairly obvious from just a simple example, which gets the version breakdown of one of my own plugins:

http://api.wordpress.org/stats/plugin/1.0/simple-facebook-connect?callback=demo

The callback parameter is optional, of course, and provided for people who want JSONP usage.

Note that the version data is relatively new, so we don’t have it for all plugins at present. It will get better as reporting continues. For those interested, it’s saving the total counts of the version numbers as reported by the plugin update-checks over the last week. Since the data at present is only from one day, it’s not very accurate.

Lame, we know. Apologies for the hassle.

A standardized taxonomy for organizing plugins and making tags more relevant.
Allow filtering of plugin search results based on version compatibility.
Allow the community to publicly ‘Like’ plugins.
Allow plugin pages to display hash-style URLs from the Read Me file.
UI Improvements for i8n support.
Allow users to publicly review plugins.
Small UI changes to the Plugin Directory
Plugin Adoption Stats
• The formation of a Plugin Security Review Team.

PDC would like for each of you, members of the WordPress community, to look over these ideas and suggest ways of how they could be best implemented. We would like each of these ideas to be sustainable for the long term, meaning they would not create overwhelming work for people contributing to the community or have a negative impact on portions of the community.

To get the ball rolling with one of these ideas, the Plugin Security Review Team, we would like to suggest that responsibilities and obligations of this team be ramped up in stages. Instead of just throwing nearly 11,000 plugins at the team and having the them read every line of code, the team would pro-actively develop solutions that would aid developers in making their own plugin more secure. The Plugin Security Review Team could provide detailed tutorials, presentations, working examples, scanning programs, or any other ideas as they see fit.

The PDC group is open to ideas, suggestions, and help, feel free to contact any of our members: Peter Westwood, Austin Matzko, Dan Cole, Brian Layman, and Michael Torbert. Hopefully with the communities’ help and feedback we will be able to implement all of these ideas.

Note: This only works when the topic is made from the plugins area, using the “Got something to say? Need help? Write a new topic.” link at the bottom of the plugins screen. Topics that are simply manually tagged with the name of the plugin won’t work.

Mods and higher can still change the resolved status on any topic, as always. So you may not be able to see this change easily.

The bug has been fixed, and I’m currently running a brute force script to update all plugins. The script is not very efficient and will take a couple days to finish.

Videos are included using one of two formats.

Shortcode: YouTube, Vimeo, WordPress.com VideoPress

Include a normal looking shortcode anywhere in the readme.txt file.

For YouTube and Vimeo, the shortcode has one unnamed parameter: the video’s URL.

[youtube http://www.youtube.com/watch?v=7EiKx_WSesk]
[vimeo http://vimeo.com/173714]

For WordPress.com VideoPress videos, the shortcode has one unnamed parameter: the video’s ID. The shortcode can be copied from the video’s embed menu.

[wpvideo OO4thna8]

To prevent shortcodes from being parsed, enclose the shortcode in backticks.

`[wpvideo OO4thna8]`

Autolink: YouTube, Vimeo

Include a YouTube or Vimeo URL by itself on its own line in the readme.txt file.

http://www.youtube.com/watch?v=7EiKx_WSesk
http://vimeo.com/173714

Example

http://plugins.svn.wordpress.org/mdawaffe-test/trunk/readme.txt

http://wordpress.org/extend/plugins/mdawaffe-test/

The Validator shows the videos too.

NB: Directly including object/embed HTML into the readme.txt file is not supported; the goal of the readme.txt file is to be human readable.

PS: Videos are not currently supported as replacements for screenshot images in the screenshots section. It’s silly that the Plugins Directory doesn’t yet support that It’s on the todo.