@jhoffm34 and I have been reviewing the content in the Codex. I exported all of the pages from Google Analytics and then we’ve sorted them into groups of similar content types to see what emerges. You can view the spreadsheet here: https://docs.google.com/spreadsheet/ccc?key=0AnxB9WffF3jOdEFWYWozTGtvNlQ5WGFTQTAxTG55R0E&usp=sharing
The content we analysed broke down broadly into these different areas:
- Installing WordPress
- Getting Started
- Site Builder
- Multisite Multisite is a WordPress feature which allows users to create a network of sites on a single WordPress installation. Available since WordPress version 3.0, Multisite is a continuation of WPMU or WordPress Multiuser project. WordPress MultiUser project was discontinued and its features were included into WordPress core.https://codex.wordpress.org/Create_A_Network.
- Administration (inc Security?)
- Getting Help
There are also about 60 reference pages for the various Panels/Screens. e.g. https://codex.wordpress.org/Administration_Panels
- Setting up a Development Environment
- How WordPress Works
- Code Reference
- Plugin 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
- Theme Developer
I am keen to have a strict division between the user-focused material and the developer-focused material. Of course, there are times when a developer will be a user (when they are managing their website) and there are times when a user will be a developer (when they tweak their theme) but linking between resources is more effective than putting the user and developer material together.
I’m reluctant to make major plans for restructuring and changing everything around before we close the Codex survey and analyse the results (some of which are surprising i.e. not everyone hates the Codex), however, I would like to come up with some concrete tasks for the Docs Sprint in a few weeks.
Therefore, I suggest that the team at the docs sprint tackle the following handbooks that can be built on learn.wordpress.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/:
- Site Builder Handbook
- Blogging Handbook
- Editor Handbook
- Theme Developer Handbook
Thoughts? Complaints? Suggestions?
Since we’re revving up for the 3.6 release and a Codex Sprint, this post will serve as our “master changes list” for 3.6. This list is by no means complete, so leave a comment if you feel like something is missing. We’ll update it as we go. If you’ve completed a todo item, let us know and we’ll check it off for you.
Multisite Multisite is a WordPress feature which allows users to create a network of sites on a single WordPress installation. Available since WordPress version 3.0, Multisite is a continuation of WPMU or WordPress Multiuser project. WordPress MultiUser project was discontinued and its features were included into WordPress core.https://codex.wordpress.org/Create_A_Network.
‘needs-codex’ Trac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. tickets
>> Look for the Trac comment where needs-codex was added for more info
Audio / Video
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 plugin 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
The first WordPress codex Living online manual to WordPress.org https://codex.wordpress.org/ sprint was a success! A bunch of us got together in the #wordpress-sfd chatroom and ploughed through the majority of the docs. You can see how successful we were by checking out our to-do list.
There are a few things left on the list so if anyone could tackle them and let me know so I can tick them off that’d be great. The final bits and pieces are developer docs.
Some things that we learned:
- documentation sprints are a great way to get through a lot of documentation at once.
- it is important to have some developers involved who can deal with the ultra-developer stuff and field questions
Anyone learned anything else? Add it to the comments so I can add it to the list.
Thanks to the following people for working hard to get the docs updated: Jerry Bates (@jerrysarcastic), Jonathan Wold (@sirjonathan), Philip Erb (@philerb), Curtis McHale (@curtismchale), Mika Epstein (@ipstenu), Jason Hoffman (@jhoffm34), and Marko Heijnen (@markoheijnen)
Special thanks to Drew Jaynes (@drewapicture) who hasn’t just been a rockstar, he’s been a superstar. Thanks Drew!
I’d love to see more documentation sprints in the future. As well as having them virtually, they could be organised at WordCamps to coincide with developer activity. Some ideas for future sprints:
- updating the function reference and making sure that everything has examples
- cleaning out old content
- updating out-of-date pages
- re-working the FAQs
- making a dent in the handbooks
- working through the Help Tabs
If anyone else has any suggestions for future documentation sprints, and how often they think they should be, do leave a comment!