Ideas for Docs and Support from the Open Help Conference

I’ve been at the Open Help conference in Cincinnati all weekend. Below are some of the ideas that I thought could have a particular impact on WordPress. I also took notes on all of the talks on my blog, there’s links to those at the end.

Jerry, Ryan, Mike, and Maria – feel free to add any of your own suggestions in the comments.

Indexing support forums

A lot of our support traffic is from Google, so people are searching for issues and then landing on the support forums. However, they are often landing on results that are completely out of date. For example, if you search for “WordPress permalinks not working” there are search results from three years ago and fix years ago. If you search for “WordPress 403 forbidden” pulls up results from 4 years ago. Should we prevent Google from crawling forums results over a certain age in order to help these searchers more easily find the content that they need?

Stack Exchange

How can we better support the work that goes on over on WordPress Stack Exchange? Should we get the moderators there more involved with the Support/Docs team? Should be look at ways that we can direct our more technical users & developers to Stack Exchange which they might find more suited to their needs?

User Advocacy

Should we have people on the support team act as user advocates and be more actively involved with WordPress development? WordPress is a user-focused product but there is little interaction between the development process and the support team. User advocates could act as a bridge between the developers and users. They could have responsibility for opening tickets based on feedback in the support forums, attend development meetings to raise questions from the perspective of users, and generally get involved with coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

Best Practices for Plugins

Mozilla has Project Squeaky to improve user experience for add-ons. They actively work with developers to ensure that users have a good experience. Many issues with WordPress come from third-party plugins – is there a way that we can help developers make plugins better? Some suggestions are best practices for pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the Plugin Directory or can be cost-based plugin from a third-party developers, a better plugin developer handbook, code templates that people can use for their plugins.

Better Integration Between Support Methods

Can we improve integration between the support forums and documentation? Could we suggest documentation pages based on the question that someone asks? Can we use apps like text expander or Alfred to create responses with links, best practice, and good suggestions, that forum moderators can use to help them deal more efficiently with support requests?

Analytics and Optimization

We should do some advanced analytics to find out what users are doing with documentation, how they’re finding it, what they’re clicking on. It would also be useful to do some user testings for common things that users are doing with WordPress: for example, finding and installing a WordPress theme, searching for plugins on the internet, finding documentation. Our users aren’t only users while they’re in the WP admin or even The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. What are they doing on Google? Where are they going for support? User testing can also be carried out to see how effective our documentation is.

Support for different versions of WordPress

There is a lot of information in the Codex relating to different versions of WordPress – some go back as early as WordPress 1.5. It makes no sense to have these in the Codex any more. We should also adjust the terminology for user documentation when new features are introduced the Codex says things like “Post formats is a theme feature since version 3.1“. While this is appropriate for APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. documentation, it makes no sense for user docs. Our documentation should reflect the current version of WordPress only.


#ideas, #open-help