WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Tagged: 3.org Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 8:56 pm on August 26, 2010 Permalink
    Tags: 3.org, ,   

    What do core contributors need to know? 

    I’ll be working on an outline for the core contributor handbook in the coming weeks, so I figured I would start a brainstorming session here. Some potential questions to ask yourself:

    • What do core contributors need to know?
    • What would have been great to know when you first started getting involved?
    • What resources (such as pages on the Codex) have you found useful?
    • What do people (including/especially non-contributors) need to know about the development process/cycle/philosophies?
     
    • Ozh 9:05 pm on August 26, 2010 Permalink | Log in to Reply

      Adam’s http://adambrown.info/p/wp_hooks/ is pretty hot

      Emphasis could be made on the Codex, too. I started coding plugins before there was a Codex, which then was pretty empty at its beginning so I never really used it. It’s just recently that I’ve discovered it again, and found it very very useful.

      • Andrew Nacin 9:37 pm on August 26, 2010 Permalink | Log in to Reply

        This comment is arguably better for http://wpdevel.wordpress.com/2010/08/26/api-status-check/. I’ve actually reached out to Adam with regards to his hooks DB, as we hope to integrate a hooks reference as part of the API reference.

      • Brian Layman 9:52 pm on August 26, 2010 Permalink | Log in to Reply

        Unfortunately Adam’s site is causing loads of extra work now as it is still big in Google but his automated code has identified many actions and filters as removed due to fine tweaking. I see people asking about it on wp-hackers and you and I chatted about it one of the reports on it Andrew.

        • Andrew Nacin 9:53 pm on August 26, 2010 Permalink | Log in to Reply

          Indeed, which is partly why it would be helpful to have a similar automated reference that is official and more complete. (And can be properly vetted by core folks.)

    • John James Jacoby 9:07 pm on August 26, 2010 Permalink | Log in to Reply

      How to use trac the WordPress way (keywords, tags, etc…)
      What is SVN? What do checkout/update/commit really mean and who can do that and why?
      How create a diff/patch, and how to attach a diff/patch to a trac ticket.
      General blog/chat/trac etiquette and community expectations.
      WordPress coding standards is a helpful codex page.

      There are probably more, but these are my few to start.

    • zippykid 9:09 pm on August 26, 2010 Permalink | Log in to Reply

      1. just a quick reminder on how to search the archives :).
      2. history of some decisions (see #1)
      3. coding standards
      4. contributing etiquette
      5. Triage process

      • Jacob Santos 9:59 pm on August 26, 2010 Permalink | Log in to Reply

        I think #2 is a good idea. There are a few areas that are/were asked repeatedly on the wp-hackers mailing list that would be good to just link to. It wouldn’t mean it is set in stone, but it would provide some reasoning for people on where to leave off when continuing discussions.

    • Kenny Younger 9:22 pm on August 26, 2010 Permalink | Log in to Reply

      I always knew the trac mailing list was available, but it wasn’t until recently that I started subscribing to it that I started to really appreciate the workflow in trac – mainly because it’s now literally at my fingertips (email on my phone).

      I just have gmail filter it off into its own label, so it doesn’t clutter my inbox (I actually do this for all the lists). One of the huge benefits is that I can drop into that label and then very quickly see what tickets are getting heavy commenting/changes. Plus I can star items that I feel I want to pay attention to more so than others.

      Another added benefit: quick searching from my phone for a particular ticket’s history.

      • Andrew Nacin 9:39 pm on August 26, 2010 Permalink | Log in to Reply

        My current workflow is very similar to this, though long ago I spun that label off into its own inbox. Even when I’m at my computer, I often use Gmail search to find tickets.

        Talking about different ways to absorb the firehoses of information, if you are so inclined, is a good idea.

    • Jacob Santos 9:31 pm on August 26, 2010 Permalink | Log in to Reply

      Requirements for patches. Adding / Modifying inline documentation and changing existing documentation when changing requirements. Writing Unit Tests. Expectations of the time for patches to get committed. What to do when there isn’t any feedback? What to do when patches don’t meet expectations.

      What it means when someone from Automattic doesn’t like your patch and therefore doesn’t gain traction. Who’s who at Automattic and WordPress core community that might need to be looked for and debated for certain patches to get in.

      • Andrew Nacin 9:36 pm on August 26, 2010 Permalink | Log in to Reply

        s/Automattic/WordPress core team/. That said, a who’s who is important, especially given the number of committers, contributors, and those who triage.

        • Jacob Santos 9:52 pm on August 26, 2010 Permalink | Log in to Reply

          No, I mean Automattic. They have just as much power, most of the time, as core commit team with what goes into WordPress. There are people at Automattic who have certain areas of expertise and core commit team has historically relied on their opinion over that of the core contributor community members.

          It is helpful to know who these people are without having to go to automattic.com web site and checking. Partly because the name(s) on the web site do not always translate to Trac.

        • Jacob Santos 10:01 pm on August 26, 2010 Permalink | Log in to Reply

          Yes, the first Automattic should have read WordPress core team. The second should have read Automattic and WordPress core team and WordPress core community.

        • Andrew Nacin 10:02 pm on August 26, 2010 Permalink | Log in to Reply

          That works for me.

      • Andrew Nacin 9:39 pm on August 26, 2010 Permalink | Log in to Reply

        Also, I really like your thoughts on patch requirements, expectations. Thanks!

    • JohnONolan 9:35 pm on August 26, 2010 Permalink | Log in to Reply

      Probably need a mini section for designers / front end developers. We can title the section “for dummies” – as Nacin will attest to by the number of questions that I asked him in the early days :)

    • Andrew Nacin 9:35 pm on August 26, 2010 Permalink | Log in to Reply

      Random quick hits:

      • Jacob Santos 9:53 pm on August 26, 2010 Permalink | Log in to Reply

        Inline documentation is found at http://codex.wordpress.org/Inline_Documentation

      • Matt 10:34 pm on August 26, 2010 Permalink | Log in to Reply

        • Andrew Nacin 2:09 am on August 27, 2010 Permalink | Log in to Reply

          Thanks! Liking that new page a lot.

        • scribu 9:40 pm on August 27, 2010 Permalink | Log in to Reply

          Nice, but the page title reads WordPress > About > Requirements

        • filosofo 5:07 pm on August 30, 2010 Permalink | Log in to Reply

          From the Philosophy page:

          There’s a good rule of thumb within internet culture called the 1% rule. It states that “the number of people who create content on the internet represents approximately 1% (or less) of the people actually viewing that content”.

          So while we consider it really important to listen and respond to those who post feedback and voice their opinions on forums, they only represent a tiny fraction of our end users. When making decisions on how to move forward with future versions of WordPress, we look to engage more of those users who are not so vocal online. We do this by meeting and talking to users at WordCamps across the globe, [sic] this gives us a better balance of understanding and ultimately allows us to make better decisions for everyone moving forward.

          (emphasis added)

          Mathematically speaking, it’s unlikely that “we” has spent enough time chatting at WordCamps to engage more than 1% of WordPress users. The counter says 13 million downloads of 3.0 so far. Assuming one user per download, talking to 1% of them for just one minute each would take by itself a full-time job for over a year, with no time to process or organize the results. It would also mean that all the past WordCamps would have had on average a couple thousand unique attendees each.

          More importantly from a statistical perspective, those with the means, the time, and the interest to attend a WordCamp are not likely to compose a representative sample of WP users in general. Nor are they are going to speak many of the hard truths in a WC reception line.

          I’m not just being pedantic; something as fundamental as a guiding philosophy should be accurate and honest. There’s nothing wrong with saying that, when it comes to resolving contentious disputes or setting big-picture goals, the ultimate arbiter is Matt Mullenweg’s judgment, which has served him well so far in numbers of WP users and the financial success of Automattic. Mullenweg keeps his finger on the pulse of WordPress users by meeting with hundreds of them at WordCamps across the world, reading thousands of blog posts, etc.

          Spelling this out would have the additional benefit of avoiding needless frustration for some contributors in controversies like capital_P_dangit, as you could just point them to the philosophy document.

      • bentrem 5:45 pm on August 27, 2010 Permalink | Log in to Reply

    • JohnONolan 9:40 pm on August 26, 2010 Permalink | Log in to Reply

      Further thoughts and questions that took me a long time to learn:

      Who are the core team?
      Who answers to who? What is the hierarchy of power?

      (oh I see that Nacin just added this above)

      What is ETIQUETTE on Trac? I was petrified for months of Trac, not being able to edit stuff is frightening. As is changing the status/priority/anything of a ticket without knowing whether or not it’s the right thing to do.

      How do you apply a patch (in detail, inc info about how to dowload it FROM trac) for testing?

      A template for bug reporting which people can use to create better, more substantial tickets.

    • Mr Mist 9:51 pm on August 26, 2010 Permalink | Log in to Reply

      A really simple guide on how to create a workable patch in various O/S.
      When to re-open a ticket / when not to re-open.
      What to put in the tags fields

    • Andrew Nacin 9:52 pm on August 26, 2010 Permalink | Log in to Reply

      From Ryan: The two most important attributes of a core contributor are brevity and thick skin.

      I’d argue that the brevity can be applied widely: to patches, comments, personal agendas.

      • John James Jacoby 10:08 pm on August 26, 2010 Permalink | Log in to Reply

        Agree with this completely. No one wants to read through a 4 paragraph explanation of a bug. And no one is out to hurt anyone else’s feelings; and if your feelings are hurt, you’re doing it wrong.

    • bentrem 9:53 pm on August 26, 2010 Permalink | Log in to Reply

      25c reads like this: a) as I cited in IRC, ” Boeing’s old “Sequential Thematic Order of Presentation” (STOP)” … time tested and industry-strenght. Else you get caught up in subjective aspects. Gotta have a matrix or tree to hang things from. –ben

    • Brian Layman 9:56 pm on August 26, 2010 Permalink | Log in to Reply

      A default assumption that others know at least as much as you, if not more. This helps you ask why something was coded a particularly way rather than going in with a “this code is bullocks” attitude.

      • Jacob Santos 10:03 pm on August 26, 2010 Permalink | Log in to Reply

        This a good suggestion but hard to do. Sometimes the personality of people (like mine) is to assume everyone doesn’t know what they are doing until they prove otherwise. However, it is very quick to learn who knows what they are talking about verses those who relatively don’t.

    • Andrea_R 10:26 pm on August 26, 2010 Permalink | Log in to Reply

      Just a few broader ones for those new to the process:

      • what do I need to keep tabs on?
      • should I hang out in IRC? When? If I’m contributing on a regular basis, is there an expectation that I should show up for dev chats?
      • after reading all the above resources, who do I turn to if I have a question that needs clarifying?
      • do I need to join particular mailing lists?
      • if I file a ticket, is it expected that I need to also produce a patch? Will it help if I do?
      • Jacob Santos 10:30 pm on August 26, 2010 Permalink | Log in to Reply

        I think dev chats has always to me been a point of contention. Decisions are made there and I suppose they are tentative, but the problems has been that work places usually do not allow for IRC chats that aren’t work related. Generally also, one can not bring up dev chat related topics after the dev chat is finish barring both those who work at jobs restricting access to the IRC chat and those who sleep during the time periods of the chat.

    • Ron 10:32 pm on August 26, 2010 Permalink | Log in to Reply

      I jumped into the deep end of the pool in January. A brief guide to trac (which others have mentioned) would be indespensible, imo.

      Second, for people who are interesting in being actively involved on an ongoing basis, I would strongly recommend that they follow activity in trac and review all the IRC logs for at least a month. The huge benefit to the contributor is that they will become familiar with the “regulars” and how they work together.

    • Ryan McCue 12:47 am on August 27, 2010 Permalink | Log in to Reply

      One essential piece of knowledge is knowing how to get your patches actually committed. I’ve found that the trick is to bug committers until they get sick of you doing so and finally commit it. ;)

      (Seriously though, at least mentioning your patch in #wordpress-dev helps to get it committed)

      • Andrew Nacin 2:12 am on August 27, 2010 Permalink | Log in to Reply

        Justification is also important. I like this from our Release Philosophy page on the Codex: “If you’re too lazy to do the homework and think through the big-picture rationale, I’m too lazy to add the feature. On the other hand, patches that come with well-thought-through rationale are often applied right away.”

    • Andrew Nacin 2:32 am on August 27, 2010 Permalink | Log in to Reply

      Another good thing that takes a while to figure out, is navigating specific aspects and functionality of the codebase, and how that goes into creating patches. A few examples that come to mind:

      • CSS and JS. Don’t minimize. It keeps the patches small, it prevents patches from going stale over an otherwise unrelated change in the file, and it allows the committer to confirm that the file was indeed properly minimized.
      • Images. Attach them to the ticket, preferably the originals too so we have a record of them. (Good for UI group.)
      • Script/db_version bumps. No need to include the bumps in the patch; we can handle them that way we know we got everything.
      • DB upgrades. How it all works is definitely confusing as first. Same with update-core.php.
      • Deprecated functions. Where they go, how we do it, etc. Maintaining full functionality is vital.
      • Also knowing how to test certain aspects of the code, using WP_DEBUG, etc.
    • dougwrites 5:59 pm on June 4, 2011 Permalink | Log in to Reply

      Still taking suggestions? Thank you for doing this!

      General: having patience with the cycle, but also understanding deadlines and when to jump before those points when no longer can get something in.

      Docs: especially contextual help but also inline. Different from other patches?? Best way to package patches (individual files, omnibus sets, also attach text files of what text would look like with changes?). Knowing that writing is rewriting and re-rewriting. Balancing brevity with hitting enough key points.

  • Andrew Nacin 8:49 pm on August 26, 2010 Permalink
    Tags: 3.org,   

    /extend is currently being upgraded. Currently @mdawaffe is working on the plugins directory. Please excuse any ceiling tiles if you’re hit with one.

     
  • Andrew Nacin 7:03 pm on August 26, 2010 Permalink
    Tags: 3.org, api-dev   

    Updates for the API reference project: duck_ was out of town, Aaron has been working on the handbooks, and Koop and I have been working on GSoC (done!), but I think we can still have some good stuff done in the next few weeks.

    Koop and I have been playing with a parser written by duck that seems like it is an excellent base for what we want to do, which is in turn excellent. Ideally we’ll have a working prototype soon, with the goal to have something launched in beta early in the 3.1 cycle.

    I’ll send that code over our api-dev list and hopefully kickstart some more progress.

     
  • Aaron Jorbin 5:32 pm on August 25, 2010 Permalink
    Tags: 3.org, ,   

    Plugin Developer Handbook Chapter List 

    Thank you to everyone that commented and help me brainstorm what is needed for a good plugin developer handbook. I’ve synthesized that information and have come up with the following chapter list / section plan behind the jump. Please let me know if there is anything you think I missed. Remember, this handbook is designed specifically for the task of Plugin development. It’s not designed to be the end all, be all guide to WordPress. It’s designed to help new plugin developers get to the point that they can build a plugin and assist existing plugin developers with finding the best practices for doing things.

    The next step is going to be to find authors for all of these sections. I’m going to be reaching out to a number of people to help out, but I’d also love to see some people volunteer. Please contact me @aaronjorbin on twitter or jorbin in IRC if you think you might be interested in writing a chapter or section. I’m going to be leaning on many of you, the experienced core developers and plugin developers.

    (More …)

     
    • Stefano Petroni 5:39 pm on August 25, 2010 Permalink | Log in to Reply

      Can’t wait to read it! :-)
      Thank you!

    • Jane Wells 7:23 pm on August 25, 2010 Permalink | Log in to Reply

      It would be great for volunteer authors to leave a comment on this post rather than using twitter etc. so that we can keep a record here.

    • Alex M. 7:39 pm on August 25, 2010 Permalink | Log in to Reply

      I assume you’ll want me to take oEmbed? If no one else steps up, I can also document some other APIs such as shortcodes, transients, or caching. My freetime is limited though, so don’t heap too much on me. ;)

      • Aaron Jorbin 7:35 pm on August 26, 2010 Permalink | Log in to Reply

        Alex, You were just the man I had in mind for oEmbed. I don’t want to over burden you, but may come back and ask for help on another after I’ve talked to a few others.

    • peterchester 1:22 am on August 26, 2010 Permalink | Log in to Reply

      This is great! We’ve been working on bits and pieces of something like this at our company (Shane & Peter, Inc.) with the intent of ensuring that we all abide by the same coding conventions.

      Is the idea behind this that developers would read the whole thing start to finish or that they would read a couple intro parts and use the rest of it as a look up index?

      • Aaron Jorbin 3:13 pm on August 27, 2010 Permalink | Log in to Reply

        Section 1 is largely going to go over basics and outside of the introduction, should be skippable/skimmable by experienced developers.

        Section 2 will hopefully be read by everyone. Section 3, pretty much the same though skimmable if you’re not storing any data.

        Section 4 will largely be a reference section.

        Section 5 will be used mostly for people releasing plugins publicly…which should be all plugin developers :)

    • mercime 8:21 pm on August 26, 2010 Permalink | Log in to Reply

      Hi Aaron, perhaps in tips or dev section, add list of tools/arsenals to create a plugin. like basic text editor, poEdit, FF with Firebug and Web Dev extensions, etc. Or maybe that’s too basic? :-)

    • Jacob Santos 8:53 pm on August 26, 2010 Permalink | Log in to Reply

      Well, I could probably write the entire 5th section if you need a draft.

      • Aaron Jorbin 9:16 pm on August 26, 2010 Permalink | Log in to Reply

        I’m going to Ping you in IRC one of these days. I think that at least one of the parts of Section 5 will be right up your alley.

    • Aaron Jorbin 9:17 pm on August 26, 2010 Permalink | Log in to Reply

      One Additional Section I forgot to add (Section 6 or maybe Appendix A) will be a list of tips, tricks, and notes from a wide variety of developers. That will be assembled and worked on much later.

    • John P. Bloch 9:44 pm on August 26, 2010 Permalink | Log in to Reply

      I’ve got WP_Rewrite like we discussed.

    • Stephanie Leary 9:53 pm on August 26, 2010 Permalink | Log in to Reply

      I wrote a basic walkthrough of SVN for people who’ve never used SVN before as part of the plugin chapter in my WP book. It has a ton of screenshots using Versions for Mac and Tortoise for Windows. If it would be helpful, you can have it.

      I think I also have the How to Get Help chunk.

    • Brian Layman 5:06 am on August 27, 2010 Permalink | Log in to Reply

      I’m up for the Short Codes entry if you need someone. Or one of the two other sections we’d discussed if needed…

    • Jay Fortner 1:11 pm on August 27, 2010 Permalink | Log in to Reply

      If you need anyone for Actions and Filters or Coding Standards – I’m here.

    • Marjorie Roswell 1:12 pm on September 17, 2010 Permalink | Log in to Reply

      Could this be placed on a wiki, so that names could appear next to the actual chapters? Might make it easier to see what’s left to claim.

  • 8:52 pm on July 30, 2010 Permalink
    Tags: 3.org,   

    Plugin Directory: Community 

    As one of two 3.org groups tasked with improving the WordPress.org Plugin Directory, the Plugin Directory: Community (PDC) group has read through all the Potential WordPress.org Improvements and has weighed what ideas would best improve the community and would be manageable to do before development on WordPress 3.1 starts. This group is tasked with improving the user interaction with the directory, the authors, and the rest of the community. Here are the ideas that have made it to the final round of the selection process:

    • 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.

     
    • Mike Schinkel 9:18 pm on July 30, 2010 Permalink | Log in to Reply

      One idea I’ve been bouncing around is to have a color-coding (and an accessibility equivalent) for plugin ratings based on the number of ratings a plugin has. Clearly a plugin with one 5 star rating (typically from it’s own developer) looks good at first glance but that rating means little. I’d far prefer to see a 4 star rating for a plugin that has been rated 100 or a thousand times.

      Suggestion: Calculate and graph the distribution of the count of ratings that are given to plugins and then find natural break points in the distribution much like how a college professor grades on a curve. Hopefully you’ll find between 4 to 7 ranges and then for each range assign a color for the stars starting with a gray and moving toward a bright yellow. The plugins with less vivid colors but high average star ratings will give an easy indicator that a few people think highly of the plugin, but the few plugins with very vivid stars and a high average star rating are the real winners. Thoughts?

    • Gautam 8:29 am on July 31, 2010 Permalink | Log in to Reply

      Can you elaborate on plugin adoption process? IMO, only some ellegible members should be allowed to take over abandoned plugins. Otherwise, people/companies may take over it, put some ads/more links/bad coding/spam/footer links etc.

      • Peter Westwood 1:53 pm on July 31, 2010 Permalink | Log in to Reply

        We don’t have a particular process in mind yet.

        It is one of the things we intend on trying to create over the next few weeks as part of the output of our 3.org team

      • Dan Cole 4:49 pm on July 31, 2010 Permalink | Log in to Reply

        Were looking into doing a more detailed version of plugin stats, looking at user adoption. The PDC group decided that allowing developers to adopt plugins belonged to the Plugin Directory: Support & Management group. I think both Plugin Directory teams should chat to clear up some of the gray areas between the two tasks we’ve been assigned to.

    • Mike Schinkel 8:15 pm on July 31, 2010 Permalink | Log in to Reply

      Other things I’d love to see about plugins are 1.) when first available, 2.) how many updates. A plugin that was first uploaded last week is less likely to be mature than one first uploaded 2 years ago with 17 updates, for example.

    • mark. 4:12 am on August 1, 2010 Permalink | Log in to Reply

      “Allow the community to publicly ‘Like’ plugins.”

      I had to double check I wasn’t on Facebook… Is this a replacement for the star rating, or is it just to tie into the community profiles (ie, Jon likes x plugins)?

      • Dan Cole 3:30 pm on August 1, 2010 Permalink | Log in to Reply

        When I worded that, I was thinking of the WordPress.com ‘Like’ button. My thoughts were for something in the community profiles, where people could see how many plugins you like, as well as the list of those plugins. Each plugin page would also have a list of people who liked the plugin. I didn’t think of replacing the star rating system, but it’s a possibility if people are on-board.

        • mark. 4:45 pm on August 2, 2010 Permalink | Log in to Reply

          This is semi-unrelated to my original post, but what I’d like to see before completely new features are added is a few updates to the old ones; case in point, people shouldn’t be allowed to say “Doesn’t Work” without filing a report (can be private or public) as to why it didn’t work for them.

          I hate seeing that on my plugins and not knowing what to do to help fix it. If it’s a valid issue people should have no problem entering a two line description (or more if they’re really nice!) and if it’s just a bad day for somebody it would slow them down enough to reconsider.

        • Dan Cole 2:04 am on August 3, 2010 Permalink | Log in to Reply

          Mark, the report part of the “Doesn’t Work” problem, is on the PDC list. The bullet of it was kicked off this post because of a poor choice of words that obscured things.

    • Jane Wells 11:51 pm on August 1, 2010 Permalink | Log in to Reply

      I don’t love the Like idea. I’d rather have a place in profiles where .org users can ID what plugins they actively use, and show their ratings/reviews for them.

      • Paul Gregory 8:28 am on August 2, 2010 Permalink | Log in to Reply

        Profiles should list all plugin reviews, positive and negative.

        A “plugins I actively use” section could be useful too, but I think people would be more likely to fill this in if their efforts made their life easier. I know the focus is on the .org site but this data could be fairly easily made available to WP to make it easier to add commonly used plugins.

        So whenever I set up a new site, I could go to Plugins > Add New, change the dropdown to “User”, search for my own ID and easily see my favourite plugins. Even more usefully, I could see a colleague’s list (or vice versa). This would save a lot of time.

        I’m not fussed whether adding plugins to my profile list is called “Like”, “Add to Favourites” or “Add to public list of plugins I actively use but may merely tolerate”. I suspect however that a phrase that is widely understood but inaccurate will prove most suitable.

        • Dan Cole 1:58 am on August 3, 2010 Permalink | Log in to Reply

          I realise now, that ‘Recommend’ would have been a better word to use to describe my view.

          Hopefully this 3.org update will continue as a full-time gig for a few developers, because their are a lot of useful things that could be done to the WP.org site. I’ll be sure to create WordPress.org Trac tickets for the great ideas that are not developed.

      • Dan Cole 1:50 am on August 3, 2010 Permalink | Log in to Reply

        To go further into you view Jane, what would your vote (+/-1) be for 1) Bookmarking plugins, 2) Marking plugins as favourites, 3) Showing actively used plugin, 4) Reviewed plugins, 5) Recommending plugins? Basically, I’m trying to get at how exclusive/inclusive should using, ID-ing, and reviewing plugins be?

      • Mike Schinkel 2:14 am on August 3, 2010 Permalink | Log in to Reply

        @Jane: If people have to work at recommendations the 90-9-1 rule[1] says only 1% of users will do it.

        What about adding a new plugin to be distributed with WordPress called (something like) “Rate My Plugins” that will let users from their own WordPress dashboard give their opinion of the plugins that they are currently using and have their recommendations submitted by to 3.org? Such a plugin could put notices on their dashboard showing plugins they’ve not rated and/or written a recommendation for complete with a one-click way to make specific notices go away. And If they want all notices to go away they go simply disable the plugin. This plugin could ask for a rating on deactivation too.

        Of course this would only be worthwhile if bundled with WordPress because <1% would actually take the effort to download and use such a plugin. Worth consideration?

        [1] http://www.useit.com/alertbox/participation_inequality.html

        @Dan: +1 on the continued development of 3.org.

    • Mike Schinkel 4:53 pm on August 2, 2010 Permalink | Log in to Reply

      I’d really like to see anonymous reporting back to WordPress.org on plugin usage so we could generate stats on what plugins are really in use.

      • Azizur Rahman 10:07 am on August 3, 2010 Permalink | Log in to Reply

        Anonymous reporting is good but in some environment it would not be allowed. I have worked in such environment.

        • Andrew Nacin 6:51 pm on August 5, 2010 Permalink | Log in to Reply

          We have reporting via the plugin update check. We don’t collect what is active and what isn’t, nor do though I believe we should. But we can provide plugin developers with basic aggregate stats they can use to identify which versions of WP they should support, whether they can force PHP5 without deserting a lot of their userbase (no longer an issue, but a historical example nonetheless), etc.

        • Mike Schinkel 6:55 pm on August 5, 2010 Permalink | Log in to Reply

          @Azizhur I guess I should have been explicit with my assuming optionality of this request.
          @Nacin: Why should we not collect which plugins are in use, anonymously and with explicit approval by the site owner? It would be hugely beneficial to know which ones are actually being used vs. just which ones were downloaded for evaluation.

        • Andrew Nacin 8:20 pm on August 5, 2010 Permalink | Log in to Reply

          Mike, that sounds like a good idea for a plugin that, as a primary purpose, puts plugin ratings (works/doesn’t work, +1/-1, reviews, etc) directly in the administration area.

        • Mike Schinkel 8:33 pm on August 5, 2010 Permalink | Log in to Reply

          @Andrew I guess I was bitten by the implication again; see elsewhere on this page where I said “Of course this would only be worthwhile if bundled with WordPress because <1% would actually take the effort to download and use such a plugin." Without a large and non-self selected sampling (ignoring the opt outs) the statistics generated would be meaningless.

        • Andrew Nacin 9:22 pm on August 5, 2010 Permalink | Log in to Reply

          Let me clarify/amend my position. I do think we should be collecting active versus inactive stats. I think the whole ‘explicit approval’ thing confused me with something else I’ve been thinking about.

    • Azizur Rahman 10:11 am on August 3, 2010 Permalink | Log in to Reply

      I would like to see the Plugin Security Review Team clearly label or block plugins download from wordpress.org that has verifiable vulnerability until the author/developer fixed it. http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=wordpress has list of some of them.

      • Dan Cole 11:39 pm on August 5, 2010 Permalink | Log in to Reply

        In the immediate future, this will not be possible to do. The team would have to read millions of lines of code, most of which are not standardized, or clearly laid out. However, if things with the Plugin Security Review Teams go well and the team decides to move in this direction, then maybe we would see labelling or blocking of insecure plugins in a year or two by this new team.

      • Andrew Nacin 11:49 pm on August 5, 2010 Permalink | Log in to Reply

        I’m pretty sure the current policy is to disable any plugin listing that has a major security flaw pending a fix. Labeling a plugin as abandoned, etc. (what have you) is fine, but for seriously insecure plugins, the proper contact would be plugins@wordpress.org or security@wordpress.org, I think.

    • Sergey Biryukov 11:55 pm on August 10, 2010 Permalink | Log in to Reply

      It would be great to have the Plugin Directory available in different languages, along with the plugin descriptions and installation instructions.

    • Brian 11:54 am on October 2, 2010 Permalink | Log in to Reply

      I like the idea of user profiles with plugins used, ratings and reviews. I don’t need to know the name but I would love some stats on users to determine authority. 1 idea — “__% of users that downloaded this plugin also downloaded X, Y & Z plugins” My biggest pet peeve right now though is the search functionality. This should include: the version, which could use: reported by dev, broken/works data. I would also suggest forcing login to download this could then be used to track downloads and request feedback. Users could then see what they have already looked at, reviewed, rated and a feature I would love would be the ability to remove plugins from searches so they don’t keep looking at the same plugins. Login would also increase reporting, reviews, rating for better dev feedback.

  • Aaron Jorbin 8:22 pm on July 22, 2010 Permalink
    Tags: 3.org, ,   

    Plugin Developer Handbook Planning 

    I’ve started brainstorming ideas for the plugin developer handbook and have come up with a pretty long list of topics that I think should be covered. Some of these will be chapters on their own, some will be combined together and others still need to be thought of. For right now, the best feedback you could give me is to tell me what I missed and what you think might be out of scope.

    A couple of notes:

    • I tried to include chapters so that both novice and experienced developers will be able use it. Hence ideas such as knowing the difference between the different languages used in WordPress.
    • Some things, while listed, I think will include warnings and language that discourages it. The two that stand out to me are: Custom database tables and Custom Option Pages.

    Alright, now for the list:

    • Introduction
    • Languages of WP – Differences between PHP, HTML, CSS, JS
    • WP Coding Standards
    • Organizing plugin files
    • Planning your plugin
    • Name Spacing
    • Adding Styles and Scripts
    • Actions / Filters
      • How to use them
      • How to add them to your theme so other plugins can use them
    • Shortcodes
    • Widgets
    • Front End Forms
    • Ajax
      • Front end ajax
      • Back End ajax
    • Roles and Capabilities and users
      • Custom caps
      • User Meta
    • Comments
      • Comment Meta
      • interacting with comment filters
    • Options
      • Adding options to existing admin pages
      • Adding your own pages
    • transients
    • Translating / Internationalization
    • Custom Taxonomies
    • Custom Post Types
    • Scheduled events (pseudo-cron)
    • Activation / Removal hooks
    • Interacting with the database
      • Adding Tables / interacting with them
    • Security
      • Kses
      • Escaping
      • Capabilities check
      • Nonces – Props Eric
    • Interacting with remote URLs
      • atom / rss
    • Interacting with WP_Query
    • Media
      • Media and Post relations (Send to editor)
    • Modifying / Creating URLs
    • MultiSite specific Compatibility
    • General Tips / Tricks / Notes (Ideally a tip or two from many different devs)
    • Adding Admin Notices
    • Giving your plugin the WordPress look (Hopefully the style guide will be finished before then).
    • Pluggable Functions
    • Admin Meta Boxes
    • Dashboard Widgets
    • Extending Tiny MCE
    • A Good Development Environment
    • Development Process
     
    • Mike Schinkel 8:25 pm on July 22, 2010 Permalink | Log in to Reply

      Wow, that’s an incredibly good list. Kudos.

      I think that to improve that list will probably take just working on it to realize what’s missing but otherwise it’s incredible.

    • Rahul Bansal 8:30 pm on July 22, 2010 Permalink | Log in to Reply

      Such a handbook will be a real treat for plugin developers.
      Being in business, I keep hearing from developers that wordpress codex is too primitive and wordpress lacks documentation a CMS need to win enterprise userbase.
      I guess such handbook can fill that void.

    • Eric Marden 8:59 pm on July 22, 2010 Permalink | Log in to Reply

      I’d also cover functions.php. While a theme file, the techniques are largely the same.

      • Aaron Jorbin 9:22 pm on July 22, 2010 Permalink | Log in to Reply

        I think the eventual Theme dev handbook will cover that more (and will share alot of chapters/sections with this handbook)

        • Eric Marden 9:24 pm on July 22, 2010 Permalink | Log in to Reply

          I think its a topic worth touching on in Plugin Dev Handbook, but covering fully in Theme Handbook.

        • Aaron Jorbin 9:27 pm on July 22, 2010 Permalink | Log in to Reply

          How do you think it should be covered? What in do you think plugin devs need to know about theme functions.php files?

        • Mike Schinkel 9:31 pm on July 22, 2010 Permalink | Log in to Reply

          For one, functions.php is a great place to start testing out proof-of-concept functionality that may be later moved into a proper plugin. Discussing that and the process of moving from proof of concept testing to actual plugin might be helpful.

        • Aaron Jorbin 9:50 pm on July 22, 2010 Permalink | Log in to Reply

          I’ve added a section on development enviorment that could probobly cover that unless there is something else I am missing?

          I think I’m also going to add a Development Process section.

        • Mike Schinkel 9:58 pm on July 22, 2010 Permalink | Log in to Reply

          Good idea. Elaborating, it would be nice to talk about setting up a local development environment on at least Windows, Mac OS X and generic Linux.

        • Eric Marden 10:00 pm on July 22, 2010 Permalink | Log in to Reply

          I’d say that it should probably cover:

          • The differences between functions.php and plugin files.
          • What’s available and not available to you in functions.php
          • When you should use it instead of a plugin

          Then point folks to the theme dev hand book.

        • Aaron Jorbin 4:55 am on July 23, 2010 Permalink | Log in to Reply

          Eric – I think the first and the third parts would be good, I think the second is straying a bit too much into theme development and might be out of scope. This is designed to be one in a series of handbooks with the focus specifically on Plugin development. While a lot of the information within this handbook will also be in the theme developer handbook, I’d prefer it not confuse the two too much.

          Mike – That’s exactly what I meant by setting up a development environment. I imagine that section is going to be heavy on links and lighter on content though.

        • Eric Marden 2:26 pm on July 23, 2010 Permalink | Log in to Reply

          Aaron – Sounds good to me. As long as their some mention of it, and pointers to more, I think it will help people avoid confusion and concur that you get into theme land pretty quickly when using the functions.php bridge.

          Mike – I agree with Aaron here, Dev Environment, while useful, is a bit out of scope. Pointing people to some good links is best, but this topic, I feel, should only be touched on in the scope of why its a good idea, not how to make it happen.

        • Mike Schinkel 2:35 pm on July 23, 2010 Permalink | Log in to Reply

          @Eric: While not completely disagreeing I will say that the biggest “hump” I had to get over before I could finally be productive was getting a dev environment set up (I had been on Windows+ASP+IIS+SQL Server for 10+ years so LAMP/WAMP/MAMP was all foreign to me.) After I finally was able to get help getting it all set up (3+ years ago, for Drupal at the time) I was rapidly able to gain relevant skills because each step was such a small step from the one before compare with the initial setup. I’ve also taught a lot of people WordPress over the past 2 years (~100 people) in workshop environments and the most important step for almost all of them is getting the development environment set up. So given how little one can do without it compared to with it and given how big a hurdle it can be to set up I would suggest we at least consider giving it more weight than we might otherwise give it if it were not such a critical path to productivity. JMTCW.

        • Eric Marden 7:22 pm on July 23, 2010 Permalink | Log in to Reply

          @Mike

          While I don’t disagree that a local development environment is a huge boon to productivity and is an important topic, it starts to delve into the area of systems administration – one of the reasons I feel that a lot of new developers struggle with it, avoid it, or don’t even know they should or could have a local server. What I’m suggesting is limiting the topic to just the essentials and letting other sources deal with all of the other variables.

          In other words, it could look something like this:

          • Here’s WAMP (windows)
          • Here’s MAMP (mac)
          • Here’s apt-get (linux)
          • Here’s how to configure a VHOST to serve one WP site.

          As soon as we try to help them worry about multiple virtual hosts, the specifics of configuring Apache, managing the /etc/hosts file for overriding DNS this topic soon becomes unwieldy and given that it is not essential for you to have one to develop a plugin we shouldn’t try to create even a shadow of a full blown HOWTO on the topic.

          Trust me, I’m the guy who has stepped in on a project and wouldn’t write a single line of code until the entire team got a local dev environment installed. But if there’s one thing I know about this topic is that getting the perfect set-up is almost impossible and the way they other guy did it is always “wrong”. Do I hand compile or use a package manager? Install binary components myself and tie them together in the configuration? A virtual machine with ubuntu? Or use a prepackaged all-in-one solution? Even the level of choice in this area, as you can see, can be overwhelming on its own and we haven’t even begun to tell you which steps to follow.

          Another reason to err on the side of simplicity (and letting other sources guide the users more deeply) is that anything put in this handbook will end up generating questions on the forums, #wordpress and wp-hackers and shouldn’t we really be in the business of supporting WordPress and not their (particular) local server?

          My 2 cents,

          ~e

        • Mike Schinkel 10:34 pm on July 23, 2010 Permalink | Log in to Reply

          @Eric Fair points.  

          One thing that I would personally like to see is it be _comprehensive; that would have helped me so much 2 years ago and I’d like to see others not have to go thru the same. If topics are collectively deemed as being too much of whatever then I’d argue at least that we cover the topic by curating a list of articles and solutions even if they point off WordPress.org. Then, for example, we could find a multiple VHOST article that covers concerns related to WordPress or if one can’t be found then one of us could write one on our blog and link to it. FWIW multiplier VHOSTs were one of the more difficult things to figure out yet one of the ones I cannot image being without today. Ironically it was really not difficult, I just had to learn a few arcane details. those details would make a great article.

          As for the other comment you made let me relate a story and I apologize that it is off topic for the develop handbook. Shortly after graduating college, probably 1992 I attended a presentation to entrepreneurs where the message hit home and has stuck with me for my adult like. In a nutshell the person made the point that if you have something you are “selling” (in our case we are all advocating for WordPress) then it is in your win best interest to make sure the prospective customer has as easy a time being able to acquire and use your solution as possible. If there is anything that would cause prospects to stall and go elsewhere, or simply not “purchase” at all then it is incumbent upon you to handle that problem for them or at least make the problem appear to go away.  

          So yes one can argue that we want to support WordPress only and not help people with their server setups and from a standpoint of purity you would be right. OTOH if we in fact do care about seeing a lot more people adopt WordPress then such perspective may be self-defeating. Note that the solution may not always be to “brute force” it but instead may be to divide and conquer (i.e. maybe we solve the problem by working with web hosts to minimize the problems, educate prospective users on which hosts have the least problems and then provide support for the remaining.) JMTCW.

        • Tim 10:54 pm on July 23, 2010 Permalink | Log in to Reply

          Discussion of Dev Environments, to some degree, would be good. Rather than focusing on specific environments, maybe a better way to approach this section in the handbook would be to encourage standardized ways of reporting what versions of WordPress (version number and single vs. Multi-Site testing), PHP and MySQL a plugin has been tested on. Right now, there’s a “tested up to” tag in the plugin header, but there isn’t a consistent way to report PHP/MySQL version requirements.

          Or perhaps this belongs in a new section covering “Writing a good readme file”?

        • Matt 11:07 pm on July 23, 2010 Permalink | Log in to Reply

          Small handbooks, loosely joined.

        • Aaron Jorbin 1:57 am on July 24, 2010 Permalink | Log in to Reply

          Anything more then a passing reference is going to be too much. I don’t want this devolving into a 800 page coffee table book that no one actually reads.. It’s for WordPress Plugin Development, not system administration. Perhaps there will be another book focused on that.

    • Eric Marden 9:00 pm on July 22, 2010 Permalink | Log in to Reply

      Also don’t forget to talk about nonces. Probably under security and/or options pages.

    • Denis 9:05 pm on July 22, 2010 Permalink | Log in to Reply

      I think you’re missing an important bit: the WP flow, with an outline of the hooks and when they occur, in what order, what they’re used for, etc. And most importantly, how to not interfere with other plugins on the same hook… (eg never call remove_action(myhook, myfunc) on myhook.)

      • Aaron Jorbin 9:26 pm on July 22, 2010 Permalink | Log in to Reply

        I think the API reference is going to more so cover flow. The actions section will definitely cover proper use of actions and priority.

    • Eric Marden 9:25 pm on July 22, 2010 Permalink | Log in to Reply

      Media probably covers this a bit, but overriding the javascript send_to_editor was a recent find of mine and is worth covering. I’m guessing there are other Javascript ‘hooks’ (timymce stuff?).

    • Aaron Jorbin 9:48 pm on July 22, 2010 Permalink | Log in to Reply

      Added:
      Pluggable Functions
      Admin Meta Boxes
      Dashboard Widgets
      A Good Development Environment

      • Eric Marden 10:09 pm on July 22, 2010 Permalink | Log in to Reply

        • PHP Docblocks
        • Licensing and Distribution
        • Promoting your Plugin
        • Best Practices with JS/CSS (like not using !important in your CSS, etc)
        • PHP Best Practices ( i.e. Coding with E_ALL on, avoiding common Notices/Warnings)
        • SVN
        • Releasing your Plugin on WP.org
        • ReadMe.txt and plugin comment header
        • Data Import/Export
        • Migrations (WP_RELOCATE)

        Obviously we’re getting into the minutiae now, and some of this stuff can be and probably is implied by some of what’s above, but thought I’d offer them up anyway. Also some of this may be running into other hand book territory.

        Is this going to be collaboratively written, and if so where and on what platform?

        • Aaron Jorbin 4:59 am on July 23, 2010 Permalink | Log in to Reply

          I’m not sure if migrations would really fall under the purview of a plugin developer. I think that might fit better for a WordPress administrator book.

          For Import/Export, I assume you mean import/export of plugin data. Correct?

        • Ryan McCue 1:12 pm on July 23, 2010 Permalink | Log in to Reply

          Apologies for the off-topic reply, but what precisely is WP_RELOCATE? I can’t find a reference to it anywhere in code, and there’s only one reference to it on wp-hackers.

      • Eric Marden 2:33 pm on July 23, 2010 Permalink | Log in to Reply

        Ryan – sorry its RELOCATE, documented here: http://codex.wordpress.org/Changing_The_Site_URL#Relocate_method

        Aaron – You may be right. I continue to suggest things from a more holistic WP Developer mind set. Maybe we need a handbook that integrates admin, theme, and plugin from a top down approach, where these topics so far have been a bit more ground up. (small component effecting larger whole).

    • Mike Schinkel 10:01 pm on July 22, 2010 Permalink | Log in to Reply

      Floating an idea. This could turn out to be a killer book if packaged as such, and might catch interest if available at major bookstores from people who might not otherwise dig into the topic. What about coordinating with a major publisher where the proceeds go to the WordPress Foundation? Again, just an idea to consider.

      • Matt 10:44 pm on July 22, 2010 Permalink | Log in to Reply

        We can cross that bridge when we get there. I wish all of the WP books thus far had been under an OS license but most authors aren’t going to have that sort of leverage with their publisher. I had one tell me “books are hard, why would we allow anyone to take the content!” Yes, ma’am, software is hard too. :)

        Now we’re completely off-topic, but here’s a link everyone should read:

        http://diveintomark.org/archives/2009/10/19/the-point

        • Mike Schinkel 11:12 pm on July 22, 2010 Permalink | Log in to Reply

          Yep, the idea is definitely premature but I figured it would be better to have in the back of our minds if doing so was an option. FWIW.

        • Stephen R 3:05 am on July 25, 2010 Permalink | Log in to Reply

          There’s an SVN book that is… not sure if it’s open source but they givve it away for free on the web site, or you can buy the physical book from O’Reilly. S not totally without precedent in books.

    • mercime 5:31 am on July 23, 2010 Permalink | Log in to Reply

      Plugin which create table/s in DB to add Uninstall function
      Cheers

      • Aaron Jorbin 11:53 am on July 23, 2010 Permalink | Log in to Reply

        That is part of the reason that people will be encouraged to use the existing data structures whenever feasible, but yes, that will be a part of custom tables.

    • João Pedro Pereira 10:21 am on July 23, 2010 Permalink | Log in to Reply

      Excelent list, Nothing to add besides TEST, TEST, TEST!

    • arena 11:39 am on July 23, 2010 Permalink | Log in to Reply

      Hi ! your list lacks structure.

      Most of the topics are related to the numerous wp api’s

      i would add the following topic
      . admin (menus, admin pages, clean coding (not loading js or css if current admin page is not related to plugin))

      • Aaron Jorbin 12:00 pm on July 23, 2010 Permalink | Log in to Reply

        Actually it does have structure, it’s an unordered list with list items that sometimes contain unordered lists :)

        For menus, I assume you are referring to interacting with the new nav menu items?

        Clean coding will certainly be a part of the WP coding standards and proper use of wp_enqueue_script / style (i.e. adding it to the right hook) will definitely be a part of the adding styles and scripts section.

    • filosofo 3:31 pm on July 23, 2010 Permalink | Log in to Reply

      Who is the proposed audience, and what do you see as the niche for this document in a world of grep, googling, and the Codex? It would be good to determine that before investing too much time in the wrong topics or too many details.

      Languages of WP – Differences between PHP, HTML, CSS, JS

      I don’t know the exact intended audience, but if it’s “developers” by any reasonable definition it should exclude someone who doesn’t know the difference between PHP and JS. That person needs to be doing remedial programming–maybe read Master PHP in 24 Hours or whatever—first.

      • Admin Meta Boxes
      • Dashboard Widgets
      • Extending Tiny MCE

      I suspect that’s the kind of detail that won’t do any potential audience much good. If you’re at the place that you’re ready to extend TinyMCE, you’re just going to google how to do it. If you’re new to WordPress plugin development, being blasted by a firehose of details will probably impress upon you the potential of WP, but it’s unlikely most of those details will stick. Or worse, the wrong details will stick to the detriment of more important ones.

      My suggestions: make the audience to comprise those with a reasonable knowledge of PHP, MySQL, and JS; neither beginners nor those who have an advanced knowledge of WP in particular. The former need more than you could possibly provide, and the latter don’t need your help.

      And don’t think of it as an academic course, in which someone can dedicate a semester to studying every topic. That’s not how most developers with jobs learn. Instead, pick a few truly core concepts, the ones that are necessary and sufficient to getting a typical plugin running. Then you can let code examples hint at some of the other details: they will be enough to spark interest without making the reader feel unduly burdened.

      • Eric Marden 7:31 pm on July 23, 2010 Permalink | Log in to Reply

        @filosofo

        I think that this plugin should serve more than just beginners. Even a mention of what’s possible (by covering all of the various extension points in WP) and cross linking to the function reference in the Codex will be a huge help to all developers, beginners and advanced alike. I, for one, am a bit sick of having to grep the code base just to look up a function signature or having to trace the code to discover that there is an undocumented filter buried in the middle of one of the functions that get called – the exact filter I need to write my plugin cleanly. I kind of see this handbook as a part comprehensive overview and part getting started guide.

        However, I do agree that a discussion on the difference between various languages and technologies used in the construction of a WP plugin is unwarranted and does provide a small barrier to entry for this part of the docs. Right now all the Codex has is this: “WARNING: Programming Code Ahead!” or something like that.

        • filosofo 7:43 pm on July 23, 2010 Permalink | Log in to Reply

          I think that this plugin should serve more than just beginners. Even a mention of what’s possible (by covering all of the various extension points in WP) and cross linking to the function reference in the Codex will be a huge help to all developers, beginners and advanced alike.

          Well, I guess it really depends on what the purpose of the handbook is supposed to be (its niche). To me what you’re describing sounds more like an annotated index of the Codex, or maybe even just the Codex already. That would seemingly be only a quantitative, not qualitative change from what’s already available.

        • Aaron Jorbin 2:25 am on July 24, 2010 Permalink | Log in to Reply

          @filosofo
          I view this as being a compliment to the API reference, but more focussed on Narrative explanations and explaining full API sections. While the API reference will tell you that register_taxonomy is used to create or modify a taxonomy object, and what arguments it takes, the handbook will explain what you can do with that taxonomy after it’s created.

          Will someone like you, who has a deep knowledge of the code turn to the handbook first? Doubtful. I imagine you’ll find what you need in the code. Might you turn to it if you have never used the HTTP api and want to get an idea of some best practices and a understanding of how you can use that in concert with Simple pie? Perhaps. Will someone building there first through fourth plugin find it useful? Absolutely.

          The reason I have the differences between languages is in part to help weed out the people that aren’t willing to learn more. I don’t view that as being as very long section. I imagine it being similar to http://aaron.jorb.in/blog/2010/01/you-better-know-the-basics/ , but better written. Then a simple: “Not scared to continue? Well onward to Victory!”

          For some of the sections (like TinyMCE editor), I actually think it might be best to keep it simple and point them to a small handfull of plugins that are doing it so that they can read some actual code. That’s open for thought though

    • jeremyclarke 4:56 pm on July 23, 2010 Permalink | Log in to Reply

      This looks great!

      It’s a small detail, but It seems to me that the “Actions/Filters” section should come before “Adding Styles and Scripts”. As far as I know, adding styles/scripts is done through the API so knowing how the API works first is probably a good investment ;)

      I’m pretty sure you would have changed it during the writing but figured I’d mention it as an excuse to tell you the list looks great and I’m excited for the result :)

      • Aaron Jorbin 3:55 am on July 26, 2010 Permalink | Log in to Reply

        The order above was in no way meant to imply the order the chapter would actually come in. It’s more so the order I brainstormed them in.

    • Jacob Santos 8:35 pm on July 23, 2010 Permalink | Log in to Reply

      It would be better to organize it in two or three sections.

      • Plugin System
      • How to Develop
      • WordPress Library Guides

      The Plugin System should include the introduction, what filters and actions are, how they work, how to add action and filters. Why and how they might be added to your themes and plugins.

      How to develop section should include WordPress coding standards, Subversion, WordPress Extend, adding plugins, checking out, how to work with the support and Trac Ticketing. Could also include notes on PHP docblocks, unit testing, and general ui testing.

      The WordPress Library Guides will include the large portion of the guide which would include every individual API section in WordPress and WordPress Admin.

      • Aaron Jorbin 3:59 am on July 26, 2010 Permalink | Log in to Reply

        My next step is actually to synthesize all this feedback and try to come up with a more coherent outline. What you’re proposing is pretty similiar to what I have in mind. Thanks Jacob!

    • bentrem 2:08 am on July 24, 2010 Permalink | Log in to Reply

      Are you setting up to co-author? Cuz I’ve been following DAV since *blush* a long time (see MozDawg on DAV and Docs, notes for which I started shortly after Netscape “released the code”.) Reason I ask: however slow the progress, progress there’s been. Now my first instinct was to shout out “This is a good start on a wiki page!” but I choked it back with something like, “Yaaa … yet.another dusty bit-rotted wiki page”.
      Social dynamics.
      Too bad GWave and GBuzz suck so completely when operationalized.
      p.s. I got started Analogous Techniques next month but my “army of 1″ batteries are flat / dead.

    • Stephen R 3:10 am on July 25, 2010 Permalink | Log in to Reply

      I think this is a really excellent idea. Part of the problem is making sure it will be updated over time and not grow stale == a problem oftentimes in Codex.

      Something you might add: a section on “final polish” — little things like adding the “Setup” link from the Manage Plugins page straight to your settings page. There are lots of little useful touches that aren’t purely core function of the plugin, but just make it a lot nicer in the details.

      • Aaron Jorbin 4:01 am on July 26, 2010 Permalink | Log in to Reply

        That tip is one that I think would be perfect for the General Tips / Tricks / Notes section. At a later date and time I’ll solicit those.

    • Ramon Fincken 1:30 am on July 26, 2010 Permalink | Log in to Reply

      Nice!

      Perhaps handy:
      Scheduled events (pseudo-cron) + Ajax frontend > http://www.ramonfincken.com/permalink/topic187.html

    • Mike Schinkel 3:42 am on July 27, 2010 Permalink | Log in to Reply

      I see you have transients (Transients API?[1]) but I don’t see any reference to the Settings API[2]?

      [1] http://codex.wordpress.org/Transients_API
      [2] http://codex.wordpress.org/Settings_API

      • jeremyclarke 3:01 pm on July 28, 2010 Permalink | Log in to Reply

        I think he just didn’t refer to it as the Settings API but he has:

        Options
        * Adding options to existing admin pages
        * Adding your own pages

        I think the first one would be the Settings API. Though its a good point that the section about adding settings pages should refer to the Settings API by name so that its brand is strengthened.

    • Byron 3:34 am on July 28, 2010 Permalink | Log in to Reply

      This Handbook is badly needed. It could seriously raise the average quality of WordPress plugins (my own could have benefitted tremendously when I start out a year-and-a-half ago). If it wasn’t for Vladimir Prelovac’s plugin book, I’d still be trying to start fire with sticks. Will this be open to contributors?

    • Jeff Sayre 3:04 pm on July 28, 2010 Permalink | Log in to Reply

      Aaron –

      Have you seen my article on WordPress action and filter events (hooks)? It could be useful for part of the information in the section on this subject. I have also created a plugin developers’ tool called the WordPress Hook Sniffer plugin. I just released an updated version this morning.

    • Marjorie Roswell 1:03 pm on September 17, 2010 Permalink | Log in to Reply

      Some questions that come to mind: Where should we look for the handbook? Online? In print? When? Will the handbook be available in draft form as its being developed?

  • Andrew Nacin 7:55 pm on July 8, 2010 Permalink
    Tags: 3.org   

    Proposed teams for 3.org 

    We have created more than a half-dozen teams for the 3.org initiative, based on various discussions, ideas, and proposals. As a general disclaimer, these may evolve over the next few days.

    API Reference. This team will build a comprehesive API reference based on inline documentation, and integrated closely with the handbooks. Lead: Nacin. Members: duck_, koopersmith, jorbin, mikeschinkel, benbalter.

    Handbooks. This team will edit a series of handbooks, with the ultimate goal of one each for users, multisite admins, plugin developers, theme developers, and core contributors. Lead: Jane. Editors: Lisa Sabin-Wilson, Andrea Rennick, Doug Provencio, Aaron Jorbin, Andrew Nacin, and others TBA.

    bbPress as a Plugin. This team will concentrate on creating a bbPress plugin for WordPress. Lead: JJJ. Member: PeteMall.

    We’re going to create a few teams to focus on the plugins directory. These teams may overlap and in some instances work together, but it is important to primarily work in small teams with manageable, defined scope. More about our general goals in this blog post.

    Plugin Directory: Support and Management. Develop tools enabling plugin authors to better support their plugins, and for better administrative management. Lead: Mark Jaquith. Members: beaulebens, Dougal, WDS-Brad, Glenn Ansley.

    Plugin Directory: Community. Improve user interaction with the directory, such as user reviews, adoption, comments. Lead: Peter. Members: filosofo, Dan Cole, Brian Layman, Michael Torbert.

    Plugin Directory: Core Integration. Improve installer, upgrades, compatibility reports, api.wordpress.org. Lead: Ryan. Members: TBD..

    UI Working Group: Will assist other teams. Lead: Jane. Members: JohnONolan, TECannon, Dremeda, MT, Kevin Conboy.

    We have identified two additional projects that would need teams to proceed:

    i18n Projects. Improving the management of localized plugins, and also providing better tools for localized communities.

    Plugin Directory: Stats. SVN notifications, improvements to Trac, better stats for plugin developers (and aggregate, public download stats).

    Quick hits for what’s not on here and why. Ideas forum: It’s a GSoC project by Justin Shreve. Themes directory: We hope lessons learned in the plugins directory projects can be carried over to the themes directory. Forums: We believe the plugins directory and the bbPress projects will offer incremental improvements to the forums. Codex: See API reference and handbooks. Profiles: We’ve realized without studying this well and developing a solid direction, a profiles project could flop. We’re going to go ahead with these projects and discuss profiles in the near future. Site content and design: We’ll get there.

    If you’re not on here, we’re sorry. We either omitted you accidentally, or weren’t sure what you want to commit to, or didn’t know enough about you to offer you an assignment. Please let us know where you’d like to be involved in the comments (links to your website, portfolio, etc would be useful). Just note that some of these teams are already pretty much at their maximum, as we want to them to be agile pirate/ninja teams. But we don’t want to leave anyone out who wants to enlist their skills and feels they can contribute.

     
    • BrianLayman 8:10 pm on July 8, 2010 Permalink | Log in to Reply

      Excellent! Sounds excitingT

    • scribu 8:10 pm on July 8, 2010 Permalink | Log in to Reply

      The “bbPress as a plugin” might want to take a look at A bbPress alternative

      • Andrew Nacin 8:15 pm on July 8, 2010 Permalink | Log in to Reply

        JJJ and PeteMall have been working on this for about as long as Justin has. They are taking different approaches, I think Justin is leveraging taxonomies and JJJ post types. I would love to see the efforts combined however, if everyone is interested. Ideally, it would end up a direct bbPress successor, versus an alternative.

        • scribu 8:31 pm on July 8, 2010 Permalink | Log in to Reply

          Actually, he switched to post types too. Anyway, yeah, a combined effort would be a lot better.

        • Mike Schinkel 9:53 pm on July 8, 2010 Permalink | Log in to Reply

          Yes, I tool would really like to see one effort rather than several.

        • Justin 4:01 am on July 9, 2010 Permalink | Log in to Reply

          I tried to get involved months ago in the bbPress plugin project, but nothing really ever came of it, which is one reason why I’ve been doing my own thing.

          Ideally, I’d move my efforts over to the bbPress plugin so we could all work together, but I’ve got project deadlines that I want to meet right now and don’t want to risk more delay (though I’m not sure where the bbPress plugin is at right now).

          I do want to keep tabs on the bbPress plugin because I’d like for users to be able to easily switch from one to the other without a lot of hassle. If anyone wants to talk about how to best store data for the forums, don’t hesitate to shoot me an email. I’ll be happy to hear your thoughts.

        • John James Jacoby 7:38 pm on July 9, 2010 Permalink | Log in to Reply

          Justin, would be happy to have your experience in on this. No reason to duplicate efforts. Let’s find time soon to pass some ideas back and forth? I know you have a deadline, where as ours is a little more relaxed (at the moment anyhow.)

          http://bbpdevel.wordpress.com

    • mark. 8:27 pm on July 8, 2010 Permalink | Log in to Reply

      JJJ/PeteMall, drop me a line if you’re in the market for any more hands on the bbPress team. That’s a project I’ve been interested in seeing happen for quite some time!

    • Sergey Biryukov 8:27 pm on July 8, 2010 Permalink | Log in to Reply

      I’d like to work on the i18 projects.

    • Mo Jangda 8:29 pm on July 8, 2010 Permalink | Log in to Reply

      I’m interested in helping; possibly either the Community, Core Integration, or bbPress groups (since their numbers seem low) — though I’m really open to anything.

    • filosofo 8:30 pm on July 8, 2010 Permalink | Log in to Reply

      Plugin Directory: Stats. SVN notifications, improvements to Trac, better stats for plugin developers (and aggregate, public download stats).

      I had mentioned interest in this when I volunteered to help, so if this team can get off the ground I’d like to participate.

    • dremeda 9:24 pm on July 8, 2010 Permalink | Log in to Reply

      Let the fun begin :)

    • kevinjohngallagher 8:37 am on July 9, 2010 Permalink | Log in to Reply

      Is there any chance we can not call the wordpress forum plugin the “bbPress plugin”?

      We have bbPress0.9 and bbPress1.0 (both incompatible, both only reffered to as bbPress), BuddyPress, the bbPress plugin for for BuddyPress (also incompatible with bbPress0.9 & bbPress1.0) and now the bbPress plugin (incompatible with both versions of bbPress and the bbPress plugin for BuddyPress).

      That is 4 pieces of software, all unique, all incompatible and all using the same name.

    • Gautam 9:22 am on July 9, 2010 Permalink | Log in to Reply

      That’s nice! I’d like to be in the bbPress team if possible – I’ve been contributing to the project for some months now.

    • Aaron D. Campbell 9:17 pm on July 9, 2010 Permalink | Log in to Reply

      I was on vacation for the last two weeks, so I missed out on a lot of this, but I’d be happy to help with either “Plugin Directory: Core Integration” or “Plugin Directory: Stats” when they get started. If those don’t end up happening, I don’t mind helping with something else.

    • Milan 10:24 pm on July 9, 2010 Permalink | Log in to Reply

      i18n Projects. Improving the management of localized plugins, and also providing better tools for localized communities.

      I think that this should be done in Plugin Directory: Core Integration since most of it is related to description of that team. There is already tool (GlotPress), we just need to connect it with plugin repository.

      Though someone could help Nikolay on GlotPress development.

  • Andrew Nacin 7:34 pm on June 24, 2010 Permalink
    Tags: 3.org, ,   

    Agenda for June 24 developer chat.

    • Review of 3.0 feedback – incoming ticket rate, common issues, etc. – All
    • Trac Changes – Nacin/Mark
    • Next steps: 3.org and 3.1 – All
     
  • Jen Mylo 5:35 pm on June 24, 2010 Permalink
    Tags: 3.hiatus, 3.org,   

    Hiatus 

    This post is meant as prep for the IRC dev chat taking place in about 3 hours, *not* as an official done deal announcement/dictate/decision, so please take it in the spirit in which it’s being offered. This is how we think it should work, and after the dev chat we’ll do a gut check to see if it still makes sense.

    “We’re taking a dev cycle off after 3.0 to focus on the wordpress.org site, plugins, and community improvements.” Ever since that idea was put forth, there have been people wildly in favor and wildly opposed. Let’s all relax a little. Here’s the general thinking of the core team:

    • Take a two month hiatus from core before beginning discussion of scope for/development on version 3.1. Obviously, security fixes and/or major bugs would still get a point release if needed in that time.
    • Identify a handful of projects that can be completed in 2 months that would make the WordPress experience appreciably better, whether it’s related to support, plugin developer infrastructure, or anything else. Taking comments on this in the forums at this thread.
    • Identify contributors who want to be part of this effort and are willing to make a specific time commitment of x hours per week for two months, as well as which mini-projects most appeal to them.
    • Put together teams from the volunteers, small ninja/pirate teams of 3-5 developers who can crank out code like [insert a metaphor better than the one that came to mind for me, 'cranking out spaghetti from a pasta maker,' which is terrible]. Add a consulting member of the UI working group so things all work/look consistent. Add a lead/commit-level dev to each team to guide the project.
    • Have each team agree to the scope of its project, create a timeline for the 2 months, and start by writing an announcement post for their improvement (this helps focus the scope and gives you a tangible goal for completion).
    • We’ll give team members author rights on this blog, and each team will post an update at least once per week, using the tag that we identify for the project, so interested community members can follow along with the project feeds.
    • Launch improvements as they are finished (they don’t all need to wait until 2 months have elapsed).
    • Bask in glow of appreciative WordPress community and your own heightened sense of awesomeness for volunteering your time and being a part of something bigger than yourself that affects tens of millions of people on a daily basis.

    Think of it like the hiatus that TV actors take in between seasons: just long enough to do a movie and get re-inspired to tackle the next season’s character blah blah blah. This will only work if we really stick to our guns and focus on .org projects; if we’re debating things all over trac at the same time, attention will be divided and we won’t accomplish the goals of the two month project sprint.

    This can also serve as an experiment in forming mini-dev teams for discrete projects, which is something that has been discussed as maybe worth trying for core feature development.

    We’ll discuss all this in the dev chat today. After the dev chat is over, people interested in participating in the 2-month .org project sprint should leave a comment on this post. We’ll organize it kind of like we did for choosing GSoC students and mentors: Identify your most useful/relevant dev skills, what potential projects you would most like to be involved with, if there’s anyone you’re particularly interested in collaborating with, etc. On Monday we’ll see what we’ve got and try to put together some appropriate teams.

    The more we can approach this experiment with a positive attitude, the more likely it is to succeed.

     
    • dremeda 5:39 pm on June 24, 2010 Permalink | Log in to Reply

      This makes Dre smile :) Awesome. See you in the channel.

    • Aaron Jorbin 9:25 pm on June 24, 2010 Permalink | Log in to Reply

      Count me in as a part of the inline documentation team and as a tech editor on handbooks.

    • Mike Schinkel 9:27 pm on June 24, 2010 Permalink | Log in to Reply

      I’d like to help with “Plugin Directory/Infrastructure”

    • Dan Cole 9:36 pm on June 24, 2010 Permalink | Log in to Reply

      I’ll help with the “WordPress.org Profiles”.

    • Dougal Campbell 9:48 pm on June 24, 2010 Permalink | Log in to Reply

      My free-time is sparse, but I’m willing to help with anything. In particular, though, the Plugin Directory improvements and forum project are interesting to me.

    • Beau Lebens 9:50 pm on June 24, 2010 Permalink | Log in to Reply

      I’m in for something around one of the following: profiles, plugin infrastructure, mentorship.

      For the record, I will only be a part of a ninja team. Ninjas FTW.

    • Eric Marden 9:59 pm on June 24, 2010 Permalink | Log in to Reply

      Count me in.

    • Jacob Santos 10:00 pm on June 24, 2010 Permalink | Log in to Reply

      Handbooks: Plugin Dev and Core Contributor. I would like to be contributor to both of these items, could also help getting the phpdoc into the site dynamically to reduce the work required and focus on improving the inline documentation in core first and then focus on the handbooks with examples and longer descriptions.

    • Mark Jaquith 10:39 pm on June 24, 2010 Permalink | Log in to Reply

      I’m in. I’d like to make WordPress.org a great place for plugin authors to support their plugins. Give them the ability to mark threads as resolved. Separate people talking about “stats” from people talking about the plugin with the slug “stats.” etc

    • Lisa Sabin-Wilson 10:48 pm on June 24, 2010 Permalink | Log in to Reply

      Jane, I’m in on the documentation aspects and as tech editor for handbooks – and wherever else I can be useful…time has opened up a bit this summer, so could like to help where possible. thx!

    • Andrea_Arrrrr 10:48 pm on June 24, 2010 Permalink | Log in to Reply

      Documentation, codex, handbook, training, welcome committee.
      Anything related to mu.wordpress.org reorganization post-merge.
      Count on an afternoon a week.

      Team Pirate ftw.

    • filosofo 11:03 pm on June 24, 2010 Permalink | Log in to Reply

      Here are some things I’d like to see improved or appear on WP.org and so would be happy to help implement. I’m also able to help with other stuff that needs it, so just ask.

      • Having an API that exposes all the (aggregate) data on plugins and WP install information collected by phone-home.
      • Making the profile page show accurate information in general, but particularly about the user’s plugins.
      • Making the profile page show activity in a manner that makes sense, is complete, and is accurate.
      • Showing my WP.org forum responses in reverse chronological order of their most recent activity (not as currently, my activity), so I can see the threads that have the most recent replies from other people. A related feed of those replies would be great.
      • Being able to receive an email (or subscribe to a feed) that notifies me when someone creates or comments on a forum topic concerning one of my plugins.
      • Enabling plugin search that has relevant results (I do have experience with Sphinx if that’s any help).
      • Publishing how to contact someone if there’s a problem with WP.org (currently there doesn’t seem to be any publicized way to contact anyone).
      • Mike Schinkel 11:12 pm on June 24, 2010 Permalink | Log in to Reply

        +1 on all that, but especially “Having an API that exposes all the (aggregate) data on plugins and WP install information collected by phone-home.” (Can we make it RESTful?)

    • Ron 11:07 pm on June 24, 2010 Permalink | Log in to Reply

      I won’t have any time immediately, but I’ll start having time available in about 4 weeks. I’ll volunteer to pitch in on support infrastructure for plugin/theme support or bbPress as a plugin.

      • Ron 11:08 pm on June 24, 2010 Permalink | Log in to Reply

        If there are lots of volunteers for those then I would be up for other things.

    • dremeda 11:21 pm on June 24, 2010 Permalink | Log in to Reply

      I’m in on the UI area for plugins. I am also interested in with mentoring, website content, mailing lists and forums.

    • Ken 12:37 am on June 25, 2010 Permalink | Log in to Reply

      I volunteer anywhere. I’ve some interest in codex/docs but I’ll help where needed.

    • Justin Shreve 3:58 am on June 25, 2010 Permalink | Log in to Reply

      I know my actual GSoC project is already a piece of this but count me in for some of the other ideas work.

      Once the base theme is done (around GSoC midterm) I could do some 3.org related changes with the theme. For example I could make a child theme for my project so the installation matches wordpress.org. This would also be a nice example on how to create child themes for my project and could be wrapped up in my GSoC scope. We can also tie in with profile improvements, etc at this point.

      I could also work on the migration of old ideas from the bbPress system and work on re-categorizing, applying “official” resolutions etc. This could probably use a team as well.

      In addition this would also give me a HUGE testing ground and would be great for the project.

    • Andrew Nacin 5:33 am on June 25, 2010 Permalink | Log in to Reply

      I’m in. I’d like to make a killer API reference. I envision something that takes the best of api.jquery.com or php.net, fully leverages all of the core source and its inline documentation, and tightly integrates with the manuals.

      I’ll also volunteer to guide and edit the core contributor handbook.

    • Rafael Poveda - RaveN 7:36 am on June 25, 2010 Permalink | Log in to Reply

      I’m in for Codex and Docs too.

    • Mark McWilliams 8:47 am on June 25, 2010 Permalink | Log in to Reply

      I’m not sure how I could help, but I’d like to do something! :P

    • Ben 9:01 am on June 25, 2010 Permalink | Log in to Reply

      I’m in for website content and anything UI related.

    • Brian Layman 1:45 pm on June 25, 2010 Permalink | Log in to Reply

      I’m in as well. I really like the idea of dedicating a specific number of hours each week and dividing into teams to help us achieve our goals. The mutual responsibility will definitely help this be a success. I can devote a solid afternoon each week at least. That’s beyond the typical project communications that would occur every day and the IRC chat.

    • Stephanie Leary 2:29 pm on June 25, 2010 Permalink | Log in to Reply

      I’d like to help with documentation.

    • Naoko McCracken 3:04 pm on June 25, 2010 Permalink | Log in to Reply

      I’d like to help around WordPress.org site i18n (content-wise) and anything with WordCamp.org. I can offer some frontend help as well where needed.

    • Gaston 3:57 pm on June 25, 2010 Permalink | Log in to Reply

      This is awesome. I’m definitely in. I would love to help with the UI/UX side of things for the theme and/or plugin directories, or the .org profiles. I can also do frontend work.

    • mrmist 7:13 pm on June 25, 2010 Permalink | Log in to Reply

      Not sure what happened to my comment here, so I’ll try again. Count me in for Forum or Codex related stuff, or any general tasks that don’t need elite php skills

    • Ryan McCue 1:41 am on June 26, 2010 Permalink | Log in to Reply

      I’d love to help out with anything WP.org related, but I’m not sure how much time I’ll have, but I should be able to contribute at least a couple of hours a week.

    • xavier 3:11 pm on June 26, 2010 Permalink | Log in to Reply

      I’m in for anything related to content, local communities, documentation, l10n/i18n and such. I’m currently in the final sprint to update the FR book on WP, but should be good to go by mid-July.

    • demetris 11:08 am on June 27, 2010 Permalink | Log in to Reply

      I made a proposal on Trac that I believe would fit well as a part of 3.org:

      http://core.trac.wordpress.org/ticket/14087

      (Set up team to evaluate web-hosting providers for WP.org recommendations)

    • Peter Westwood 7:26 am on June 28, 2010 Permalink | Log in to Reply

      I’m in for work on Profiles, Plugin/Theme infrastructure

    • Brian Layman 5:37 pm on June 28, 2010 Permalink | Log in to Reply

      Since I hadn’t mentioned specifically what I wanted to help with, let me say so now.
      Either or both of these projects would be my choice:
      *Plugin Directory/Infrastructure
      *WordPress.org Profiles

    • TECannon 6:02 pm on June 29, 2010 Permalink | Log in to Reply

      Forgot to say that I’m interesting in helping with wherever I’m needed. (IA, UX, etc.)

    • Glenn 2:01 am on June 30, 2010 Permalink | Log in to Reply

      I’d love to help out with WordPress.org plugin infrastructure… anything really. Can I help with WPMU? It doesn’t look like it’s had any forward momentum for since right after WordCamp SF 2009 ;)

    • John James Jacoby 8:54 pm on July 1, 2010 Permalink | Log in to Reply

      I like helping.

    • Brad Williams 9:08 pm on July 1, 2010 Permalink | Log in to Reply

      Sign me up!

    • Sergey Biryukov 11:39 pm on July 1, 2010 Permalink | Log in to Reply

      I’d like to work on:

      Having the WP.org Plugin Directory available in different languages, along with the plugin descriptions and installation instructions.
      Displaying user’s local support forums responses and local Trac activity on the profile page.
      Anything else related to i18n/l10n in general, improving the Plugin Directory or WP.org Profiles.

    • Christopher Ross 3:26 pm on July 2, 2010 Permalink | Log in to Reply

      I can help with the plugins directory, improving the RSS feeds etc.

    • Alex M. 8:52 pm on July 2, 2010 Permalink | Log in to Reply

      Andrew reminded me that I have yet to reply. Whoops.

      I’m pretty busy of late with work, but I’d love to help out in any way I can.

    • Matt Martz 12:42 am on July 3, 2010 Permalink | Log in to Reply

      Andrew gave me a little kick as well. I am leaving for Greece in under 2 weeks and will be gone for a little over 3 weeks. When I get back in the second week of August I’ll check in to see if any teams need some help.

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel