What stats would be useful/helpful/just plain cool to know around your team? This is brainstorming… don’t think about APIs or if/how it could be collected, just throw out ideas in the comments of what information you think it would great to start seeing, say on a monthly basis. List any and all ideas, including stats you are already collecting. I’ll collate all the teams’ ideas and see what the Meta team says we can do.

@coffee2code: As team rep, can you try to rally your group to make suggestions over the coming week? Thanks!

For a list of various licenses, and their compatibility with GPLv2 please read this: http://www.gnu.org/licenses/license-list.html – We know not all of you are lawyers, and thankfully that list makes it easy to check what licenses do and don’t mesh. If something doesn’t have a license, ask the author please, and don’t assume.

The following code bases are popular (which is to say we see submissions with them pretty regularly), but at the time of this post, are not licensed GPL-compatible. None of this means you can’t or shouldn’t use this code on your sites or plugins, just that we can’t host it here if you do.

• Adobe Air
• FancyBox v2 or later
• FancyZoom
• Font Awesome (Edit: Version 3.0 of this is now compatible)
• FLV Player
• Highcharts
• Highslide
• HTML 5 Music Player (Code Base Hero) (only pre version 1.0.1 – you can use this version)
• Imageflow
• Isotope
• JpGraph
• jquery Lightbox
• LightBox2
• MagicToolbox

If there are plugins you find using these (or any non-GPL-Compatible) code bases in their plugin, please email plugins AT wordpress.org and we’ll get in touch with the developer. If you’re the author of one of those code bases, please consider re-releasing your code under a GPLv2 Compatible license! We’d love to be able to host your work here.

Note: It can’t be folks who are already the team reps for other teams, and it should be folks who want to the responsibility (mostly posting weekly updates on team activity to the weekly updates blog). Since there are some newer members of this group it might be nice for one of them to level up and learn the ropes from Scott? Up to you guys. Anyone interested in being a plugin team rep should leave a comment saying as much so people know who they can/should vote for. Voting is open until December 15, and results will be posted here once voting closes.

Vote for Plugin Team Reps

Team Rep Voting Backstory and Detail

Earlier this year, we took a stab at creating a structure for contributor group communication, based on identifying working groups and letting each group elect team reps. All the teams were represented at the community summit at the end of October, which was a huge step forward in recognizing contributors in areas other than core. That said, once all the reps were together, one of the things we talked about was the idea of team reps, responsibilities, and expectations. As a result, it’s time for a bit of an update there.

Moving forward, each contributor group will have two team reps. We’ll have voting to choose team reps every six months. The idea is that one person will take the lead for the first half of the term with the other person acting as a backup rep, then about halfway through, they’ll swap roles. This way, there’s always someone ramping up with more responsibility, and someone who’s been there still around to lend a guiding hand, without anyone having to make too significant of a time commitment. If one new person takes on team rep responsibilities with each election, then it will be a constant cycle of mentoring people into more responsible roles, which is better for the project long-term than keeping all the responsibility in the hands of a few indefinitely.

It’s important to understand that “team rep” is a role that handles communication (namely contributor wrangling and posting weekly updates on the team’s activity and plans); it is not called “team lead” for a reason. While the people elected as team reps will generally come from the pool of folks that people think of as the experienced leaders, remember that the team rep role is designed to change hands regularly. For example, if in 6 months Ipstenu was ready to step back from being the support team rep, that would not reduce her leadership role on the support team, it would just mean she wasn’t responsible for team rep duties anymore.

All teams are participating in this round of elections, but you don’t have to choose all new people as team reps. Though Mark has chosen to step back, you’re welcome to vote for Scott to continue in the role. One thing to be sure of is that anyone you vote for is actually interested in having the team rep responsibilities until the next round of voting in June; this role has a time commitment attached to it, and if a team rep fails to meet that commitment (not posting the weekly updates, for example) they will be removed from the role. To that end, it would probably help for anyone who wants to be in the running to declare their interest in the comments.

Vote for Plugin Team Reps

As part of that original header update, one thing that was added which I always meant to do more with was the addition of a new “assets” directory at the top level of the plugin SVNs. This is an optional directory that sits alongside the /tags and /trunk directories, and was just used to hold the banner images. Creating a place to put plugin assets which didn’t need to be included in the plugin itself simply made sense to me.

It also never made sense to me that the plugin screenshots, which are rarely used by the plugin, needed to be included in the plugin’s ZIP file. Some plugins can use these themselves, certainly, but the majority don’t and it’s just really inflating the size of the plugin to include them.

So, starting today, you can put your screenshot files in the assets directory instead of in the main plugin directory.

A few notes, for the technically minded:

• Screenshot naming conventions have not changed, nor have the readme.txt requirements for their captioning. The naming and behavior is exactly the same, the file can just go into a new place.
• The old way still works too. If you have your screenshots in the plugin’s “stable” directory, then it will find them there just fine.
• Screenshots in the assets directory take precedence over screenshots in the plugin’s directory. If you have both, then the assets directory wins. Of course, there’s really no reason to have both, this is just for backwards compatibility.
• Like everything else in the assets directory, we are serving them through a separate static caching system, and so it may take a few minutes to update when you change them. What this means is that when you put the screenshots in there for the very first time, they may not show up on your page for a few minutes and you’ll just see the captions with no images above them. Please give the proxy some time to retrieve your screenshots and cache them before telling me it’s buggy. It should only take a few minutes.

The ultimate goal, of course, is to reduce the size of the plugin ZIP files being served. By not including the screenshots in the plugin, files are smaller and upgrades are thus speedier for everybody.

In the future, if we have a need for more “directory only” files, I expect them all to be in the assets directory as well, for just this sort of reason.

 **********

There are multiple areas that we should discuss: directory/repo/3rd pty repos/

There are two different points of view to consider: dev/user ux

Users

What should we be thinking about and trying to improve?

Dashboard, search/discovery – updated, popular, directory, updates, what we expose re ratings, compat, confidence/trust, stats/metrics (inspire trust), don’t put ones you already have in the dashboard box

Developers
What are the pain points and/or things we need to make better?

Managing forums, support, getting stats, translations, doing code, collaboration, adoption/abandon process, security, bug tracking, plugin review team, submission process/onboarding, slug/username/link/description

Start a plugin (unreleased development, packaging/releasing) vs host a plugin – what things do you need for each?

Hide ‘recently updated’ in dash box now from rss feed
What things are useful to users when deciding on a plugin?

• # downloads — active installs would be better
• ratings — reviews by trusted sources would be better
• #of individuals working on plugin — active within x time
• support response stats – response time, % responded, % resolved
• # support requests/# installs
• # active users/#support requests
• version compat
• known conflicts
• author-driven metrics. ex total cache, very responsive
• trusted authors program? weighting in search? bump based on core contributions

18 mos/2 year cutoff not shown in search
Complaints: some quality plugins are not maintained (hyperdb 2.5 yrs, automatic); updates in directory sometime don’t go through and updated date gets frozen otto/nacin/adams can’t figure out why this is
repo refresh every minute with locking instead or 15 minutes? talked to barry

need to email when plugin hits the time limit — 2-3 weeks before cutoff date to update readme

send email to everyone who uses a filter when we remove it from core

Action Item: make.wordpress.org/plugins!
plugin directory needs a way to bring people in
provide route to get involved

duck -best practices/education

westi – user: finding good plugins; dev: writing good plugins (security, review)

nacin -

koop – provide every plugin own trace = ton of work. use 3rd party repo, grab readme. let people use their own tools

matt – we said no bc we lose ability to take them over or update it. still want to have everything duped on our svn etc

github integration: we still need the code in our repo. require full sync/every commit? or just port it over each release?
will that move the needle? current setup just doesn’t encourage collaboration.
Action Item: Change language to say it’s ok on the page so it is clear that it’s blessed.
Action Item: dev contact form? based on profile?

Plugin review team/plugin advisory

• security review team volunteers known to nacin
• best plugin devs
• core contribs who also do plugins

Action item: Learn.wordpress.org/plugins
courses, workshops

matt: if you had a friend who wanted to make a plugin, what would you do?
westi: would email links to simple plugins, something less than 20 lines
jane: screencasts of walking through the file and explaining the bits (like viper did)

Make/Learn

plugin review team’s home will be at make
hackers helpful conversations move to make
-hackers archives not a good resource
-stack exchange? no, karma system makes it less appealing for some new people who don’t have time to build up points

What’s going on in the world of plugins? How can we be a resource for this?

• make: monthlyish discussions of plugins (submit for review), get patches/suggestions to deliver to author. becomes a resource also
• start with a blog. initial team: westi. viper. duck, mark jaquith — initial posting group. restrict author status [ed note: since this time, the pluginrepo review group has formed, of Otto, Scott Reilly, Mika/Ipstenu, Duck, Nacin, and Mark Riley]. seed with: inexperienced people – what do we need to post about? focus group, get to-do list of posts to write/get guest authors.

content:

1. simple stuff, intro stuff.

2. review one popular plugin per month, bring in author, hopefully they stay involved

3. posting about things posted elsewhere – good posts about plugins, error-prone posts about plugins
posting once per week
contacting plugin authors
security advisories — if a plugin gets closed until fixed, then after it’s fixed, post about the problem, how we informed them, and the fix. now go your plugin for similar issues.
where to put that: make/a-mess (heh)
Action: create blog, add authors , westi talk viper, posting calendar, pick 1st plugin and contact author. write first post.

———————

More Action Items:
1. move to usage base/position instead of downloads
position is objective/harder to game
this is separate from ranking (tax matching + downloads would be tax+position)

2. banners. custom headers for plugin pages, icon, moor graphical elements. can expose those all over. chrome web store good example, itunes store
exclude images in zip files? maybe just exclude custom header [ed note: this is active now]

3/4/5. remove extra radio buttons from search page, search only by relevance

 **********

So those are the notes! The discussion at dotorgplugins.wordpress.com can hopefully feed into some of these goals (many are the same, I think) and we can finally put together the broader plugins contributor group that we imagined but never got around to cultivating.

Layout

First, let’s briefly go over the layout of your plugin in the SVN repository. There’s three directories created by default, and an optional fourth one that you can create yourself.

Trunk: The /trunk directory is where your plugin code should live. The trunk can be considered to be the latest and greatest code. It’s the development version. Hopefully, the code in trunk should always be working code, but it may be buggy from time to time because it’s not necessarily the “stable” version. For simple plugins, the trunk may be the only version of the code that exists, and that’s fine as well.

Tags: The /tags directory is where you can put versions of the plugin at some specific point in time. Usually, you’ll use version numbers for the subdirectories here. So version 1.0 of the plugin would be in /tags/1.0, version 1.1 would be in /tags/1.1, and so forth. Again, not every plugin uses tags for versioning.

Branches: The /branches directory is a place that you can use to store branches of the plugin. Perhaps versions that are in development, or test code, etc. The WordPress.org system does not use the branches directory for anything at all, it’s considered to be strictly for developers to use as they need it.

Assets: The last optional directory doesn’t exist by default. You can create it yourself though. Just make a directory called “assets” next to those other three directories. Assets currently only has one use, which is to store the banner image to be displayed on your plugin page. We may use it for more things in the future. For now, you can just make an image, name it banner-772×250.png or jpg, and put it in there. Easy.

Parsing the plugin information

All plugins contain a main PHP file, and almost all plugins have a readme.txt file as well. The readme.txt file is intended to be written using a subset of markdown.  The example readme.txt explains most everything pretty well, but there’s a few little tidbits that are worth pointing out.

First is the concept of the “Stable Tag”. When WordPress.org parses the readme.txt, the very first thing it does is to look at the readme.txt in the /trunk directory, and then read that “Stable Tag” line. If the Stable Tag is missing, or is set to “trunk”, then the version of the plugin in /trunk is considered to be the stable version. If the Stable Tag is set to anything else, then it will go and look in /tags/ for the referenced version. So a Stable Tag of “1.2.3″ will make it look for /tags/1.2.3/.

Important bit: Everything else is read from this new location. If the Stable Tag is 1.2.3 and /tags/1.2.3/ exists, then nothing in trunk will be read any further for parsing by any part of the system. If you try to change the description of the plugin in /trunk/readme.txt, and Stable Tag isn’t trunk, then your changes won’t do anything on your plugin page. Everything comes from the readme.txt in the file being pointed to by the Stable Tag.

Now let’s get to the plugin information itself. The WordPress.org directory reads the main plugin PHP file to get things like the Name of the plugin, the Plugin URI, and most importantly, the version number. On the plugin page, you’ll see the download button which reads “Download Version 1.2.3″ or similar. That version number comes from the plugin’s main PHP file.

Some people get this versoning confused due to the tags system. The Stable Tag points to a subdirectory in the /tags directory. But the version of the plugin is not actually that, it’s the version that is listed in the plugin’s PHP file itself. If you have changed Stable Tag to 1.4 and the plugin still says 1.3 in the PHP file, then the version listed will be 1.3.

Readme.txt pieces that everybody gets wrong

Back to the readme.txt. There’s a line called “Contributors”. This line has always been expected to be WordPress.org usernames only. WordPress reads those, gets information about that user, gets their gravatar, name, etc, and makes the authors listing. If you put anything here that’s not a WordPress.org username, then it doesn’t look nearly as good. No picture, no link, just text.

Other information in the readme.txt is read and used at various points on the Plugin listing. The Donate link makes a “Donate to this plugin” link in the sidebar. The “Requires at least” and “Tested up to” fields are used for compatibility checking, even on the WordPress installation itself. Few people get these wrong.

One thing a lot of people get wrong is this line:
“Here is a short description of the plugin.  This should be no more than 150 characters.  No markup here.”

That bit is serious, and you should read it again. That one line people get wrong more often than anything else. That line of text is the single line description of the plugin which shows up in big letters right under the plugin name, and if it’s longer than 150 characters, it gets cutoff and makes your plugin page look silly.

Markdown allows for easy linking in your readme.txt as well. Just write like this to link a word to a URL:

[WordPress](http://wordpress.org)

Videos can be put into your readme.txt too. A YouTube or Vimeo link on a line by itself will be auto-embedded. It’s also possible to embed videos hosted on VideoPress using the wpvideo shortcode. More on that topic here: http://wpdevel.wordpress.com/2010/02/20/plugins-can-now-include-videos-in-their-readme-txt-files/

Summary

I don’t think I covered everything, but hopefully that will explain some of the more obscure features of the directory and how it works. If it reduces the number of times people send me the question “why didn’t my version change show up in the directory”, then I think this post was time well spent.

What are endpoints?

Using endpoints allows you to easily create rewrite rules to catch the normal WordPress URLs, but with a little extra at the end. For example, you could use an endpoint to match all post URLs followed by “gallery” and display all of the images used in a post, e.g. http://example.com/my-fantastic-post/gallery/.

A simple case like this is relatively easy to achieve with your own custom rewrite rules. However, the power of endpoints shines for more complex situations. What if you wanted to recognise URLs for posts and pages ending with “gallery”? What if you wanted to be able to catch multiple different archive URLs, e.g. day, month, year and category archives, with “xml” appended in order to output an XML representation of the archive? For these situations endpoints are very useful as they allow you to add a string to the end of multiple rewrite structures with a single function call.

How to use them

There is one function for interacting with endpoints: add_rewrite_endpoint(). It takes two parameters $name and $places.

$name is a string and is, wait for it… the name of the endpoint. $name is what is used in the URL and is the name of the query variable that the endpoint URL will be rewritten to. For example, an endpoint named “print” added to post permalinks would use a URL like http://example.com/my-awesome-post/print/.

$places is an integer value which represents the locations (places) to which the endpoint will be added, e.g. posts, pages or year achives. To understand $places you need to learn about the endpoint mask constants.

In wp-includes/rewrite.php (browse wp-includes/rewrite.php on Trac) a number of constants are defined all with names beginning with “EP_”:

define('EP_NONE', 0);        // 0000000000000
define('EP_PERMALINK', 1);   // 0000000000001
define('EP_ATTACHMENT', 2);  // 0000000000010
define('EP_DATE', 4);        // 0000000000100
define('EP_YEAR', 8);        // 0000000001000
// ...
define('EP_PAGES', 4096);    // 1000000000000
define('EP_ALL', 8191);      // 1111111111111

These are the endpoint masks which describe sets of URLs; post permalinks are described by EP_PERMALINK, year archives are EP_YEAR, etc. They should be thought of in terms of their binary values (see the comment I’ve added to the end of each line). Every EP_* mask, except for EP_ALL, is a different power of two and so has a different bit set to one. This allows us to build up combinations of endpoint masks by using the bitwise OR operator:

// all posts or attachments
EP_PERMALINK | EP_ATTACHMENT // 0000000000011

// all full dates (yyyy/mm/dd), years or pages
EP_DATE | EP_YEAR | EP_PAGES // 1000000001100

$places should also be thought of as a binary number. It should be set to one of the EP_* constants or a combination of them using the bitwise OR operator. If we wanted to add our endpoint to all post permalinks we would use EP_PERMALINK. For both posts and pages: EP_PERMALINK | EP_PAGES. For posts, pages, and categories: EP_PERMALINK | EP_PAGES | EP_CATEGORIES. There is also a special value to add an endpoint to all URLs that support endpoints: EP_ALL.

NB: The values of the EP_* constants are not guaranteed to stay the same which is why you must say $places = EP_PERMALINK and not $places = 2. This is particularly important for EP_ALL which will change every time a new endpoint mask is added.

It’s time to put this information into practise. The running example will be a plugin that adds JSON representations of our content using a new rewrite endpoint called “json”. So, the goal is to get URLs such as http://example.com/about/json/ to return a JSON response that gives information about the “about” page. To add the “json” endpoint to post and page rewrite structures:

add_rewrite_endpoint( 'json', EP_PERMALINK | EP_PAGES );

This is called in a function hooked into the init action:

function makeplugins_add_json_endpoint() {
    add_rewrite_endpoint( 'json', EP_PERMALINK | EP_PAGES );
}
add_action( 'init', 'makeplugins_add_json_endpoint' );

Now we want to act on requests for JSON content. This is done by hooking into template_redirect. We want to detect appropriate requests and include our custom template for serving up posts and pages in JSON format:

function makeplugins_json_template_redirect() {
    global $wp_query;

    // if this is not a request for json or a singular object then bail
    if ( ! isset( $wp_query->query_vars['json'] ) || ! is_singular() )
        return;

    // include custom template
    include dirname( __FILE__ ) . '/json-template.php';
    exit;
}
add_action( 'template_redirect', 'makeplugins_json_template_redirect' );

And we’re done. For a full example plugin see https://gist.github.com/2891111.

How do they work?

The best way to understand how anything works is to take a look at the source, so let’s do that. Endpoints are added with the add_rewrite_endpoint() function in wp-includes/rewrite.php:

/**
 * Add an endpoint, like /trackback/.
 *
 * Adding an endpoint creates extra rewrite rules for each of the matching
 * places specified by the provided bitmask. For example:
 *
 * <code>
 * add_rewrite_endpoint( 'json', EP_PERMALINK | EP_PAGES );
 * </code>
 *
 * will add a new rewrite rule ending with "json(/(.*))?/?$" for every permastruct
 * that describes a permalink (post) or page. This is rewritten to "json=$match"
 * where $match is the part of the URL matched by the endpoint regex (e.g. "foo" in
 * "/json/foo/").
 *
 * A new query var with the same name as the endpoint will also be created.
 *
 * When specifying $places ensure that you are using the EP_* constants (or a
 * combination of them using the bitwise OR operator) as their values are not
 * guaranteed to remain static (especially EP_ALL).
 *
 * Be sure to flush the rewrite rules - flush_rewrite_rules() - when your plugin gets
 * activated and deactivated.
 *
 * @since 2.1.0
 * @see WP_Rewrite::add_endpoint()
 * @global object $wp_rewrite
 *
 * @param string $name Name of the endpoint.
 * @param int $places Endpoint mask describing the places the endpoint should be added.
 */
function add_rewrite_endpoint( $name, $places ) {
      global $wp_rewrite;
      $wp_rewrite->add_endpoint( $name, $places );
}

So this is just a wrapper for the add_endpoint() method of the WP_Rewrite class. Although the (excellent!) documentation gives us some clues as to what it does we’ll have to dig deeper to find the how:

/**
 * Add an endpoint, like /trackback/.
 *
 * See {@link add_rewrite_endpoint()} for full documentation.
 *
 * @see add_rewrite_endpoint()
 * @since 2.1.0
 * @access public
 * @uses WP::add_query_var()
 *
 * @param string $name Name of the endpoint.
 * @param int $places Endpoint mask describing the places the endpoint should be added.
 */
function add_endpoint($name, $places) {
    global $wp;
    $this->endpoints[] = array ( $places, $name );
    $wp->add_query_var($name);
}

Another very short and simple function. All it does is append the two parameters passed to it to the private $endpoints property of the WP_Rewrite class and also add a new query variable using WP::add_query_var().

Okay, so that’s still not useful for a full understanding of endpoints. All we know is that the arguments you pass to add_rewrite_endpoint() are stored in a private array of the $wp_rewrite global. To find out more we’ll have to search wp-includes/rewrite.php for “>endpoints” (i.e. code accessing the WP_Rewrite::$endpoints property). There are only three references to this: WP_Rewrite::add_endpoint() we have seen, WP_Rewrite::init() is boring (initialising the array), and the third is WP_Rewrite::generate_rewrite_rules():

$ep_query_append = array ();
foreach ( (array) $this->endpoints as $endpoint) {
    //match everything after the endpoint name, but allow for nothing to appear there
    $epmatch = $endpoint[1] . '(/(.*))?/?$';
    //this will be appended on to the rest of the query for each dir
    $epquery = '&' . $endpoint[1] . '=';
    $ep_query_append[$epmatch] = array ( $endpoint[0], $epquery );
}

// ... a lot of code removed ...

foreach ( (array) $ep_query_append as $regex => $ep) {
    //add the endpoints on if the mask fits
    if ( $ep[0] & $ep_mask || $ep[0] & $ep_mask_specific )
        $rewrite[$match . $regex] = $index . '?' . $query . $ep[1] . $this->preg_index($num_toks + 2);
}

In the code above the first foreach is looping through the defined endpoints and building a new array called $ep_query_append. This new array uses regular expressions that match a specific endpoint as keys and the values are the endpoint $places and $epquery which is a partial query string to append to a full query. So, for our JSON endpoint example we would get:

$ep_query_append[ 'json(/(.*))?/?$' ] = array( EP_PERMALINK | EP_PAGES, '&json=' );

The second loop generates the final rewrite rules for our endpoint. It loops through $ep_query_append checking if the current permastructure being generated has an endpoint mask, $ep_mask, that matches any of the endpoints. If the bitwise AND produces a non-zero value then there’s a match and the endpoint rewrite rules should be added to this permastructure.

For our JSON example, if WP_Rewrite::generate_rewrites_rules() has been called for the posts permalink structure then $ep_mask = EP_PERMALINK and $ep[0] = EP_PERMALINK | EP_PAGES. The bitwise AND of these values produces 1, therefore a new entry is added to $rewrite. Assuming that the post permalink structure is “/%postname%/” it would look something like:

$rewrite[ '([^/]+)/json(/(.*))?/?$' ] = 'index.php?name=$1&json=$3'

This is the final rewrite rule for our JSON endpoint applied to post permalinks. It matches a request for “post-slug/json/” and sets up the appropriate query variables “name” and “json”. Our template_redirect hook now picks this up and produces the required response.

And you made it to the end, phew! Time for a drink…

Conclusion

I hope that after all of that you understand how to use endpoints and how they work. If you have any questions please don’t hesitate to ask them in the comments. Always remember that the best way to understand a function is to look at the source and follow its execution.

Design refresh for plugin pages.

We’re glad to see so many of you use the plugin headers we launched in December. Now, we’ve provided a further refresh. We’ve made authors much more prominent and with bigger Gravatars and better placement, and cleaned up the styles for the ratings, support, and compatibility sections. There’s a great before-after shot in the announcement post.

Support is now integrated into your plugin page.

In the past, creating new support topics for plugins has been special, and not in a particularly good way. It had this specialness by overloading the tags in the support forums to indicate that a thread was about a particular plugin. No longer. We’ve promoted plugins up a notch and given them their own area.

So now, on your plugin pages, you’ll see a “Support” menu in the header, and you’ll see the topics for that plugin in that tab. You’ll also find a submission form at the bottom of that tab, to add new support topics specifically for your plugin. Topics about plugins made from here get a special sidebar with links to the plugin, to the plugin’s FAQ page, and to the list of Support Threads for that plugin.

While this section looks like it’s on the Plugin’s page, it’s not really. These support threads are actually in the same place they’ve always been, in the Support forums. What you’re seeing as far as the look and feel of that view of the support forums is just some clever trickery on our part.

Akismet, for example, will have it’s “support forums” at this URL: http://wordpress.org/support/plugin/akismet.

How to follow support threads for your plugins.

You may want to take advantage of this by subscribing to the RSS feed for your plugin: http://wordpress.org/support/rss/plugin/akismet. Email subscriptions are not available for these yet, but we will be adding them this week.

For plugin authors who have been using them, the old convenience views of plugin-committers and plugin-contributors are still there as well. (Committers are managed in on the Admin tab, while contributors are taken from readme.txt.) We’ll be exposing these links in more places, but you can use them with URLs similar to the following: http://wordpress.org/support/view/plugin-committer/Otto42 http://wordpress.org/support/view/plugin-contributor/Otto42. (RSS feeds exist for these as well.)

Support statistics are now shown to users.

You’ll notice a new area on the plugin page sidebar showing information about how many topics there are for your plugin, and how many of them have been marked as resolved. These are handy for users to see if questions are likely to get a response.

You have had the ability to mark plugin support threads as resolved for some time now. It’s now really easy — you can mark a thread as resolved while making a post with a simple checkbox. Note that the user who opened the thread can also mark threads as resolved and unresolved. Threads that are marked “Not a support question,” such as suggestions or feedback, are not counted toward these stats and do not need to be marked resolved.

Statistics will be based on a rolling two-month period, based on when the thread was opened. Currently, the statistics cover threads opened in the last two weeks, and will continue to increase until it reaches two months, to allow you some time to resolve existing threads.

Managing your forum with sticky topics.

You can now make threads “sticky”  threads to the top of your plugin’s support forum, just like the other forums on WordPress.org. (You’ll find a link “Stick topic to this plugin’s support forum” in the sidebar.) Threads marked as sticky will show at the top of your plugin’s Support tab. (They won’t be sticky on the regular forums.) We hope you find this handy for posting FAQs or other important information about your plugin.

A new section for developers.

Every plugin now has a Developers tab where you can find links for browsing the code in Subversion, the development log, and development versions. Here, you can now subscribe to get an email whenever a commit is made to a plugin repository, even if it isn’t yours. (You will of course continue to receive commits for your own plugins.)

Favoriting plugins.

As I’m sure you’ve now seen, plugins can now be favorited by logged-in users — and have been more than 2,000 times since we soft-launched this feature earlier in the week! When you favorite a plugin, it gets added to your profile. And if you’ve also rated that plugin, your rating gets shown.

We expect to do a lot more with all of this in the future — favorites, plugins, support, and profiles. Until next time, we hope you enjoy these changes as much as we do!

— written by Nacin, Otto, and Scott

As our page on wordpress.org says, “We see this most frequently with spammy sites distributing plugins and themes with malware in them, which you probably don’t want to be associated with.”