Suggested roadmap

After Tuesday’s meeting the conversation continued in SlackSlack Slack is a Collaborative Group Chat Platform The WordPress community has its own Slack Channel at and I suggested a step process we should consider following. As we do with everything, I’m putting it up here to ensure that everyone gets to see it.

Before I dive in, a few other things need to be pulled out from the Slack conversation:

  • Lets consider changing our name to Theme team (or variation). I will add lets not acronym everything it’s not cool for new people. Why should we change our name? We now have the option to encompass everything that effects themes including the directory.
  • Lets do research before we jump. We have a lot of opportunity to make something amazing here so lets do it right.

It’s worth noting that steps 1 and 2 do not need to be done chronologically. If we are happy with the baseline tests (we may already be) on upload, we should do 2 as soon as we can.

1. Research:

This phase consists of user testing and surveys with mind to change. These will focus on the 3 main areas: using themes, getting a review and the theme directory. This is not a time to get hooked up on small details or theme directory proposals yet. Without a solid research phase any proposal will not hit the mark.

Also mentioned something we absolutely should do and that’s do comparative research of .com, theme forest and other directories.

Surveys are going up in next few days here thanks to @melchoyce working with me on them.

I would also suggest this is an ongoing phase. Once we have plans we should also be user testing those.

2. Review:

Ensure our base test is solid enough to cover security issues on theme upload. We may be there already. Remove the queues and have all themes uploaded for a time period without human curation. We need to add in a report button to this. We also need a report still so we can check themes. TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub. tickets being created still would help us do that and be able to easily pull themes back out of being live.

It’s important to note that a reviewers job would then be really broken down into the following points:

  • Education
  • Reviewing queues to check for duplicates and issues (sanity checking)
  • Maintenance of our tools
  • Directory
  • Theme preview and demos
  • Point of contact for anyone with a theme in the org directory or wanting to have one
  • Theme trac tickets
  • Reviewing and tackling reported themes queue
  • Handbook and guideline curation and publicity. WordCamps and other events allow us to make the review process and what team does known. We are going to shift to enabling theme creators so passing on skills is important.

Worth noting, there are a lot of things this still needs us to do. We are not removing the need for this team, just changing it’s focus and optimising the people we have.

3. Directory:

This should only be done after the research and is the only phase that depends on another. What we do here should for now be seen as an empty box. This is whatever we want it to be, lets keep an open mind and not get caught on small details. We can’t plan for something we’ve not researched.

4. Education:

This is a perpetual phase and one we’ve been starting to be strong with recently. We need to increase what we do here and really help the community.

5. Design reviews and advanced theme reviews:

Once everything is in place we can review with mind to tagging the directory and also get a way people can even request reviews maybe (we have to research that people would want that). Having people that can review the themes and tag them with specific skills sets is really going to be a powerful thing.

With all this in mind I suggest that next week’s meeting focuses on research reporting back on status and the review phase. Lets also discuss this roadmap. We should have a goal of working out what the security and sane minimum is (emphasis on minimum).