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?

#3-org, #core-contributor-handbook

/extend is currently being upgraded. Cur…

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

#3-org, #infrastructure

API status check

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.

#3-org, #api

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.

Continue reading

#3-org, #handbooks, #plugins

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.

#3-org, #plugin-directory

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

#3-org, #handbooks, #plugins

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.

#3-org

Agenda for June 24 developer chat. – Rev…

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

#3-org, #agenda, #trac

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.

#3-org, #wordpress-org