Currently, there is a delay between tickets being closed as “Approved”, and Themes being made live in Extend (“Extend” is no more) the Theme directory. This delay exists for two reasons: one, because the synchronization between Theme-Trac and the Theme directory is manual, and two, because Admins do a final audit of “Approved” tickets before making the Themes live. (Because we have so many volunteer reviewers, and don’t have the time or resources to implement any kind of formal training process, we basically give anyone who wants to review Themes, and shows the initiative to get involved, the privileges necessary to assign/resolve/close Theme-Trac tickets. So, the compromise is that, for tickets resolved as “Approved”, the Admins add in an extra, quality-control step before making those Themes live in the Theme directory.)

Because of that delay, the Admins have asked for up to a week to complete the synchronization to make Themes approved in Theme-Trac live in the Theme directory. While this delay is (unfortunately) not a huge additional amount of time to wait for most Themes in the queue, for currently approved Themes, the delay prevents end users from getting bugfixes or security updates for Themes they currently use.

Because it is especially important for updates for currently approved (and currently in-use by end users) Themes to be made live in the Theme directory as quickly as possible, I would like to propose a change to the Review process: to reserve the Priority #1 Queue (i.e. currently approved Themes) for review by Admins, who can review, approve, and synchronize those Themes immediately, rather than sorting through the queue of approved Themes waiting to be synchronized.

I’ve added a poll. Please leave any additional comments or feedback in the post comments.

So, how did we do?

As it currently stands, the review queue is at approximately 50 tickets, with 260 tickets closed in the past 7 days, by 28 reviewers. Special thanks to @gpriday, @nishasingh, and @life.object, who each closed more than 10 tickets each; and @slobodanmanic, @mercime, @labor4it, @jcastaneda, @Frank_Klein, and @Fingli, who each closed at least 5 tickets each.

(Note: you can now see real-time stats for the past 7 days, here.)

As it now stands, we have completely cleared the Priority #2 queue, which means that we have no unassigned tickets older than two weeks. Fantastic job on that front as well, since any tickets that wind up in that queue represent developers who have been waiting at least 2 weeks just to get feedback on their Theme. (Ideally, we will never have any tickets fall into the Priority #2 queue.)

But even better: we now only have 15 unassigned tickets older than one week. While I see the Priority #2 queue as an indication that we’re really not getting the job done, I would love to make it a goal to keep the number of Themes older than one week at zero as well. Getting to the point where the team can turn around all tickets in a week or less, on a regular basis, would be a huge improvement, and would, I hope, keep the developers happy who submit Themes.

So, let’s see if we can get that queue of 50 Themes knocked out (we last saw review queue “Inbox zero” over a year ago, IIRC), and then see if, from a fresh start, we can keep the number of tickets open longer than a week at zero.

As always, thanks everyone for your contributions. We know that this is a volunteer activity, and that contributing to the Theme Review Team takes away from valuable time spent elsewhere.

The most likely occurrence of this issue is with Themes developed using Twitter Bootstrap. When reviewing such Themes, please be sure to check that, if the Theme is licensed under GPL, that the license specifies either unversioned GPL, or GPLv3.0.

(And if for any reason this interpretation is incorrect, please discuss in the comments.)

Edit

Note, by “unversioned” GPL, I am referring to the current version of the GNU GPL, which can be found at this URL, and which currently is GPLv3.

What is important is the actual license text associated with the Theme: whether called simply “GPL” or explicitly GPLv3, the license text must be GPLv3. A Theme that claims the license is “GPL”, but that ships with a license.txt that is GPLv2 would not be able to bundle an Apache 2.0-licensed work.

We would like to know: what is it that you as an author don’t like or really want to change around Theme Review and our entire process?

(no personal agendas please, we do see quite enough of that around here lately)

We’ll call it the “end of February” push, but we can use the weekend, too.

There are almost 150 tickets awaiting review.

We have about 90 people with close-ticket privileges.

That’s less than one and a half tickets per reviewer, by the end of the weekend.

Who will commit to reviewing 1-2 tickets between now and Sunday?

• Themes are not to use WordPress in their name. For example My WordPress Theme, WordPress AwesomeSauce, andAwesomeSauce for WordPress would not be accepted. After all, this is the WordPress Theme repository.
  • Themes are not to use the term Theme in their name, such as: AwesomeSauce Theme. Same reason as above … it’s a Themerepository.
  • Themes may use the WP acronym in the Theme name, such as WP AwesomeSauce.
• Themes are not to use version-specific, markup-related terms (e.g. HTML5, CSS3, etc.) in their name.
• Themes are not to use related terms (e.g. Blog, Web Log, Template, Skin, etc.) in their name.
• Themes are not to use Theme author/developer credit text in their name. For example AwesomeSauce by John Q. Developer(makes for a much better credit link); or, SEO/SPAM-seeded text, such as: AwesomeSauce by Awesome Free WP Themes (this is just not going to pass).
• Themes are not to use related Theme names (e.g. WP Twenty Eleven, Twenty Eleven WP, The Twenty Eleven, etc.) in their name.

In light of recent discussions, I think this would be a good time to clarify these guidelines. Please discuss below if you have any comments, questions, or feedback related to the Theme Name guidelines.

WordPress

The requirement not to use the term WordPress in a Theme Name should be obvious; all Themes hosted in the directory are WordPress Themes.

Generic Terms

The following Guidelines relate to the use of generic terms:

• Themes are not to use version-specific, markup-related terms (e.g. HTML5, CSS3, etc.) in their name.
• Themes are not to use related terms (e.g. Blog, Web Log, Template, Skin, etc.) in their name.

These are the guidelines that I think are the least articulate, and need clarification.

The intent is to avoid generic terms related to design elements, features/functionality, or intended use of the Theme. Whether that’s markup (HTML5, CSS3), design (responsiveness), features/functionality (photo galleries, jQuery masonry), or intended use (“Tumblogging”, real estate, business), terms related to these aspects are better left to the Theme description and, where applicable, filter tag keywords.

The purpose of a Theme name is to ascribe an identity to the Theme through the uniqueness of that name.  It is perfectly fine to invoke design elements or intended use of the Theme through the Theme Name, but it should be done using a creative/unique term, rather than a generic term. The intent of the related Guidelines here is to emphasize this point, and to help avoid naming conflicts and disagreements that arise from the use of generic terms.

Developer name

As with the WordPress term, I think this one is self-explanatory.

Reserved Core Theme Names

The WordPress Core team has chosen a naming convention to use for the annually updated Theme distributed with core. Thus, it makes sense to ensure that this naming convention is reserved for core.

Should the Theme Directory host “Coming Soon” Themes? If so, how should we handle them? By design, Coming Soon Themes would omit some functionality (e.g. comments) that would get flagged/blocked by the uploader script, and by design such Themes would obviously not pass the Theme Unit Tests. And what would be the requirements for such a Theme?

One suggestion for handling uploads/reviews: rather than having to whitelist Coming Soon Themes in the uploader, perhaps we could add a new tag, e.g. “coming-soon” (or whatever), that the uploader script could check for, and that the Theme Reviewer would note during the review.

What are your thoughts?

Rather than making decisions (or creating new Guidelines) on the fly, let’s discuss those questions, and the issue of branding vs. “white labeling” as a whole, here. What I would envision coming out of this discussion would be a clarification of the Guidelines, to indicate more clearly what we’re currently requiring/enforcing, under a “Theme Branding” heading (or similar) that would envelop the existing “Credit Links” requirements.

For example: logos. Some Themes add a “logo” Theme option, but set the default as a text-as-image Theme Name “logo”. This is obvious branding, and obviously an instance where the user would rather have the Theme default to displaying the user’s configured Site Title, rather than a Theme-branded text-as-image “logo”. But a different developer may want to display a generic/arbitrary logo by default, to demonstrate the Theme’s custom logo feature. So: we should discuss where/how we want to draw the line of appropriateness.

In a discussion such as this one, my default position is: with all else equal, which decision is in the best interest of the end user? But it is equally important to consider the needs and interests of developers, as well. Guidelines should not be onerous or unreasonable for developers. I would contend that, when initially activating a Theme – whether on a new site or a site with established content – an end user will not want then to have to go through the Theme to “disable” the demo/branding content. So, I think it is reasonable to require that all default/demo imagery be generic/non-branded/”white-labeled”.

To take a counter example: footer credit links. Should developers be required to make footer credit links user-configurable (i.e. able to be disabled) via Theme option? I don’t think so. We put enough requirements around the form/display of footer credit links to ensure that they are appropriate, that I think requiring them to be user-configurable via Theme option crosses the line into being too onerous. (Consider all the Themes that have no Theme options; should we force developers of those Themes to incorporate all the overhead of Theme options, just for footer credit links?) What might be more reasonable, however, would to to recommend that footer credit links be user-configurable, via Theme option, custom filter, template-part file, etc.

Feel free to discuss from both high and low levels: from principle to guideline. But, please try to avoid the, “but Theme X does this” type of arguments. That we are discussing the need to clarify the Guidelines implies that existing Guidelines have been interpreted differently, resulting in different review comments for different Themes. Our aim here is to find consensus regarding the correct approach to handling these issues, regardless of how these issues have been handled consistently or inconsistently in the past.

Twenty Thirteen is ready for feedback and testing in core: http://make.wordpress.org/core/2013/02/18/introducing-twenty-thirteen/

Our goal is to have it ready along with the rest of 3.6 for an April launch. Would love your eyes on it for testing, performance, tying in with core features, all that good stuff.

Also noting several theme-related core tickets, if anyone wants to jump in with comments, patches, and testing:

• HTML5 for wp_list_comments() and various other comment markup: #20088, #15080, and #15081
• Standard theme hooks: #21506

We’ll have open office hours Tue/Thu throughout the cycle (see http://make.wordpress.org/core/ sidebar for times), so hope to talk with you soon.