open help – Make WordPress Documentation

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 WordPress.org Plugin Directory https://wordpress.org/plugins/ 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 WordPress.orgWordPress.org 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. https://wordpress.org/. 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.

Notes:

#ideas, #open-help

At the docs chat last week I raised the possibility of having a documentation sprint at the Open Help Conference in Cincinnati in June. The conference is two days on 15th & 16th June, followed by a three day documentation sprint from 17th – 19th June. The great thing about doing it here is that we get to meet and learn from other OS documentation projects such as Mozilla and Gnome. Also, the venue and all of the practicalities are taken care of for us. We’ve just got to write.

I would like to bring a team of WordPress people out there to run a documentation sprint to tackle the following tasks:

completing the theme and 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 WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party developer handbooks
populating and organising the new code reference
possible other project depending on who attends and how many people we have.

The aim is for high impact in a short space of time. I’m open to suggestions for other projects so please feel free to run them by me.

I’m looking for both writers and developers to come along. So if you’re a developer and you’ve always wanted to get involved with docs, we would love to have you.

There will be some funding available but this will be largely for people who have already gotten involved with the WordPress project. I have gotten in touch with some WordPress businesses already, who have said that they will send an employee. So ask your boss – or ask me to ask your boss 🙂

If you run a WordPress business and you’re reading this, this is a great opportunity for an employee to improve their documentation skills while giving back to the project.

If you are planning to come, please keep in mind that this will be a working trip. You will be writing for three days, although we should have time to to squeeze in a bit of fun somewhere (not that writing documentation isn’t fun!)

Please fill in one of these two forms:

I’m going to be figuring out my budget this weekend so the application for financial assistance will close on Saturday 22nd April, 23:00 UTC. I’m happy to answer any questions on the thread here, or in the chat on Thursday.

Note: please don’t book tickets to the conference until everything is finalised

#open-help, #sprint

Want to get involved?

Weekly meetings

Tag Archives: open help

Ideas for Docs and Support from the Open Help Conference