WordPress.org

Ready to get started?Download WordPress

Theme Review Team

Updates from February, 2012 Toggle Comment Threads | Keyboard Shortcuts

  • Jen Mylo 6:19 pm on June 20, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Team Meetup at WCSF 

    Hi again! We’re working on making sure we have enough room blocks to make sure all the contributors who are coming in October can get a decent rate (or have a room provided by us if applicable). Some of you replied to my post from last week and filled in the survey so I’d know you were planning to come, but some haven’t. Additionally, some people did the survey and marked themselves as team members of teams they’re not actually involved with, so I need your help! :)

    I just want to make sure we count everyone so we can try to put you at the same hotel to make the meetup part easier.

    If you didn’t read the post before, the plan for the event is:
    Sat/Sun — WCSF conference
    Monday — community summit
    Tues/Wed — team meetups (team being together to talk issues, make plans, work together, etc)

    The people who identified themselves as active members of the theme review team in the survey are:
    @jcastaneda, @cais, @otto42, Tammie Lister (@karmatosed), Aleksandra Łączek (@alex27), Sakin Shrestha (@Catchtheme), Ayman Al Zarrad (@aymanalzarrad), and Joe Dolson (@joedolson).

    Notably, @chipbennett and @emiluzelac are missing. :) Could you guys fill out the survey so I can have you on the list as we start deciding which hotels to put each team in (this applies to anyone on the team planning to come who hasn’t submitted this survey yet). We’ll be spread out among 4 or 5 hotels, so I want to be sure we can keep the teams together. If you’re not planning to come, just let me know in the comments.

    @emiluzelac and @chipbennett, could one of you let me know if the list above is accurate or if there are names on it that are not active members of the team?

    And just a reminder that we have a travel assistance program this year to help contributors who don’t work for a wp-based company and can’t cover travel costs on their own. Apply for travel assistance by June 30. IMPORTANT: if you apply for travel assistance, you still need to fill out the contributors at wcsf survey so you’ll be included in the team count as we do our planning.

    Thanks!

     
  • Jen Mylo 9:33 pm on April 18, 2014 Permalink
    Tags: incentive program   

    Theme Review Incentive Program 

    Hi theme reviewers! It seems like there’s been some disagreement about the implementation of the theme review incentive program lately. Disagreement draws attention, and once it was looked at more closely, turns out the theme review incentive program (as it exists right now) is actually kind of a problem. In this post, I’ll lay out the issues that jump out, and ask for your feedback; we’ll gather up the team opinion and take it to a conversation with Matt about what should be done moving forward.

    When this team suggested the program, I think there may have been a miscommunication about the intent/outcome, or perhaps it just sounded like such a cool idea that some of the more questionable aspects didn’t get the scrutiny they could have, but when Matt approved trying the idea as an experiment it sounded more like it would keep themes rotating through the Featured section for the benefit of users, not that people would be featuring their own themes in exchange for reviewing themes for the directory.

    Issues:

    • People choosing their own themes to feature. Basically, what this amounts to is a form of pay-for-play, where someone gives something of value (in this case reviewing time and expertise) in exchange for something of value (advertising in the form of a featured theme listing). That’s pretty much the opposite of how contributing to the WordPress project is supposed to work. No other team has that kind of tit for tat, nor should they. Recognizing contributors needs to be absolutely separate from formalized promotion of their products, businesses, etc.
    • Themes being chosen repeatedly. The featuring was intended to be a way to move more themes through that lineup (and not by putting more themes on that page), and though that page wasn’t getting the attention it deserved before the TRT program, we should still be working toward that goal. Any theme that is always on the Featured page might as well just be called a default theme; if someone thinks their theme is so awesome that it should basically be a default theme, then they should consider donating it to core as a potential base for the next year’s default theme.

    The goal of Featured Themes is to present people with a variety of quality themes they might not see otherwise. So featuring the most popular themes (which are already listed under Popular Themes) or the same themes month after month doesn’t really serve that goal. And telling people that if they volunteer their time they’ll be rewarded with advertising is pretty unfair to people volunteering in other areas of the project. Recognition is something we need to get better with, but we shouldn’t be using promotion of products — even if those products are free — as a reward. So! What does that mean for this program?

    Basically, it has to change. In talking to Matt, we came up with a few possibilities for the featured themes page:

    1. Abandon the program altogether, and use an algorithm to select featured themes to auto-rotate so there’s always something different there rather than a static selection for any period of time. Note: this is Matt’s preference.
    2. Switch to an algorithm to choose featured themes, but build in a feature for theme reviewers to suggest themes for inclusion that they reviewed and think are really good, so that it pulls from a pool recommended by TRT members (incentive or just in general, whatever).
    3. Keep the incentive program but put two rules in place: no one can feature their own theme, and no theme can be selected to be featured more than once in a six month period. That addresses both the project pay-for-play issue and the stagnation issue, but still retains the possibility of gaming the system (you choose my theme, I’ll choose yours, etc).
    4. Something we haven’t thought of but that addresses these issues.

    So. In the comments, I ask that you weigh in, with these caveats:

    1. Be constructive. No accusations, no name-calling, no anger. Just working toward a common goal. Your comment should move this conversation forward, not rehash old ones.
    2. Focus on the goals of the project and how this impacts users, the team, and the overall project, not your own personal goals. If you care about your own goals and not the goals of the WordPress project, that’s fine, but that’s not what project-wide decisions are based on, so it shouldn’t be the subject of a novel-length comment here.
    3. Think about other ways we can recognize (rather than reward) contributors on this team. Putting recognition on the pages of themes they’ve reviewed? Doing something like the about page they do for core but for the theme review team? Any and all suggestions encouraged, as long as they don’t veer into pay-for-play territory.

    Sorry if this bums you out. Hopefully we can resolve this quickly and painlessly so we can all get back to what we were doing. :) Thanks!

     
    • Rohit Tripathi 9:41 pm on April 18, 2014 Permalink

      The first 2 suggestions are actually great. Non Static featured themes is a good idea, and must be implemented. At least to experiment, to see how it goes.

    • Ulrich 9:57 pm on April 18, 2014 Permalink

      I like the first suggestion. The question that arrises, is how will the algorithm work?

      It would be nice to have a page with the top reviewers with a time filer to see for all time and for the last month. Something like the about page for core sounds good.

    • acosmin 10:01 pm on April 18, 2014 Permalink

      First two suggestions are quite awesome. It was starting to get frustrating to put a lot of time in a theme and knowing it will not get featured even a single day.

    • tskk 10:02 pm on April 18, 2014 Permalink

      #2, human input will enhance the algo results.

    • Matt Beall 10:14 pm on April 18, 2014 Permalink

      My vote is for #1 or #2, but two questions come to mind.

      First, in general, how would the algorithm work? We shouldn’t publicize the details of the algorithm, otherwise it may be able to be manipulated, but I’m curious how it would work in general.

      Secondly, how do we encourage involvement in reviewing themes? The incentive was a great way to get people involved, but it also only rewarded the top contributors, and didn’t recognize all the others. So how do we incentivize getting involved for everyone?

      One last thought: we don’t want reviewers to review their own theme, but reviewing a theme is the best way for a theme developer to understand the review process. Maybe instead of, or in addition to, an incentive program, we require or at least strongly recommend that theme developers review x theme(s) before submitting their own for review.

    • CyberChimps 10:15 pm on April 18, 2014 Permalink

      I’m glad something is being done on this front, at CyberChimps we felt the review contest was extremely unfair and biased. Our contributions these past few months felt more like extortion then they did volunteering.

      On the other hand, some consideration needs to be put in place as to which themes are featured.

      While the review process is designed to make sure all the themes on the repo are quality themes, the reality is a lot of them are not maintained, and the theme authors can’t support themes with as much traffic as a featured theme receives. Even at CyberChimps we’re struggling to maintain Responsive which is by far the most popular theme on the repo, and has been for over a year.

      We’re also not opposed to version 2.0 being considered as a default theme, but at very least we’d like to keep our work under our name if that is at all possible. @Jen please reach out to trent at cyberchimps dot com if this is something worth discussing with Matt.

      With all of this said, I’m fine with an algorithm, but the themes it should pool should be curated by a human.

      In other words, instead of the algorithm grabbing from all themes on the repo, it should only pool from a list of maybe say the top 100 themes on WordPress.org to ensure the themes are regularly updated and maintained.

      There needs to be a reliable theme author behind the featured theme to make sure it is being maintained and supported.

      • CyberChimps 10:51 pm on April 18, 2014 Permalink

        I’m fine with an algorithm, but the theme pool should be curated by a human.*

      • Chip Bennett 10:56 pm on April 18, 2014 Permalink

        Extortion?

        I would think that the 48 New Themes that are approved and Live in the directory as a result of @cyberchimpscode reviews in the past 90 days would be a point of pride – a reward in and of itself.

        That, after all, is the point of a community contributor group, isn’t it?

        As for the fairness to reviewers of the review incentive program: in those 90 days, 288 New Themes were made live, and 10 incentive winner “slots” were named over three months. 2 of those (20%) were @cyberchimps code, who completed 17% of the reviews of New Themes made live during that period. I’d say that the program – which was intended from the beginning to be a fun way to encourage more participation, rather than a serious contest with rigidly defined rules – accomplished its objective of fairness.

        Personally, I’m glad to see the program changing. I’ve wasted more time managing a program that ended up getting taken way too seriously, which detracted from my time available for actual TRT admin duties.

        • Jen Mylo 11:04 pm on April 18, 2014 Permalink

          That, after all, is the point of a community contributor group, isn’t it?

          Yes, it is, flat out. Anyone expecting any form of reward or compensation other than feeling good, knowing you’re helping the project and that your volunteer efforts are helping millions of people, and recognition by your peers in the project, has expectations that are not in line with project values. For wp-based businesses, it’s considered an investment in the platform upon which the business is based (instead of, say, license fees ike proprietary platforms would charge).

          Ask not what WordPress can do for you, but what you can do for WordPress. :)

        • CyberChimps 11:07 pm on April 18, 2014 Permalink

          Numbers do not justify the cost and harm to the community.

          I’ve never seen pay-to-play rules in the WordPress community before, and I had never seen contributions being punished before either.

          We use to contribute reviews to contribute to the community, not for some reward of being featured.

          Due to the review contest we were forced to pull our developers away from doing what they do best, which is developing themes, and instead were forced to do theme reviews to keep our themes relevant. That is why it felt like extortion.

          To make matters worse our reviews were being disqualified from the contest if we made even a minor mistake for rules that are mostly subjective and mostly a matter of opinion.

          I don’t really care how many reviews were conducted or what the numbers are, contributions shouldn’t be forced.

          • Jen Mylo 11:11 pm on April 18, 2014 Permalink

            You’ve never seen it because it gets cut off before it gets that way, as other areas have much tighter oversight by project leaders/Matt. I have told MANY potential contributors thanks but no thanks when they offered to give us something awesome (code, video content, docs, etc) but wanted proprietary credit. We tend not to dwell on the bad things, and promote the good.

          • tskk 11:13 pm on April 18, 2014 Permalink

            Nobody forced anyone to compete.

          • Jen Mylo 11:13 pm on April 18, 2014 Permalink

            No contribution is forced. Period. If you were doing it just for the possibility of getting to promote your own theme on the Featured Themes page, then that’s pretty much the definition of pay for play. Anyone who isn’t here for love of the project/the work is absolutely encouraged to spend their volunteer hours with a cause that will give them those good feelings. No one should be building a business model around the site pages of wordpress.org.

            Further, I specifically asked for comments to focus on the discussion of what to do with the program moving forward, not to rehash old complaints, so please stick to that. Thanks.

          • Chip Bennett 11:31 pm on April 18, 2014 Permalink

            I would like to address this point, because it is important for moving forward:

            Numbers do not justify the cost and harm to the community.

            In the eight months since the inception of the program, 691 New Themes have been approved and made live in the Theme Directory. That equates to 1,036 Themes in a 12-month period. If you recall from Matt’s last State of the Word address, he mentioned that 300-some New Themes had been added to the directory.

            The review incentive program contributed to four times as many New Themes being added to the Directory. And that doesn’t even get into the considerable reduction in turn-around time for Themes to be reviewed (ah, yes: the glory days of 60-day waits in the review queue). Nor does it address the almost three thousand Updates to approved Themes that were reviewed and approved during that same, 8-month time period.

            That also doesn’t address the many developer comments I saw in the Trac tickets, thanking the reviewers for helping them through the review process, expressing appreciation for how helpful their reviewer was, and saying that they learned a lot through the process. (That’s a remarkable change from what used to be the typical response: frustration and resignation.)

            Those, far from being harm to the community, are measurable, demonstrable benefits to the community.

            It is that benefit that I want to ensure we maintain, in whatever changes we make to the review incentive program. To be honest, I’m not especially confident, given the amount of energy that was expended into the rules of the incentive program, rather than in working to improve the quality of reviews, and finding ways to work together as a team.

            So, I don’t plan to have much input on the discussion here. I’d like to see what the whole team has to say, and what we can come up with, as a consensus, for how to move forward.

      • Jen Mylo 11:06 pm on April 18, 2014 Permalink

        Any interest in contributing to a default theme should be directed to Matt. That said, no, we would not keep anything in a company name. That’s not really how contributing code works here. When something is contributed, it gets hammered on and changed by a bunch of people, and the default themes all carry worrdpressdotorg as the author, even if only one person wrote and designed most of it.

        • CyberChimps 11:17 pm on April 18, 2014 Permalink

          Understood.

          We’d just hate to give up the name Responsive, but perhaps a better alternative would be to contribute our 1.x code base, and then still release 2.0 under CyberChimps. Best of both worlds that way.

          Will think on this.

          • Jen Mylo 11:19 pm on April 18, 2014 Permalink

            That’s always an option. The themes that went into some previous default themes live on as separate entities.

    • arpowers 10:17 pm on April 18, 2014 Permalink

      Great, to hear you guys have figured this out!

      It seems to me that ‘featuring’ has a specific role in a marketplace (and economics).

      Specifically ‘featuring’ helps prevent good products from getting buried from products already on the leaderboard. For example, this is how Apple views featured Apps on the App Store for example. It’s all about visualizing things and giving good products a chance.

      TL;DR – If you guys want to do it correctly, then featuring is somewhat of a soft art, but it has a clear function. Admins should select featured themes monthly, objectively, based on an application and peer review. You can’t fight economics.

    • eminozlem 10:27 pm on April 18, 2014 Permalink

      Couldn’t agree more. It seems for reviewers, promoting their own theme is a huge motive to make more reviews. I too don’t like the section to be occupied by biased themes and same themes.
      So, the best would be a hybrid solution ie; If there are 10 featured themes; make 6 of them a random selection, 4 of them reviewer’s choice, like it’s right now. That could make everyone happy.

      As for the algorithm, I think everyone should be taken into account.
      1- Download count. (Should be calculated together with time. Otherwise older themes would gain advantage)
      2- Rating. ( Should be calculated together with number of reviews, Otherwise 5* theme with only 3 reviews would win over one with 4.8 rating with 155 reviews)

      • tskk 10:29 pm on April 18, 2014 Permalink

        Downloads and ratings can be manipulated.

      • Chip Bennett 10:44 pm on April 18, 2014 Permalink

        Ratings are broken, and, in their current implementation, irrevocably so.

    • tskk 10:55 pm on April 18, 2014 Permalink

      This is off topic, since the decision is already made to scrap the program, but did you guys have any plan to deal with the issue of 2 months waiting time or will that be something theme authors have to live with?

    • Bryan Hadaway 12:06 am on April 19, 2014 Permalink

      Let’s look at the program in a purely objective way.

      What’s the point of the program? To get more reviews done, faster and ultimately get more themes approved. Why is that important? Because, the more themes and plugins there are available to the end-user, the more popular WordPress becomes. Why is that important? Because WordPress is a product of Automattic, a business, like any other. The more popular the brand/trademark is, the more people use it, the more people use it, the more money it makes, through affiliated hosting referrals, through .com services etc.

      WordPress.org is an upsell to WordPress.com (regardless of any idealism held by WordPress being open source software under the WordPress Foundation, which is great, or even regardless of intention, that’s still the reality of it), just like a lot of our free themes are upsells to premium versions.

      That’s the objective bottom line of any business, understandably and there’s nothing wrong with that.

      The program works, period. All of these things are being accomplished.

      However, subjectively, people simply don’t like the program, regardless of the fact that it works. That to me, seems like the problem that needs to be addressed.

      It’s an Incentive Program, again, that’s INCENTIVE Program.

      Basically, I see only 2 options being presented to us:

      1. Retire the incentive program.
      2. Remove all the incentives, but keep the program. That doesn’t make a whole lot of sense, how is that different than removing the incentive program? If there’s no additional incentive, then the program simply dissolves.

      There are a lot of unpaid volunteers, theme developers, plugin developers, reviewers, admins etc that keep the project alive and popular. Yes, it is our choice to volunteer our time to help out, but let’s not demonize receiving incentives in return for our effort like it’s some dirty, unethical thing.

      There’s no such thing as a purely selfless act, so please, let’s stop pretending and stop spinning the desire for gain with a negative connotation.

      We all gain something from the project (ALL of us), for one or all of these reasons:

      • It’s fun to volunteer
      • It makes us feel good to help out
      • It’s fun to build something that other people actually use
      • It’s a good way to stay sharp and keep informed about web design trends and best practices
      • We use WordPress for client projects (and our own projects)
      • We make products for WordPress for monetary gain

      Matt is a millionaire because of WordPress after all, we’re not really going to continue to spin incentive as a negative are we?

      I personally use/have used WordPress for all these things, I love WordPress and I receive incentives daily from contributing to the project. These are all good things.

      One hand washes the other. That’s the true spirit of WordPress and really, any community in general. We wouldn’t do it if it served no benefit to us. It’s called being human.

      I vote that we keep the program, which must include logical incentives or there’s no program at all. If Matt thinks volunteers receiving incentive is wrong, of course the program will and should be removed, but I think if we could address what about its current implementation people find unfair, that would be the most constructive and productive approach.

      Here are my thoughts for an actual solution for the main Theme page. Keep the program exactly the way it is now (with maybe a few minor tweaks), only change the design of wordpress.org/themes to have 5 even columns/blocks of listed themes, in this order:

      • Featured
      • Reviewer Recommended
      • Popular
      • New
      • Updated

      Featured will be admin picked and “Reviewer Recommended” or just “Recommended” will be what the incentive program is for. Yes, reviewers should still be able to pick their own theme, that’s what drives competition (another word that’s not a bad word) and makes the program work in the first place.

      Fairness. I don’t see why there’s even a fairness problem to begin with. Anyone that can submit their own theme and get it approved can also review other themes. It’s entirely someone’s choice how much they want to contribute. Those who choose to contribute the most should naturally receive the most incentive. That’s the way the world works.

      For the record: This comment is not made in a rude or accusatory or off-topic or angry manner. It’s just an honest and calm construction of my thoughts on the issue.

      Thank you.

      • tskk 12:23 am on April 19, 2014 Permalink

        If there is a vote, then i would vote to keep the program at least the earlier version.

        Removing the incentive of not selecting our own theme will bring back the problem of 2 month wait time. Volunteer reviewers can only do a little, 2 month wait time is after the volunteer effort.

        Only other viable alternative is to hire full time reviewers.

        • Chip Bennett 1:24 am on April 19, 2014 Permalink

          If people stop contributing because the “incentive” goes away, then the entire Review Incentive program was a failure from the start. Regardless of how many more Themes were approved, and how much the review queue wait-time was solved, if that all came about only because of the pay-to-play aspect of the program, then we failed.

          • Bryan Hadaway 1:27 am on April 19, 2014 Permalink

            I don’t think so.

            The problem isn’t really an objective one, but a subjective one.

            2 + 2 always equals 4 even if not everyone agrees on the method 4 was reached. That’s really what we’re talking about.

            The program works.

            • Chip Bennett 1:33 am on April 19, 2014 Permalink

              I’m not a believer that the end justifies the means. The Theme Review Team is a community contributor group. It exists to give people an opportunity to contribute to the WordPress project. There are many benefits inherent in participation in the Theme Review Team: become a better Theme developer by learning more best practices, help other developers get their Themes approved and listed in the Theme Directory, and help ensure end users have a wider variety of the highest quality Themes they can find anywhere.

              Those are the reasons the Theme Review Team exists. If the Review Incentive program caused the team to lose sight of its raison d’etre, then yes: the program failed, and needs to be replaced with something that similarly advances those objectives without turning the Theme Review Team into a pay-for-play operation.

            • Bryan Hadaway 1:40 am on April 19, 2014 Permalink

              @Chip – Agreed, I was here before the incentive program and I’ll be here after, but I did review more with an incentive because I could justify the time spent more. I think that’s the ideal.

              I think a simple pros and cons list would still prove the program useful.

          • tskk 1:30 am on April 19, 2014 Permalink

            I think it all came from only that aspect, but i will be happy if proven wrong.

            • tskk 1:34 am on April 19, 2014 Permalink

              correction : not all, but most of it.
              A few reviewers were there before the program and continue to do so and will continue to do so.

            • Bryan Hadaway 1:37 am on April 19, 2014 Permalink

              @tssk – I was one of those reviewers that was there before the incentive and will be there when it’s gone. I’m not going to lie though, I reviewed way more with an incentive than without because it allowed me to justify allocating my time away from other things I was working on.

      • Jen Mylo 12:29 am on April 19, 2014 Permalink

        WordPress.com is a product of Automattic, but WordPress is not. Have you checked out .com lately? They have a vastly different user experience, and lots of developers that do not have anything to do with .org.

        I also think you have it backwards… if anything, we generally pitch .com as the entry-level freebie, with self-hosted/.org being the kind of site you ‘graduate’ to when you need more complex stuff.

        • Bryan Hadaway 1:23 am on April 19, 2014 Permalink

          “WordPress.com is a product of Automattic, but WordPress is not.”

          Yes, I know that. But, that’s only a legal technicality.

          “if anything, we generally pitch .com as the entry-level freebie, with self-hosted/.org being the kind of site you ‘graduate’ to when you need more complex stuff”

          I also understand this.

          Both of your points I already expanded on and rebutted in my original comment, because I had already predicted someone would say .com is a “product” of Automattic and .org is a “project” of the WordPress Foundation. We’re talking about words, not function.

          I’m referring to the reality of brand building as seen from the consumer’s eyes and the bottom line dollar reality, not what’s written on paper. The point I’m making is that every little thing volunteers do to contribute to WordPress.org, builds up the name of the “WordPress” trademark overall. Without the popularity of .org, .com wouldn’t make as much money. Keeping in mind that .org also directly makes money via wordpress.org/hosting. But that’s of course chump change in comparison.

          Again, it doesn’t matter what the legal technicalities or the intended ideals are, the reality remains unchanged. Matt and other paid employees gain direct (not indirect like “feeling good”) incentive from our efforts, why is it a problem for us to receive direct incentive in return? Again, one hand washes the other. Community is about give and take, not hierarchy. In that case, we really are talking about volunteers being employees, admins being managers and Matt being our boss.

          Of course, I don’t expect Chip or Emil to all of sudden get paid for their hard work or any volunteer for that matter. We are here by choice. But, to be able to feature a theme (that in and of itself is a contribution) for our contribution efforts of reviewing themes for others seems like a very mildly generous incentive, not something to feel bad about or frown upon. That’s pretty disheartening to say the least.

          Again, that’s great that Matt and company is so successful, I’m casting no negative shadow on that whatsoever. What I’m talking about is the double standard that’s been presented here.

          But, we can get deeper and deeper into the philosophical state of the issue, and we’ll probably just rest that portion on disagreeing and move onto the next…

          Do you have any thoughts on my proposed solution? I don’t think it would be too difficult to implement and maintain and I feel like it kills two birds with one stone.

      • Sami Keijonen 7:36 am on April 19, 2014 Permalink

        Very good points Bryan, I pretty much agree all of them. And your our solution seems best so far. I’d like to add some kind of random theme section. Also default Twenty themes should not be featured all the time. They should be treated like any other theme.

        Community is a two way street. It’s not just about giving, it’s also about getting.

      • Zulfikar Nore 11:17 am on April 19, 2014 Permalink

        +1 to “Let’s look at the program in a purely objective way.” and everything else Bryan said!

    • Carolina Nymark 12:45 am on April 19, 2014 Permalink

      I dont mind nr1 or 2, but I wish there was a way to make sure theme authors are actually ready to submit a theme. I mean the que will go back to two months because there are so many themes that goes into the “not approved” bin and you put time and effort into a review and the authors don’t bother to try and fix it. The incentive should be the authors not the reviewers.

    • Josh Pollock 1:34 am on April 19, 2014 Permalink

      This isn’t a vote, or an opinion about what to do, it’s just a comment:

      I actually stopped reviewing themes soon after the incentive program started.

      I started reviewing themes, like a lot of people, when I looked up how to submit my own theme, and saw that it involved a 6-8 week wait and thought “that sucks, but this looks like a good way to contribute to WordPress.” So I started reviewing themes and learned a lot from doing it. This was the first thing I did to contribute to the WordPress community.

      Then the incentive program came along and at if there were ever tickets available, they were always “problem” tickets. So it became way less fun and I stopped. I didn’t feel bad as the queue wasn’t 6 weeks long anymore, which is great.

      Since then I’ve started contributing to the community in many other ways. I’m not upset, I like the fact that themes get reviewed quickly and I’m just saying that before theme reviews was a competition, it was a gateway to becoming an active contributor to and participant in the community.

      • Chip Bennett 1:40 am on April 19, 2014 Permalink

        Your experience is a big part of why I knew the program was in trouble when I had to post about not hogging or selectively assigning tickets. Despite all of the good that resulted, it turned Theme Review into a competition. I would rather see 100 people review and approve one new Theme a month, than have a dozen people fight over a competition.

        • Jen Mylo 1:59 am on April 19, 2014 Permalink

          One of the other infrastructure improvements I’d like to propose if we have bandwidth is a ticket assignment system that works like a customer service call center, where it just assigns the next theme in the queue to whoever’s next (or whoever is next with the right qualifications) so that cherry picking isn’t just discouraged it becomes pretty much impossible.

          • Zulfikar Nore 11:20 am on April 19, 2014 Permalink

            “or whoever is next with the right qualifications”

            What would be the “right” qualification and how would that be determined?

            • Chip Bennett 11:40 am on April 19, 2014 Permalink

              I think Jen is referring to the “reviewers” group in Theme-Trac – the group that has ticket-assigning and ticket-closing privileges.

    • Drew Strojny 2:12 am on April 19, 2014 Permalink

      Observing this from a distance it certainly looks like paid compensation for reviews. Almost all the winners are featuring for profit themes. If you’re selling freemium themes, being featured in the theme directory is like rocket fuel for that business model. The “cost” of reviewing themes is incredibly cheap for the real dollar return you’ll get on that work. If you were selling those featured spots they’d probably go for a few thousand dollars a month or more.

      When you receive something of significant dollar value for work performed, it’s called compensation, even if it isn’t real dollar bills in your pocket. I think we’re just seeing basic economic realities play out here.

      My vote is for a completely randomized featured theme list. It’s simple and it takes the drama out of the whole thing. This will eventually turn the “popular” list into a meritocracy, which I’ve always felt it should be.

      There is no point in subjectively choosing featured themes unless the person or persons choosing the themes has absolutely zero incentive bias. They shouldn’t be selling themes themselves, affiliated with anyone selling themes, or doing freelance work for someone selling themes. This is hard to accomplish in such a small and tight knit community. Even just being friends with someone might make you more likely to feature their theme.

      • Jen Mylo 2:17 am on April 19, 2014 Permalink

        If comment likes were in Jetpack already, I would totally “like” this comment. :)

      • Bryan Hadaway 2:24 am on April 19, 2014 Permalink

        You have some good points here, but you’re also not offering a solution.

        The incentive program was put in place because theme reviews were absolutely stagnant. It was taking months for theme developers to get their themes approved, that is, if they didn’t give up altogether first.

        The trac (https://themes.trac.wordpress.org/) is an absolute graveyard of abandoned themes.

        I think those of us who actually review themes, as well as submitting our own themes have a much better insight into this issue. A lot of you are only looking at one side of the issue because you really don’t understand the whole picture, first-hand.

        • Drew Strojny 2:46 am on April 19, 2014 Permalink

          In my opinion the solution is to scale back the theme review standards so it isn’t such a colossal project to get a theme approved. This makes the reviewers job easier and the whole process less intimidating.

          It’s the same balance government has to strike when they pass laws. If you add too much regulation, it ends up stifling innovation. You need to keep tweaking until you find the right balance. At the moment, WordPress.org themes feel overregulated to me. I think the recent changes that Chip enacted are a step in the right direction.

          • Bryan Hadaway 3:12 am on April 19, 2014 Permalink

            You’re right. I think that’s a very good solution, probably gets more to the root issue than anything else we’ve discussed so far.

            Honestly, the only mandatory checks should be for security, spam and bug issues. Any subjective design and function reviews we could probably do without.

            But then again, we’re probably just opening a whole new can of worms because naturally, there’s likely some who think we should only be more strict in our filtering of themes and what they’re allowed to do, not less.

            With that, I guess we’ll see what those in charge decide.

            • Chip Bennett 11:34 am on April 19, 2014 Permalink

              There are no “subjective design and function” Guidelines. We even down-rated the entire Theme Unit Tests to recommended.

              Security issues are where most (especially, new) reviewers struggle the most. Security issues generally derive from Theme Settings, which are the one aspect of Themes that have the highest learning curve. So, eliminating everything but security issues really won’t help the review process at all.

              And I disagree that the other aspects of the Theme Review Guidelines aren’t important. Ensuring that the Theme uses proper hooks, enqueues scripts and stylesheets properly, separates presentation from functionality, uses proper core functions, and maintains a consistent UX are all important. Directory-hosted Themes should play well with core and with Plugins, and should provide as consistent user experience as possible from Theme to Theme. These may seem like unimportant issues to some Theme developers, but they are certainly important to end users, to core, and to WPORG.

              But wholesale changes to the Guidelines really are a separate discussion, that would only sidetrack this one.

          • Ulrich 6:45 am on April 19, 2014 Permalink

            Only have security checks part of the review process would make the reviewers job easier but I don’t think this the best solution.

            The problem that I find is that a number of themes that are submitted are half baked or are just submitted so that they have a theme on the repository and somehow is free marketing for their company. These are the themes that you spend the most time and normally the theme author has put no effort to read the guidelines.

            I would love to see lower number of themes but more quality themes.

            Perhaps even require theme developers to review themes before submitting them.

          • Frank Klein 8:50 am on April 19, 2014 Permalink

            In my opinion the solution is to scale back the theme review standards so it isn’t such a colossal project to get a theme approved.

            I disagree with this, because it values quantity over quality. In my opinion, the problem with WordPress themes isn’t that there aren’t enough of them. There are just not enough good ones.

            We can’t review for design, but we can review for code quality and observance of best practices.

            I think that the biggest problems right now for theme reviews is that the process is entirely manual. You have to open the theme files, verify a whole laundry list of things and type up a report with all the issues you find.

            It also requires the reviewer to be an experienced developer and often to dig through code that may not be easy to read because it lacks things such as basic formatting.

            It’s very time consuming and repetitive, which is why it isn’t fun. It also wastes human brain power on things that machines could detect easily.

            So instead of lowering standards and thus reducing the quality of themes in the repository, we should look at our review process, note the things that could be automated and write tests for it in the Theme Check Plugin.

            Because if we invest the time to write a check that saves a minute for every review, we end up saving hours of reviewers’ time due to the volume of submissions.

            AFAIK, the Theme Check Plugin is not on Github, which would be a first step towards accepting community contributions.

            • Jose Castaneda 11:05 am on April 19, 2014 Permalink

            • Ian Stewart 4:59 pm on April 21, 2014 Permalink

              instead of lowering standards and thus reducing the quality of themes in the repository, we should look at our review process, note the things that could be automated and write tests for it in the Theme Check Plugin.

              Because if we invest the time to write a check that saves a minute for every review, we end up saving hours of reviewers’ time due to the volume of submissions.

              +1

            • alex27 3:22 pm on April 24, 2014 Permalink

              Amen to that! This would go a long way towards reducing the queue without incentive program.

      • Philip Arthur Moore 3:24 am on April 19, 2014 Permalink

        Spot on.

      • Frank Klein 9:05 am on April 19, 2014 Permalink

        My vote is for a completely randomized featured theme list. It’s simple and it takes the drama out of the whole thing. This will eventually turn the “popular” list into a meritocracy, which I’ve always felt it should be.

        Absolutely. I think that the proposed solution #1 is the best way to approach this. The algorithm doesn’t have to be complicated.

        The only two things that I would check for in this code is to make sure that themes that weren’t updated in a while don’t make the featured section and keep a list of the already featured themes during a certain time period (6 months? A year?) so that a theme isn’t featured too often.

    • Konstantin Kovshenin 7:31 am on April 19, 2014 Permalink

      I think #1 is the best approach.

    • Stanko Metodiev 9:18 am on April 19, 2014 Permalink

      I like the general idea of this initiative, but different people understands contribution differently. I like #1, but it would be great to have place where top reviewers could list their themes

    • nikeo 9:30 am on April 19, 2014 Permalink

      Let’s have a quick look at the different actors of the game and their “interests” here :

      • wp.org => featuring the best of what you can do with WordPress. This contributes to keep its position of first open source CMS in the world. This of course benefits to the WP.com business=> brings a huge popularity, talented developers, ideas, etc…
      • users => finding awesome free WordPress themes and beeing sure that they work fine and contain no malicious code
      • theme developers => beeing able to propose their work and ideas whithout waiting for weeks, having the possibility to support their theme’s users, build a freemium business
      • theme reviewers => contributing to a great project. But since this review activity is the key of success for everyone, it seems that some kind of reward/incentive is normal.

      Like @chipbennett highlighted it, looking at the theme review stats, the incentive program has brought really great results. Both from a user perspective => more great themes beeing available in the rep and from a developers perspective => faster reviews of course.
      To me, abandon this program and all the efforts that have been put into would not be optimal then.

      That says and following @jenmylo and @matt ideas, I think that an adapted solution #2 would be the best :
      Use an algorithm to select featured themes and keep the incentive program.
      How? The featured themes list would be a monthly merged list curated both by the TRT admins and the other half by the top reviewers of the month.
      Let’s say we keep the idea of 10 featured themes. The theme review admins would choose 10 themes and the reviewers would choose another 10. The algorithm would then randomly grab 10 themes among this pool of 20.
      With this solution, reviewers should still be able to choose their own themes and would have a statistically significant chance to see their theme featured. All other actors : wp.org, users and developers, could also benefit from it.

      Thanks for opening this discussion!

    • Greg Priday 9:44 am on April 19, 2014 Permalink

      I’d like to see #1 for the featured themes list. A weighted randomized list of themes that takes into account downloads, rating and newness. We could also allow admins or other trusted community members to boost themes they like so they generally land up higher on the featured themes list.

      This way we could keep the incentive program if we wanted to (it did solve the 2 month queue problem). We’d just allow the winners to give their theme a small, month-long boost in the algorithm. Maybe something that would translate to ~50 extra downloads per day.

      At the moment, incentive program winners are getting 1000+ additional downloads/day on their themes. I wouldn’t be surprised if this worked out to thousands or tens of thousands of dollars in monthly sales. That’s far too much of a bonus for what should be a fun little program.

      • Schwarttzy 11:44 am on April 19, 2014 Permalink

        Not a fan of the newness part. I think old theme should enjoy the spot light from time to time.

    • Zulfikar Nore 11:33 am on April 19, 2014 Permalink

      If a decision to abandon the incentive program has been made then #1 is the viable alternative.

      The only reason the program should be abandoned thought is because it is no longer what it was meant to be and we should not loose sight at what the program actually achieved, cut down the waiting Que :) – to me that is in no way a “failure”.

      Just my 2 cents :)

      • Schwarttzy 11:47 am on April 19, 2014 Permalink

        It has serious problems, when themes are being check out the second they get uploaded. Means the reward is way too high.

    • Schwarttzy 11:42 am on April 19, 2014 Permalink

      I’m so up for changes! I’m sick of these people blasting their theme month after month.

    • tskk 11:50 am on April 19, 2014 Permalink

      Out of the 10,
      2 for twenty somethings
      4 for best themes feature wise, decided by TRT admins/reviewers, these can be unseated only by themes with even better features.
      4 themes from last month’s new themes voted by TRT admins and reviewers who reviewed at least 5 tickets last month.

      • Chip Bennett 12:01 pm on April 19, 2014 Permalink

        Note: the Twenty-Somethings are separate from the 10. Also: 10 isn’t a fixed number.

    • ThinkUpThemes 12:26 pm on April 19, 2014 Permalink

      Removing 100% a program that has contributed so significantly to improving the theme review process is highly illogical and is a major step back. I struggle to see any sense in entirely removing a program which will result in the theme review process becoming a lengthy and cumbersome process. Surely an objective of any operation, whether it be for profit or not for profit, is to deliver a service in a streamlined and efficient manner? The review incentive program helped achieve this.

      Also considering @Chip comment “a remarkable change from what used to be the typical response: frustration and resignation” I would hate to see WordPress be viewed in this light again, particularly by potential .org theme authors, who are essential in ensuring the continued growth and future success of WordPress. Theme developers will simply go elsewhere, to other platforms or even marketplaces. We might brush this off and say “let them go”, however this would be a terrible attitude as for me it will indicate the start of the fall for WordPress.

      I personally think that competition is great, it drives developers and others to push their themes to be even better. As surely if they have an opportunity to become featured, they are more likely to bring to market a product that looks great, works fantastic and ultimately represents WordPress in a positive light. Removing the incentive program 100% will remove the friendly competition that’s currently in place and will inevitably result in reviewers going elsewhere. However if change is required, then lets approach the issue and seek a resolution in a manner that aims to satisfy all parties.

      I should stress that I don’t believe reviewers will actively seek to abandon their involvement with the review team, however this will happen due to the realities of life. If a reviewer is able to identify an “opportunity” elsewhere for them to gain exposure for their theme then it’s likely they will pursue the opportunity.

      Any incentive program that does not allow a reviewer an opportunity to benefit, I’m sad to sad, is not going to work. No matter how much we all believe it will. In this case I agree with many above that #1 is the most viable option.

      • ThinkUpThemes 12:27 pm on April 19, 2014 Permalink

        Just a note, change is always a good thing. So I’m excited to see what’s next in store for the review process. :-)

    • Justin Tadlock 3:38 pm on April 19, 2014 Permalink

      I originally thought the incentive program might be a good thing because the winners would choose themes that they actually reviewed during the month to be featured. Their reward would be to choose a theme that they found interesting, thought was good, etc. That’s the only way I would really like to see incentive program stick around.

      I’ve seen a number of good themes come through since the program started that have no chance of being featured though, and that’s something I’d like to see changed.

      But, we have to look at why the incentive program was introduced in the first place to get at the root of the problem. That problem is that we have way too many themes coming in and not enough reviewers/time to do full-scale reviews, which creates about a 2-month long wait time before a submitted theme is ever looked at. Then, it could be another month or so before the theme is ever approved (we’ve taken major steps in improving this second wait time with how we now do reviews).

      Therefore, we need to look more closely at why it takes so long to get these reviews done. I don’t believe this is a secondary topic or unrelated. All of these things are intrinsically tied together. What we’ve done over the past few years is create a review system that introduces a high barrier to entry for theme authors and makes for long and arduous reviews for reviewers. There are a lot of good reasons for our guidelines, many of which I’ve taken part in creating. However, this is probably an area we need to take a long, hard look at because it is what has led to the situation we currently have.

      Something has got to give somewhere because I don’t think any of us want to go back to the days where we had those 2-month long wait times. Like it or not, the review incentive program fixed that. While changing how themes are featured is good, we need a way to fix the problem if we drop the incentive program. We can’t fix one problem without addressing the other.

      On the specific subject of featuring themes, here’s what I’d like to see:

      1) All reviewers should get an opportunity to propose a theme (not their own) to be featured. At the end of the month, the admins choose from any themes proposed by the reviewers.

      2) The algorithm approach. Of themes not specifically chosen by the theme review team, they should be auto-rotated.

      3) Themes that are chosen as featured should not be featured for more than a month nor should they be chosen again within a specific time-frame (3 months, 6 months, year, etc.).

    • ThinkUpThemes 3:58 pm on April 19, 2014 Permalink

      I like points 2 & 3, however there are a number of issues introduced with point 1. A number of theme reviewers, especially those heavily involved during the incentive program run their own theme shops, many of which are small businesses. Do you truly believe that someone who runs a small business will (or can afford to) spend the amount of time they’re currently doing so to review themes without even the potential of benefiting their own business?

      It sounds great, however lets all be honest. If we all truly took actions solely out of the kindness of our own hearts to help others without the need for recognition or benefit, then we’d all be volunteering at our local hospices. This is simply the reality of it. So I really do hope that when arriving at a solution we are realistic in our expectations on how it will impact the review process.

      I’m fairly new to WordPress and honestly am truly grateful for this whole project. The reality is that reviewers can still build successful theme shops without ever being featured (e.g. Elegant Themes, StudioPress, and the many MANY theme authors on ThemeForest).

      Please lets not alienate our theme reviewers and punish them for wanting to benefit their own situations whilst working to developing WordPress. If we do this then the experienced reviewers (who I would assume it’s safe to say are also experienced developers) will simply go elsewhere. Then we’ll be left with a situation where the majority of the review team consists of those that are new to WordPress reviews, and therefore less experienced, and possibly stick around for less time as they do not even have a prospect of benefiting. Inevitably those that will suffer are the admin, prospective .org theme authors and eventually the WordPress users that are left with low quality themes which are rarely updated and developed by inexperienced developers.

      I say we return to the old program where only 3 reviewers can get featured. There’s no need to completely scrap something that is working and greatly benefiting the community.

      • Chip Bennett 4:09 pm on April 19, 2014 Permalink

        I just did a quick count; we have about 150 people with “reviewer” privileges. We’re currently approving just under 100 New Themes per month. If every person with “reviewer” privileges reviewed one New Theme every two months, we would be able to keep up with the review queue. (That’s not counting Theme Updates, of course; but those are much simpler, diff-reviews.)

        We say that we want quality-over-quantity for approved Themes; I think that we have reached a critical mass of reviewers that we can set a goal of quality-over-quantity for Theme reviews now, as well.

      • Jen Mylo 4:09 pm on April 19, 2014 Permalink

        Do you truly believe that someone who runs a small business will (or can afford to) spend the amount of time they’re currently doing so to review themes without even the potential of benefiting their own business?

        That’s how contributing to WordPress works. Some people won’t do it without getting paid or rewarded, and that’s okay.

        • ThinkUpThemes 4:15 pm on April 19, 2014 Permalink

          Hi Jen,

          I should stress that I’m a part of the group that will still continue at my current rate of contributing. I don’t do many reviews, but do as much as I can afford to. Lets just hope that every reviewer has this view. However, I do believe that we’ll have a drop off from reviewers that are running small businesses. Hopefully though this wont impact the review queue too much. Like I said I’m new, and grateful for everything everyone here is doing. :-)

          @chip. I didn’t know we had so many reviewers! in that case, maybe my predicted impact wont be as significant as I’d thought.

          • Jen Mylo 4:38 pm on April 19, 2014 Permalink

            Don’t second guess yourself. Removing the possibility of featuring your own theme will definitely mean some people don’t participate anymore, or at least at the same level. What I’m getting at is that that’s how the WordPress project works, and the loss is something we’ll deal with. Just like if someone has a job that pays for them to contribute to core loses that job and doesn’t want to put in as much time anymore because they ant to spend more time on paying work or other hobbies — it’s a built-in expectation in open source projects.

            • ThinkUpThemes 4:42 pm on April 19, 2014 Permalink

              “Don’t second guess yourself.”

              Not sure what you mean? :-)

          • Chip Bennett 12:09 am on April 20, 2014 Permalink

            I’m not sure I understand why those with commercial Theme shops are really any different from those without commercial Theme shops. We all have families, and day jobs, and other commitments and priorities. We are (or should be) all here because we want to contribute to the WordPress project and community. We do so because we prioritize that contribution for its own sake.

            Idealistic? Of course. But then, WordPress itself is idealistic.

      • Justin Tadlock 4:41 pm on April 19, 2014 Permalink

        No, I don’t believe all will continue reviewing as they do now and said as much above. I don’t think any of us believe that. The whole point of my post is that if we scrap the incentive program, we’re probably going to have to rethink other parts of the theme review process to be able to keep up.

    • Emil Uzelac 6:47 pm on April 19, 2014 Permalink

      Quick Background.

      At the beginning I was not for the program, but it kind of grew on me.

      First it was great seeing this entire group of people at one place, reducing the ticket number and approving them quickly.

      What a fantastic feeling, @chipbennett and I were simply relieved.

      Soon after that we started getting poor reviews, tickets re-opened and some complaints from Theme authors. We figured that this was only a temporarily but we were wrong.

      Reviewer approves the Theme and admin evaluates each review before the Theme is “marked” live. After the evaluation admin decides the scoop and “holds the right” to re-open the ticket if the bare minimum is not set.

      So if you have 100 tickets, admin goes through all and tries our best not to re-open them because that can create more work for author, reviewer and delay the overall approval process.

      The contribution turned into competition and competition became a “battle”, not only among the reviewers, but also toward the TRT (not a healthy “relationship” if you ask me).

      Please note that program was just a trial and because of that we don’t have to go over a lengthy discussion to decide weather we need to continue or discontinue.

      • robin90 5:43 am on April 21, 2014 Permalink

        Can’t agree more on what Emil have said. The start of the incentive program was very good but slowly it has turned out to be an unhealthy competition. The number of tickets being reopened has increased lately and admins have to waste their time justifying themselves for the reopened ticket when the incentive winners were announced.

        The incentive program was just a trial and if more people are having problem with it then it’s fine that we close down it. But again a viable way should be there to reduce the number of tickets. We don’t want a month queue as used to be before the incentive program. Also I would like to see reviewers being rewarded for their work somehow, whether it’s via featured themes or any other way.

    • Jose Castaneda 9:52 pm on April 19, 2014 Permalink

      This doesn’t bum me out. When it was first introduced I liked the idea of empowering the reviewers and letting us share some cool ways of creating themes. As Justin mentioned previously it took a side step and wound up in this path. I really like the first implementation and think that the second could be very feasible.

      When I first chose to start reviewing themes it was to give back to the community. If it benefits me that’s fine. If it can benefit everybody: even better.

    • Catch Themes 1:27 pm on April 21, 2014 Permalink

      Firstly thanks @chip and @emil for the hard work. This incentive program was opened with good intention and before of this, we have learned a lot. It’s not become a habit to review the theme. Closing the incentive program will be definitely increase the waiting time for theme review and approval. So, we should come up with alternatives. We will continue to support review even if there is no incentive. As learning and giving it to the community is what values the most while working in open source projects.
      Good Luck to @jenmylo and hope for the best one :)

    • Ian Stewart 5:08 pm on April 21, 2014 Permalink

      Abandon the program altogether, and use an algorithm to select featured themes to auto-rotate so there’s always something different there rather than a static selection for any period of time

      This is a great way to feature themes. A trending list based on downloads + usage stats + reviews + support requests. (That’s an unordered list of positives and negatives.) It would be the freshest, fairest, and fastest way to feature the finest themes.

      That said, there is something to be said about the power of subjectivity — despite Drew’s really great points. A human editor can make great lists that pull out beautiful, on-trend, themes from the directory like this:

      http://themegraphy.com/provider/wordpress-org/

      • Emil Uzelac 8:20 pm on April 21, 2014 Permalink

        I like it!

        @otto42 would something like this be hard to integrate?

      • carlhancock 8:43 pm on April 23, 2014 Permalink

        The problem with an algorithm to select features themes based on analytics such as downloads, usage and reviews is that it’s going to neglect NEW themes that might be amazing but because there are so many themes they got lost in the mix and don’t have the analytics behind them for the algorithm to then feature them.

        Popular themes just get more popular. New themes that could be popular get buried. Rinse. Repeat.

        With something like this, human curation has to be part of the equation.

        I’ll give a great example. Digg.com. How is that relevant? The original incarnation of Digg.com was something I never used because the frontpage of Digg looked like the frontpage of Reddit to be honest.

        A ton of useless funny pictures, videos, etc. I found it pretty juvenile for the most part and sure you could find something of interest but you had to search for it.

        After Digg was acquired and re-launched they added a heavy dose of human curation to the mix and have a staff dedicated to just that. It’s a mix of both an algorithm and human curation to determine what was featured on the homepage.

        I now visit Digg everyday because there is always interesting news, etc. features on the homepage because they do such a great job with the curation.

        The same applies to featuring themes. The human element has to be involved in order to make it more powerful.

    • Ulrich 6:59 pm on April 23, 2014 Permalink

      @emiluzelac, @chipbennett & @jenmylo – What is the next step? When will a decision be made? Will the current featured theme be featured till a decision has been made and implemented?

      Thanks

    • Greg Priday 11:03 am on April 25, 2014 Permalink

      Quick idea for a possible incentive that could replace the (outgoing?) incentive program.

      How about we add 2 fields to theme pages on WordPress.org? “Reviewed By” and “Last Update Reviewed By.” These could be links to the WP.org profile pages of the reviewers who initially approved the theme and who approved the most recent update respectively.

      Here are the benefits as far as I see it

      • Exposure for reviewers: These profile links would indirectly result in more eyeballs on their themes, plugins and website.
      • More accountability: Having their names publicly displayed on theme pages might encourage reviewers to do a more thorough job of reviewing.
      • Reputation for reviewers: Probably the biggest benefit for reviewers. Reputation within the community as an (active) reviewer.

      It might not be quite as effective as the old incentive program in keeping the review queue clean, but it should be enough to keep more reviewers interested and active.

    • Zane Matthew 12:26 am on April 28, 2014 Permalink

      My vote would be for #1 “Abandon the program altogether, and use an algorithm to select featured themes to auto-rotate so there’s always something different there rather than a static selection for any period of time. Note: this is Matt’s preference.”

      Honestly really really surprised its done the way its done, I mean why wouldn’t someone just keep on submitting their theme to be featured.

      Maybe they should not be able to feature their own theme?

      I mean, I remember in grade school plenty of times we had to vote for x, y, and z and it was always like “okay, class, no you can only vote once, but remember you can’t vote for your own idea.”

    • Zane Matthew 12:29 am on April 28, 2014 Permalink

      One idea might be for theme reviewers to have the number of themes they’ve reviewed featured on their WordPress profile page, or next to their theme and/or plugin.

      This would server as a type of quality assurance, were the person downloading the theme/plugin would say; “Oh wow this author has reviewed 56 themes, they work must be up to par.”

      • Jose Castaneda 6:28 am on April 30, 2014 Permalink

        Would be pretty neat but I think would take some time to gather all that information and sort it all out.

    • CyberChimps 9:56 pm on April 28, 2014 Permalink

      Month is coming to an end. What is the status of the program?

      • Emil Uzelac 3:00 am on April 29, 2014 Permalink

        Patience is a virtue friend :)

        • CyberChimps 6:19 pm on April 30, 2014 Permalink

          Just curious since tomorrow is the 1st.

          So are the existing featured themes going to remain feature indefinitely until this is figure out?

          • Zulfikar Nore 7:30 pm on April 30, 2014 Permalink

            If the incentive program is out then I don’t think it would be ideal to feature the current listed themes until a decision is made on the way forward.

            All current featured themes (but for the default ones) should be removed and the admins then pick any random themes they feel deserve to be on the list and feature those for this month – that would be a fair call IMO.

          • Emil Uzelac 9:33 pm on April 30, 2014 Permalink

            I know that you meant no harm :)

    • Manoj H L 4:06 am on May 1, 2014 Permalink

      My opinion incentive program is not that bad..
      out of 10 featured themes Twenty Fourteen, Twenty Thirteen will always be there and make only 3 featured themes from who ever the winner is… **only Three winners** so 5 so still their will be slot for 5 more themes now randomize the process of selecting these 5 themes.
      ;) this is just my idea!!!!

    • CyberChimps 12:49 am on May 6, 2014 Permalink

      Can someone explain what the criteria is to be featured now?

      • Emil Uzelac 4:18 am on May 6, 2014 Permalink

        Program is in recess until further notice.

        At this time, featured items are handpicked Themes based on Underscores.

        • tskk 1:37 pm on May 6, 2014 Permalink

          I have a ton of themes based on Underscores :)

        • Zane Matthew 12:13 pm on May 8, 2014 Permalink

          I’d love to know what classifies a theme to be “based” on Underscores. I base all my themes on Underscores in some form or shape, but they always ended diverging from the original code base.

    • Emil Uzelac 12:48 am on May 8, 2014 Permalink

      @CyberChimps that is not what I said.

      All I know is that featured section will no longer serve as a promotional tool.

      • Romik84 5:07 am on May 8, 2014 Permalink

        Finally! this is what I said two years ago and is the changehttp://wordpress.org/support/topic/featured-themes-section-boring?replies=26 . It’s kinda funny.

    • CyberChimps 1:30 am on May 30, 2014 Permalink

      So what the heck is the criteria now?

      It seems The Theme Foundry was just allowed an upsell theme in the featured list.

      As well as themes from a WordPress.org admin, an Audrey Capital blogger, and other theme shops.

  • Chip Bennett 6:40 pm on November 26, 2012 Permalink | Log in to leave a Comment
    Tags:   

    WordPress 3.5 Guidelines Revisions 

    It is that time of year again: with the upcoming release of WordPress 3.5, the Theme Review Team conducts its periodic review of the Theme Review Guidelines, and proposes any changes, either as necessitated by the new WordPress version, or otherwise as-needed.

    The 3.5 release has little impact on Themes, and as such will be mostly invisible to Theme developers. One minor change will be support for HiDPI (i.e. “Retina”) screenshots. If there are any other 3.5-related changes that we need to account for, please post in the comments.

    Here is the starting point for the discussion regarding changes to the Guidelines:

    • Change Theme Screenshot (screenshot.png) maximum dimensions from 300x225px to 600x450px. (Fixed per comment below)
    • New guideline under presentation-vs-functionality: Themes must not bundle custom post-content shortcodes
    • Change guideline: reduce criticality for Content Sidebar feature from required to recommended. (Themes would still be required to implement core Settings API if Theme incorporates content sidebar feature.)
    • Change criticality of add_theme_support( ‘automatic-feed-links’ ) from required to recommended. (Modified per comments below)

    Please discuss in the comments, and recommend any additions or changes to these proposed Guidelines revisions.

     
    • Andrew Nacin 6:45 pm on November 26, 2012 Permalink | Log in to Reply

      Could you explain the reasoning behind automatic-feed-links?

      • Chip Bennett 6:49 pm on November 26, 2012 Permalink | Log in to Reply

        Sure. I have no particular preference one way or the other. That one is there for discussion, primarily.

        It was suggested to me – and I would tend to agree – that inclusion of RSS feed links is a) not exactly *presentational*, and b) easily enabled via Plugin. So, I’m throwing it out there for the Theme developer community to discuss and to decide. That way, we’ve documented our reasoning for keeping it or removing it.

        • Andrew Nacin 7:15 pm on November 26, 2012 Permalink | Log in to Reply

          I need to do some research to verify my recollection here, but as far as I know, the only reason why it is a theme-support thing is because prior to that line of code, themes would add them into header.php directly. This would cause a double-up. If it weren’t for that, we never would have had the opt-in, and we’d just always do it. I’m game for revisiting this in the future, but I think it makes sense for themes to continue to add the line.

          • Chip Bennett 7:18 pm on November 26, 2012 Permalink | Log in to Reply

            I would consider header RSS feed links to be analogous to the WP version generator and other similar meta data. I’m sure you’re right about the reasoning behind the add_theme_support() implementation. Perhaps a criticality bump from *required* to *recommended* (or *optional*), to help make the point that this functionality lies very close to the presentation-vs-functionality line?

            • Samuel Wood (Otto) 7:53 pm on November 26, 2012 Permalink

              I would say that you could put this in the category of if you use them, then you must use them correctly by using the theme support bit instead of putting them in the header.php manually yourself. But we would definitely say that using automatic-feed-links is recommended.

              I would also say that it is definitely not plugin territory. If anything, core should be doing it automatically, all the time, period. However, because themes traditionally used hard-coded feed links, there was no way to do that and be backwards compatible.

            • Samuel Wood (Otto) 7:55 pm on November 26, 2012 Permalink

              In other words, ban hardcoded RSS links in theme headers, and require use of automatic-feed-links for themes that add feed links (which, IMO, should be all of them).

            • Chip Bennett 8:17 pm on November 26, 2012 Permalink

              I’m with you, Otto. I don’t think anyone is advocating *prohibiting* automatic feed links; but rather more like what you said: adding feed links is *recommended*, *must not* hard-code feed links, and if adding feed links, *required* to use add_theme_support().

            • Vicky Arulsingam 1:03 am on November 27, 2012 Permalink

              I’d prefer it be bumped down to recommended.

              If a user has a plugin for this feature and feed links are added in the theme, would this result in the links being displayed twice?
              If this is the case then a recommendation/requirement to perform a ‘current_theme_supports’ check would be helpful

            • Andrew Nacin 2:49 am on November 27, 2012 Permalink

              They should remain required. Think about it this way: The theme *must not* hard-code feed links, and the theme *must* tell core that they are not hard-coding feed links. That’s really the only meaning of automatic-feed-links.

            • Samuel Wood (Otto) 2:49 am on November 27, 2012 Permalink

              Vicky: If both the theme and the plugin are using automatic-feed-links, then no, they would not be added twice.

            • toscho 11:19 am on November 27, 2012 Permalink

              Core should ask for opt-out and apply the feed links automatically. Legacy themes should not force theme authors to use non-presentational functions in their new themes.

            • Edward Caissie 3:19 pm on November 27, 2012 Permalink

              Quoting Otto:

              I would say that you could put this in the category of if you use them, then you must use them correctly by using the theme support bit instead of putting them in the header.php manually yourself. But we would definitely say that using automatic-feed-links is recommended.

              I agree this is the best method going forward on the implementation of automatic-feed-links

      • mrwweb 7:05 pm on November 26, 2012 Permalink | Log in to Reply

        I moved automatic-feed-links to my functionality plugin a year ago for this reason. If a site needs them, they shouldn’t disappear and reappear depending on the theme.

    • Chip Bennett 7:13 pm on November 26, 2012 Permalink | Log in to Reply

      Other things I’d like to discuss:

      • Timing for making do_settings_sections() required (as opposed merely to recommended) as part of Settings API implementation
      • Removing public-facing credit links, or making them follow Plugin rules: user-configurable, and disabled by default
      • Reformatting the Guidelines as a checklist (either replacing the existing Guidelines entirely, or creating a companion tool to aid reviews)
      • Ian Stewart 7:54 pm on November 26, 2012 Permalink | Log in to Reply

        Removing public-facing credit links, or making them follow Plugin rules: user-configurable, and disabled by default

        Can you elaborate on some of the reasoning behind this?

        • Chip Bennett 8:07 pm on November 26, 2012 Permalink | Log in to Reply

          I’m curious what the Theme developer community thinks about the idea. I think that there is an argument to be made that the negatives far outweigh the positives with respect to displayed-by-default footer credit links. It attracts an inordinate share of of Bad Things, and leads to an inordinately high number of headaches for reviewers and developers alike, under the false premise that such footer credit links help developers’ SEO.

          Obviously, there *is* real benefit to be gained, through actual humans seeing and following those links, but I have long-questioned whether that benefit outweighs the volume of crud Themes that get submitted solely in an attempt to spread footer credit links.

          I’m really just interested in finding out if the Theme developer community would be even partially amenable to the idea, or if it’s something that remains completely off the table for discussion.

          • Emil Uzelac 8:24 pm on November 26, 2012 Permalink | Log in to Reply

            As developer and TRT admin I strongly believe that this is not necessary. Credit Links are the “connection” between the site and the author and many of us here are making a living out of that.

            • Chip Bennett 8:41 pm on November 26, 2012 Permalink

              Agreed, and I don’t want to give the idea of wanting to throw the proverbial baby out with the bath water.

          • CyberChimps 1:16 am on November 27, 2012 Permalink | Log in to Reply

            I think it is a good thing that we are not letting themes into the repo that were submitted on the premise of generating SEO. If we remove the credit links we will be punishing honest authors, and lose the ability to spot the spammers more quickly. It is a lose-lose situation.

            The rules do not matter to spammers, there will always be spam submissions no matter what the rules are we shouldn’t punish honest authors from having a connection to their work.

          • Edward Caissie 3:30 pm on November 27, 2012 Permalink | Log in to Reply

            I would say we leave the credit links in, as is.

            My concerns are not so much in the continued efforts of spammers trying to “game the system” but more so for the developers and designers who may lose interest in updating and/or submitting new themes to the repository without any credit for their works.

            An option to “turn off” credits may be feasible, or even something to be suggested, but I would never get to the point of it being recommended.

            If “Code is Poetry”, how can you expect the poet to not openly sign their work?

        • Ian Stewart 8:18 pm on November 26, 2012 Permalink | Log in to Reply

          I think it’s an interesting idea. My two cents: I think an option is too much cruft for a problem that doesn’t really affect the user and that not allowing public facing credits will probably discourage submissions from designers — especially ones that aren’t quite aware that a theme developer community exists. I don’t think designers do it for the SEOs. I just think it’s natural for them to want to put a credit line on their work in the same way that an artist naturally tends to sign their work.

          • Ian Stewart 8:21 pm on November 26, 2012 Permalink | Log in to Reply

            I don’t think designers do it for the SEOs

            Though obviously some spammers with not-the-best themes are. :)

          • Chip Bennett 8:22 pm on November 26, 2012 Permalink | Log in to Reply

            Is there a way to provide the benefit (which is certainly deserved), without attracting the bad?

            • Ian Stewart 8:34 pm on November 26, 2012 Permalink

              Probably not.

            • Chip Bennett 8:36 pm on November 26, 2012 Permalink

              Is it something worth further consideration, to try to come up with a better alternative, or is it just something that we just have to continue to deal with, because it can’t be fixed?

            • Ian Stewart 8:40 pm on November 26, 2012 Permalink

              There may be some way to make it easier to spot/flag these themes beforehand (automatically diffing against the default themes and coming up with a percentage that flags a theme? Flagging first time themers that have some sort of commonality to theme?). I can’t think of any alternatives to it beyond getting better at spotting the bad guys and just dealing with the fact that there are bad guys.

            • Ian Stewart 8:41 pm on November 26, 2012 Permalink

              … sort of commonality to theme?

              s/theme/them

              For some reason that’s a common spelling mistake with me.

            • Chip Bennett 8:49 pm on November 26, 2012 Permalink

              I often “audit” the Priority #4 queue, for just this sort of review. I look for spammy/inappropriate credit links and landing pages, and obvious knock-offs of known Themes.

              Honestly, child Theme support helps greatly in this regard, since we can spot Twenty Ten and Twenty Eleven derivatives, and require them to be resubmitted as proper child Themes. That’s helped cut down on a good bit of the knock-off Themes. But a lot of the pattern recognition you describe is purely manual, and requires familiarity with Themes prone to being forked.

            • Emil Uzelac 9:29 pm on November 26, 2012 Permalink

              We can reduce the numbers from 4 priorities to only 2. #1 Previously Approved and #2 All others, this way the process would be much faster and we can “scan” for SPAM easier. Does that make sense?

          • Philip Arthur Moore 12:13 am on November 27, 2012 Permalink | Log in to Reply

            Big +1.

        • Daniel 8:40 am on November 27, 2012 Permalink | Log in to Reply

          I have a bad feeling an unintended consequence of this would be many developers not updating theor themes anymore to circumvent this guideline.

        • Konstantin Kovshenin 11:19 am on November 27, 2012 Permalink | Log in to Reply

          Will adding “nofollow” to such links help avoid the “Bad Things”? If it does we can make it a recommendation or even a requirement.

      • Ian Stewart 7:54 pm on November 26, 2012 Permalink | Log in to Reply

        Reformatting the Guidelines as a checklist (either replacing the existing Guidelines entirely, or creating a companion tool to aid reviews)

        I think this is a great idea.

      • kwight 8:08 pm on November 26, 2012 Permalink | Log in to Reply

        I’ve volunteered to help the Documentation team with the Theme Review handbook: http://make.wordpress.org/updates/2012/11/20/docs-team-intro/#comment-22

        I’m a little unclear as to how this relates to the current posted Guidelines; I’m hoping the handbook eventually /becomes/ the posted guidelines. Is this what you’re referring to, or are you suggesting an interim step?

        • Chip Bennett 8:10 pm on November 26, 2012 Permalink | Log in to Reply

          As I understand it, the Theme Review Handbook is more intended to be a “how to get involved with the Theme Review Team” kind of thing?

          • kwight 8:24 pm on November 26, 2012 Permalink | Log in to Reply

            Ah, perhaps I’ve misunderstood; so the Handbook is more of an onboarding tool, while the Guidelines exist separately in the Codex?.. Either way, I’m in, the current format could certainly be improved.

            I think it would be more effective for each guideline to have a What Why How approach: “What” is the guideline, “Why” is it required/recommended, and “How” is it implemented (actual code example). I think it would reduce a lot of confusion both for reviewers and submitters.

            • Chip Bennett 8:27 pm on November 26, 2012 Permalink

              I like that approach; the problem is that the Codex doesn’t necessarily present the best means to implement such an approach. We would have to have separate entries for the Guidelines themselves (essentially what we have now), and for the What/Why/How information; otherwise, it would be even *more* difficult for new Reviewers to read/parse the Guidelines.

              But, I am absolutely in favor of providing more code examples, wherever we can.

            • kwight 8:51 pm on November 26, 2012 Permalink

              True; in my fancy designer head, each of the What Why How would be a tab for each guideline, but AFAIK, that’s not possible with the Codex. If only the Codex was WordPress :|

              The best thing I guess, could be having a “more detail” link for each guideline that goes to a more lengthy What Why How page, with code examples.

    • Ian Stewart 7:41 pm on November 26, 2012 Permalink | Log in to Reply

      Change guideline: reduce criticality for Content Sidebar feature from required to recommended. (Themes would still be required to implement core Settings API if Theme incorporates content sidebar feature.)

      Could explain this one a bit more? I’m not quite clear what it refers to.

      • Chip Bennett 7:48 pm on November 26, 2012 Permalink | Log in to Reply

        In other words: Themes don’t *have* to include dynamic-content sidebars (whether as a traditional sidebar, or a footer sidebar, etc.) .

        This came out of a discussion about Appearance -> Widgets no longer displaying if Themes don’t call register_sidebar(). Dynamic Sidebars would thus be treated as analogous with Custom Backgrounds or Custom Header Images.

      • Ian Stewart 7:49 pm on November 26, 2012 Permalink | Log in to Reply

        Awesome. Thanks.

      • kwight 8:11 pm on November 26, 2012 Permalink | Log in to Reply

        +1. It would be great (particularly for stripped-down/minimalist themes) to not be forced in to implementing widget areas.

      • Danielx64 3:57 am on January 24, 2013 Permalink | Log in to Reply

        -1 for the sidebar removal, like I said on the mailing list, I wouldn’t be happy to download a theme only to find out that it doesn’t support widgets.

    • kwight 7:57 pm on November 26, 2012 Permalink | Log in to Reply

      Ack! I already changed the guidelines re: screenshots, after noticing the new hiDPI screenshot for Twenty Twelve works in 3.4.2. Since it’s stating a maximum, would be a problem keeping it like that unless something comes up?.. Let me know if I’ve really jumped the gun, I’ll set it back.

    • shawn 8:09 pm on November 26, 2012 Permalink | Log in to Reply

      New guideline under presentation-vs-functionality – anyplace I can get more info on these guidelines

    • shawn 8:11 pm on November 26, 2012 Permalink | Log in to Reply

      New guideline under presentation-vs-functionality: Themes must not bundle custom post-content shortcodes

      Any place I can get more info on this???

      • Chip Bennett 8:16 pm on November 26, 2012 Permalink | Log in to Reply

        What sort of information are you looking for? This is probably the best place to get it. :)

        • shawn 8:38 pm on November 26, 2012 Permalink | Log in to Reply

          Are we talking just shortcode(s) or any custom post content code….

          A clearer definition of presentation vs functionality guidelines standard for either themes or plugins in WP are not exactly up to common PHP standards. I would love to know what exactly the guidelines are.

          • Chip Bennett 8:45 pm on November 26, 2012 Permalink | Log in to Reply

            Are we talking just shortcode(s) or any custom post content code

            What other post-content code do you have in mind? As a general rule, if you’re manipulating post content in any way other than presentationally, that manipulation probably belongs in a Plugin.

            A clearer definition of presentation vs functionality

            In some regards, that is the million-dollar question. But for the purposes of Themes, 99% of the time it isn’t difficult to determine whether something is functional or presentational.

            Do you have any specific examples where you’re unclear about whether something is one or the other?

            • Sayontan Sinha 9:13 pm on November 26, 2012 Permalink

              Themes that are framework-based (like Hybrid) have a lot of bundled shortcodes. Are those acceptable? What exactly differentiates a “custom post-content” shortcode from a regular shortcode?

              Along the lines of the Hybrid question, is it acceptable if the author provides a shortcodes plugin which is simultaneously offered with the theme (I do so, mainly to help users transition out of the theme without impact).

            • shawn 12:36 am on November 27, 2012 Permalink

              Most of my custom post-content runs from generic class located in a theme plugin toolkit, themes decided what is run, when, on a case by case basis, this allow me to customize post types based on the needs the theme.

              The problem with this method as far as I am aware is that themes with dependencies like these cannot function in the theme repository, now that it is policy, has this changed?

              Do you have any specific examples where you’re unclear about whether something is one or the other?

              I am unclear about everything here, since most theme developers already separate presentation from functionality what I see happening is the creation of another theme dependency and I not sure I like it.

            • shawn 2:23 am on November 27, 2012 Permalink

              Since the purpose of Themes is to define the presentation of user content, Themes must not be used to define the generation of user content, or to define Theme-independent site options or functionality.

              Sorry if I sound confused but this new guideline completely caught me off guard, theme dev/designers agreed to this???

            • Chip Bennett 2:28 am on November 27, 2012 Permalink

              The presentation-vs-functionality criterion is not a new guideline. It has been an operating principle since the beginning of the Theme Review Team’s efforts.

              What part of it do you disagree with?

            • Chip Bennett 2:30 am on November 27, 2012 Permalink

              Themes that are framework-based (like Hybrid) have a lot of bundled shortcodes. Are those acceptable? What exactly differentiates a “custom post-content” shortcode from a regular shortcode?

              As far as I’m aware, Hybrid does not bundle post-content shortcodes, but rather uses a custom shortcode for user configuration of footer text, etc. Such “shortcodes” are perfectly acceptable.

              The differentiation is post-content. If the shortcode is used in the post content – i.e. if it is added by the user to the post content editor, such as or [ref] or [two-columns] – then it belongs in a Plugin rather than in the Theme.

            • Sayontan Sinha 6:09 am on November 27, 2012 Permalink

              As far as I’m aware, Hybrid does not bundle post-content shortcodes, but rather uses a custom shortcode for user configuration of footer text, etc. Such “shortcodes” are perfectly acceptable.

              The shortcodes that come with Hybrid are entry-title, entry-author, entry-terms and several others, which to me seem very much like post-content shortcodes. These are by design to be run where the global $post is available. Where else would you invoke these if not in the post content? Hybrid has a host of other shortcodes that can be used in comments.

              So if this is made a requirement, then all themes that have such existing shortcodes have to pull them from the theme, risking sites breaking as as a result.

              I see no reason for any Theme ever to bundle post-content shortcodes.

              Except that, as I mentioned, several themes already include them, and they are in very heavy use. Trying to cull the shortcodes from such themes will only result in frustration for the users of the themes. I thought the aim of the theme review team is to make things easy for users, while disallowing what already exists only serves the opposite purpose.

              Of course, one way could be to disallow new shortcodes, but forcing theme authors to remove every existing post content shortcode is going to the extreme.

            • Chip Bennett 12:49 pm on November 27, 2012 Permalink

              The shortcodes that come with Hybrid are entry-title, entry-author, entry-terms and several others, which to me seem very much like post-content shortcodes.

              Those sound like template shortcodes to me. Key point: where does the user use those shortcodes: in the Visual/Text post editor, or elsewhere?

              These are by design to be run where the global $post is available. Where else would you invoke these if not in the post content?

              You are misunderstanding “post-content” shortcodes. A “post-content” shortcode is one that the user places in the post Visual/Text editor, that lives in the database in $post->post_content, and that is parsed by do_shortcode() upon display.

              Hybrid has a host of other shortcodes that can be used in comments.

              And Justin explicitly says that the Theme’s shortcodes are not intended to be used in the post content:: “These shortcodes are not meant to be used with the post content editor. Their purpose is to make it easier for users to filter hooks without having to know too much PHP code and to provide access to specific functionality in other (non-post content) shortcode-aware areas.

            • shawn 2:49 pm on November 27, 2012 Permalink

              What part of it do you disagree with?

              Practically all of it, with so much discussion and advances in development and understanding of UI/UX, to state the the purpose of a theme is to define the presentation of user content is shallow at best. What even worse is the intent of the statement (Themes must not used to…).

              Simply change a couple words in the statements purpose to read

              Since the purpose of Themes are to define how users interact with a websites content…

              We are having a different discussion about the rule(s) of what themes should be used for, presentation now becomes functional as functionality, as it should be is now defined by the theme!

              New old or whatever this is just sooooo wrong Chip!

            • Chip Bennett 2:56 pm on November 27, 2012 Permalink

              with so much discussion and advances in development and understanding of UI/UX, to state the the purpose of a theme is to define the presentation of user content is shallow at best.

              No. That is precisely the purpose of a Theme. WordPress is designed such that the Theme is the content presentation abstraction layer.

              What even worse is the intent of the statement (Themes must not used to…).

              Simply change a couple words in the statements purpose to read

              Since the purpose of Themes are to define how users interact with a websites content…

              We are having a different discussion about the rule(s) of what themes should be used for, presentation now becomes functional as functionality, as it should be is now defined by the theme!

              Perhaps it would be helpful to shift your paradigm from functionality to content. Properly designed Themes will support most functionality out-of-the-box.

              Asked a different way: what functionality do you think Themes should be defining?

            • Sayontan Sinha 10:34 pm on November 27, 2012 Permalink

              And Justin explicitly says that…

              So in summary it is okay to state something like “Don’t use these in your post content” in the comments, but it is not okay to state, “If you decide to stop using this theme you can use this alternative plugin”.

              The point that I have been trying to get you to see is that there are active themes with huge user-bases that have shortcodes built in them. Some theme authors actively try to make the transition out of their themes painless by providing plugins for various modules. Forcing them to pull the shortcodes out will affect a LOT of users. If this isn’t sufficient for getting an exception on existing themes with existing shortcodes, I don’t know what is.

            • Frank Klein 11:34 pm on November 27, 2012 Permalink

              As a general rule, if you’re manipulating post content in any way other than presentationally, that manipulation probably belongs in a Plugin.

              Exactly. I can see why this new proposed guideline is controversial, since a lot of developers think of themes as “website packages”, that bundle a very custom design with the necessary functionality – custom post types, short codes, etc. But the sole fact that this is practiced by a lot of themes shouldn’t matter for putting a guideline in place for future themes.

              I wonder how many of the heavy shortcode users will get the shock of their life when they switch themes and suddenly all their posts are littered with shortcodes that no longer work.

              It seems to me that most users don’t care about what comes with a theme and what comes with a plugin, all they care about is that it is there. So as developers we should make their life easier by allowing them to switch themes freely without losing any functionality.

              It isn’t that difficult to point users to the right plugin that adds the desired functionality to a theme. If someone is smart enough to use shortcodes, then he will get this too.

              Besides I hope that this will lead developers towards leveraging more existing plugins.S o instead of whipping up your own crappy SEO optimization code in functions.php, why not simply point users toward a great plugin like WordPress SEO? How different can the functionality of your portofolio post type be from that offered by Justin’s plugin?

              Relying on production-hardened, specialized plugins instead of cooking up your own is the way of the future. Not only will this free up time for theme developers so that they can focus on building the best theme possible, but it also over time improve portability and establish de facto standards.

            • shawn 3:58 pm on November 28, 2012 Permalink

            • Justin Tadlock 5:35 pm on November 29, 2012 Permalink

              Just a note about Hybrid Core: Its shortcodes are intended for use in templates. This is stated in the file listing the shortcodes as well as in my theme documentation on my site. Most users aren’t even aware that there are shortcodes in the themes because they are not advertised as a feature. Basically, to even know the shortcodes exist, you must read the notice that they’re not to be used in the post content.

              With that said, I do have some ideas about de-registering the shortcodes specifically when the_content() is called just to outright avoid any potential issues. Not once have I had an issue with this from my users though.

      • kwight 8:31 pm on November 26, 2012 Permalink | Log in to Reply

        Content shortcodes should be plugin territory, so that users don’t lose the shortcode functionality when changing themes.

        • Rizqy Hidayat 3:30 am on November 27, 2012 Permalink | Log in to Reply

          So what ‘s the actual meaning of *content shortcodes*? is it shortcodes in the editor or somekind like what?

          • Chip Bennett 12:51 pm on November 27, 2012 Permalink | Log in to Reply

            Yes: a “post-content” shortcode is a code that the user places in the post content, via the post Visual/Text editor. Shortcodes used elsewhere in the template are fine, because they don’t affect user content upon switching Themes; they’re merely Theme customizations.

      • Sami Keijonen 6:53 am on November 27, 2012 Permalink | Log in to Reply

        What comes to Hybrid Core shortcodes, they are only used in template files. Never in post editor. There is a big difference for me at least.

        • Sayontan Sinha 6:06 pm on November 27, 2012 Permalink | Log in to Reply

          Do you mean “they are only used” or do you mean “they are only *supposed* to be used”? I don’t believe there is anything preventing a user from going ahead and using these shortcodes in the post content.

          • Sami Keijonen 9:39 pm on November 27, 2012 Permalink | Log in to Reply

            Basic, non developer user don’t even know these shortcodes exists. And there haven’t been any question about using them in post content in themehybrid support forum or having problems when changing theme. Chip already pointed out all the others aspects about “post-content” shortcodes.

            But yes you can use them in post content like any other shortcode.

          • Chip Bennett 10:08 pm on November 27, 2012 Permalink | Log in to Reply

            Intended use is what matters here. The shortcodes included with Hybrid are not intended to be used in the post content. End users can do myriad things with any Theme outside of the developer’s intent; such is not our concern (see: software freedoms).

            • Sayontan Sinha 10:53 pm on November 27, 2012 Permalink

              Basic, non developer user don’t even know these shortcodes exists. And there haven’t been any question about using them in post content in themehybrid support forum or having problems when changing theme.

              This argument can be made for any theme. Bear in mind that I am not suggesting that the shortcodes be removed. I am merely saying that shortcodes either don’t matter to users at all because they aren’t aware of them, or the users make fully conscious decisions to use them.

              End users can do myriad things with any Theme outside of the developer’s intent; such is not our concern

              If that is the case, then a simple disclaimer somewhere (like the options panel) should suffice, telling users that some shortcodes are distributed with the theme and that if the users use those shortcodes they run a risk of a lock-in. After all, that takes care of the theme author’s intention. Maybe this could even be built into the core: the way it states on the themes page that a theme uses widgets, there could be something to state that a theme uses shortcodes.

              Not to belabour my point, but nobody seems to be getting that there are themes out there that have shortcodes in active use. Pulling the plug on the shortcodes simply leaves all users of such features in the lurch. And not allowing shortcodes even if there is a separate plugin offering all of them seems even more counter-intuitive.

            • Chip Bennett 11:37 pm on November 27, 2012 Permalink

              …or the users make fully conscious decisions to use them.

              I question whether such decisions are truly “fully conscious”; I don’t think most users realize what will happen to their post content if and when they switch Themes.

              Not to belabour my point, but nobody seems to be getting that there are themes out there that have shortcodes in active use. Pulling the plug on the shortcodes simply leaves all users of such features in the lurch.

              Of course we know that there are approved Themes that bundle shortcodes. Changing the Guideline doesn’t mean that those Themes are suddenly going to get suspended or anything. (Our aim is to *improve*, not to *degrade*, the user experience.) But that doesn’t mean that we shouldn’t or can’t say, “henceforth, no more.”

              And not allowing shortcodes even if there is a separate plugin offering all of them seems even more counter-intuitive.

              I don’t think there is any need to “grandfather” Themes that currently have shortcodes. I don’t see any problem with providing a transition for existing Themes with shortcodes. In your next update, make them pluggable in your Theme, and instruct users to install/activate the Plugin. Then in the subsequent update, you can safely remove them from your Theme.

            • Sayontan Sinha 11:57 pm on November 27, 2012 Permalink

              I question whether such decisions are truly “fully conscious”; I don’t think most users realize what will happen to their post content if and when they switch Themes.

              Themes are supposed to prefix their custom functions with a slug. I have always extended this to mean that their custom shortcodes should be prefixed with a slug. At least that is what I have practised always and I have even made a suggestion to this effect on the WPTRT list. If that is the case, using a shortcode from the theme becomes a very conscious choice, particularly since there is no UI provided to insert the shortcode.

              In your next update, make them pluggable in your Theme, and instruct users to install/activate the Plugin. Then in the subsequent update, you can safely remove them from your Theme.

              You are assuming that all users upgrade whenever a new version is available. I am pretty sure that there are several users who skip 5-6 versions before upgrading even if a theme is stable and from an active developer (I have even seen instances where people wait several months before upgrading).

              Regardless, if a rule is being set, there should be clear cut distinctions in the review guidelines between what is a permissible shortcode vs. what isn’t, with specific examples. Very often with other vague requirements I have had to go back and forth with a reviewer because his/her interpretation didn’t match mine.

            • Chip Bennett 12:25 am on November 28, 2012 Permalink

              If that is the case, using a shortcode from the theme becomes a very conscious choice, particularly since there is no UI provided to insert the shortcode.

              That still doesn’t make it a “fully conscious” choice, unless the user has been explicitly told “your post content will not display properly if you switch Themes”.

              You are assuming that all users upgrade whenever a new version is available.

              As a matter of principle, we do not facilitate users who choose not to keep their core, Theme, and or Plugin code current. Users are fully within their rights not to update, but that doesn’t mean we must accommodate that decision.

              Regardless, if a rule is being set, there should be clear cut distinctions in the review guidelines between what is a permissible shortcode vs. what isn’t…

              I’m not sure how much more explicit we can be with respect to shortcodes.

              If the Theme instructs or implies to users that bundled shortcodes are to be used in the post content, they are not allowed. If the shortcodes are intended to be used for other purposes (extending the Theme via hooks, or for user-configuration of template elements, etc., then they are allowed.

            • Sayontan Sinha 1:24 am on November 28, 2012 Permalink

              That still doesn’t make it a “fully conscious” choice, unless the user has been explicitly told “your post content will not display properly if you switch Themes”.

              I disagree. Regardless, I did make recommendations for this on this very thread:

              1. Make the users specify explicitly in their options page or in the readme.txt file that the shortcodes are not portable. You take your pick where you want them to specify this.
              2. Or make a modification to the core to show that a theme is defining shortcodes in the Appearance → Themes page. I am willing to write a patch if if this has takers, because that way it will not matter where a user has got a theme – the message will give the user fair warning even if the theme author hasn’t put it in.

              I’m not sure how much more explicit we can be with respect to shortcodes.

              Sorry, but this is not at explicit from any point of view:

              Themes must not bundle custom post-content shortcodes

              It makes no effort to define what a post-content shortcode is and to say that it leaves itself open to misinterpretation is an understatement. To me something like entry-title is a post-content shortcode, simply because it is defined in the context of a post. But you interpret this differently. I have multiple shortcodes of this sort, which if I went with my definition, I would have to pull from the theme, but based on your description they are fine because most of them don’t need to be executed in a post’s content.

              You could consider appending your own text from the above to the messaging:

              If the Theme instructs or implies to users that bundled shortcodes are to be used in the post content, they are not allowed. If the shortcodes are intended to be used for other purposes (extending the Theme via hooks, or for user-configuration of template elements, etc., then they are allowed.

            • Chip Bennett 2:31 am on November 28, 2012 Permalink

              You could consider appending your own text from the above to the messaging

              Oh, I certainly will.

              In case it hasn’t been apparent, I do try to go back to the OP and update the list based on the outcome of discussion in the comments. But, I try to wait until some consensus becomes clear, or until all questions have been answered regarding clarity/intent/etc. (For example, I think it would be more clear to refer to $post->post_content or the_content() rather than “post-content”, to indicate the shortcodes to which the guideline will apply.) I just want to make sure everything is clear before I edit the OP.

      • shawn 3:50 pm on November 28, 2012 Permalink | Log in to Reply

        Perhaps it would be helpful to shift your paradigm from functionality to content. Properly designed Themes will support most functionality out-of-the-box.

        Asked a different way: what functionality do you think Themes should be defining?

        I think we should all shift our paradigm not to content but its content usability and consumption, realizing that themes are more that just a presentation layer but the UI, disseminating and distributing content.

        The role of the theme while understated by its definition in the rule is very important to not only the success of the application but the site it powers. Themes should therefore be able define all “non out of the box” functionality or at least have a role in saying how it affects functionality of the theme.

        No. That is precisely the purpose of a Theme. WordPress is designed such that the Theme is the content presentation abstraction layer.

        That maybe so, but the design and implementation of the layer is functional and requires functionality. What abstraction does is hide that functionality from the end user, attempt to remove then the applications becomes static, useless.

        The problem I am having is that WordPress has now officially separated presentation from functionality, so the installation of a WP blog / site is becoming more and more windows-esque Drivers (plugins) Required, taking 100 year (computer years) step backwards.

        Look I get the problem mixing design and code is bad, but lets fix it the standard way by encouraging devs to separate design from data and code and not by penalizing theme dev/designers for their innovation!

        • Chip Bennett 4:21 pm on November 28, 2012 Permalink | Log in to Reply

          Shawn, that is a discussion, and a paradigm shift, that is far outside the scope of this periodic guidelines review process. Such a shift would fundamentally alter the underlying principles of the guidelines, and not something that we’re going to consider as part of this exercise.

          If you do feel passionately enough about it, though, I would recommend starting a discussion on the Theme-Reviewers mail-list, where the discussion can be given a more full and proper treatment.

          • shawn 5:20 pm on November 28, 2012 Permalink | Log in to Reply

            I not sure I understand why, if a guideline is fundamentally flawed it should be automatically reviewed or at least redefined.

            You simply cannot separate presentation from functionality, it would be like trying to create a graph without the data.

          • Chip Bennett 5:27 pm on November 28, 2012 Permalink | Log in to Reply

            I disagree that the presentation-vs-functionality guideline is “fundamentally flawed”. Again: if you do feel passionately about the matter, please start a discussion on the Theme-Reviewers mail-list, and we can discuss it at length, with all interested parties.

            • shawn 5:48 pm on November 28, 2012 Permalink

              I will seriously consider putting aside some time for it!

              Thanks for your time and patience Chip.

      • wpweaver 6:51 am on December 1, 2012 Permalink | Log in to Reply

        I missed the start of this discussion, but I do have a few thoughts on this. My theme, Weaver II, does indeed include a quite a few shortcodes, and certainly some of them could be unbundled and put into a plugin.

        But at least two of them, and they are both heavily used by my theme’s users, really would not work outside the context of the theme’s support framework. One is almost an integral part of how users can present content – a show post shortcode. The main reason it can’t go outside of the theme is that it relies on theme settings and display functions to format posts – picking up all the theme local layouts, how to display post information, etc. It truly is integrated with theme design. One could remove it to a plugin, but that plugin would only work when integrated to the theme.

        The other is a shortcode to conditionally display content depending on the if the view is mobile. While my theme is fully responsive, it also can dispay things differently depending on the user agent – so it is really more than responsive. How does one separate the plugin from the mobile display model of the theme? Even if using just the responsive parts, there are still theme settings to determine when various display items switch.

        And as been mentioned before, updating an existing theme that had been forced to eliminate included shortcodes, would mean that literally tens of thousands of sites would instantly be broken upon update.

        I do appreciate the goal of switching theme and having things still work. But my theme does things that no other themes can do, and part of the capability is to provide an integrated environment for the site developer.

        So – I think there needs to be some kind of grandfathering of existing themes. It just would not be reasonable for thousands of existing sites to break just to enforce a rule.

        One possible aid to solving the theme switch problem would be to require themes with built-in content side shortcodes to provide some kind of plugin that provided near-equivalent functionality upon theme switch. This might be difficult in some cases (e.g., my post shortcode or conditional display on mobile devices), but I suppose one could come close. I’ve even had this on my development list to help my own users who might want to switch.

        And not to shoot myself in the foot, but what about Page Templates? My experience is that switching themes that don’t have similar page templates is actually harder than some shortcodes.

        But at the heart of it, I still believe that there is room in the free repository for higher level themes that represent more of a complete environment that includes tightly integrated widgets, page templates, and shortcodes. Not every user is ready to develop their own child-theme, or spend hours hunting through plugins to find the functionality that fits just right with some theme – if they can add their own CSS rules to make the plugin’s styling consistent with the rest of the theme.

        • Chip Bennett 11:58 pm on December 1, 2012 Permalink | Log in to Reply

          Given that Weaver already has an associated Plugin, I don’t see any reason that the bundled shortcodes can’t easily be shunted off to that Plugin. In any case, there are other ways to implement a “show_posts” shortcode (which is really just a wrapper for a custom WP_Query() call) in a custom page template) than having users put the shortcode in $post->post_content.

    • Philip Arthur Moore 12:09 am on November 27, 2012 Permalink | Log in to Reply

      Change Theme Screenshot (screenshot.png) maximum dimensions from 300x225px to 600x480px.

      Should this read 600x450px?

    • Vicky Arulsingam 12:59 am on November 27, 2012 Permalink | Log in to Reply

      Shouldn’t custom post types fall under the “presentation-vs-functionality” rule?

      In terms of exceptions, if the theme author provides a plugin for shortcode/custom post type functionality, is that acceptable?

      • Chip Bennett 2:25 am on November 27, 2012 Permalink | Log in to Reply

        CPTs are a separate discussion, and are already handled by the “special use-case” Theme exception.

        If shortcodes can be placed in a Plugin, and the user directed to install the Plugin if/when he switches away from the Theme, then why not short-circuit the Theme altogether, and just release the shortcodes in Plugin form to begin with?

        Asked another way: what is the compelling reason for a Theme to bundle post-content shortcodes?

    • Sayontan Sinha 1:22 am on November 27, 2012 Permalink | Log in to Reply

      +1 for accepting themes that offer bundled shortcodes/CPTs as plugins.

      • Chip Bennett 2:23 am on November 27, 2012 Permalink | Log in to Reply

        CPTs are a separate discussion, and already handled by the “special use-case” Theme exception.

        I see no reason for any Theme ever to bundle post-content shortcodes.

    • Danielx64 4:02 am on January 24, 2013 Permalink | Log in to Reply

      Can we please add remove “wp_enqueue_script( ‘comment-reply’ )” to the list and make it recommended? One reason is that some people (like me) wants to add a quote button and therefore they don’t need to use the above function.

  • Jen Mylo 5:10 am on February 16, 2012 Permalink | Log in to leave a Comment
    Tags: checklist, description   

    Every time I browse new, featured, or recently updated themes in the dashboard, I cringe because there are always instances of WordPress, wordpress, and Word press in the descriptions of the themes provided by the authors. In the absence of capital_p_dangit, could you guys add it to the checklist to do a quick proofreading of the description in style.css to make sure they spell WordPress correctly? It will help prevent my crow’s feet from getting worse. :) Thanks!

     
    • Nitin Reddy 5:27 am on February 16, 2012 Permalink | Log in to Reply

      Perhaps I should write a plugin that auto-corrects the casing of “WordPress” in the descriptions, assuming there’s a hook for it, if course :-)

    • Emil Uzelac 5:46 am on February 16, 2012 Permalink | Log in to Reply

      @Nitin Autocorrect will not work in style.css, nothing will unfortunately. This is something we need to do manually and it can be a requirement. http://codex.wordpress.org/Function_Reference/capital_P_dangit.

      As one of the admins/reviewers I think that this is very important, therefore it’s added in Theme Review as well: http://codex.wordpress.org/Theme_Review#Capitol_.22P.22_in_WordPress_.28capital_p_dangit.29

      If anyone else have better wording, feel free to change it. But that should be all right for now.

      Cheers,
      Emil

    • Edward Caissie 1:42 pm on February 16, 2012 Permalink | Log in to Reply

      There may be more significant consistency issues to address in the Theme Review process, but having WordPress spelled correctly is a rather straight forward request to be followed through with.

      Although I must admit I may not necessarily “not-approve” a theme for inclusion into the Extend repository if the only issue was misspelling WordPress in the theme description but it would be a required correction to be made in future releases of the theme.

      PS: @emiluzelac I did adjust the text and title of the new guideline you added … http://codex.wordpress.org/Theme_Review#Capital_.22P.22_in_WordPress_.28capital_p_dangit.29

    • Chip Bennett 2:41 pm on February 16, 2012 Permalink | Log in to Reply

      IMHO this is completely a bikeshed issue, and I think that the reviewers have far more important matters to worry about. If it must be a consideration, then put it in Theme Check, and make it a blocker in the upload script, so that the reviewers don’t have to bother with it.

      • Jane Wells 6:27 pm on February 16, 2012 Permalink | Log in to Reply

        Yes and no. It’s not a functional issue in terms of theme quality, but is in an issue in terms of trademark and quality control for wordpress.org. A code-based solution would be ideal and I can ask @otto42 if he can come up with something, but in the meantime, taking 2 seconds to look at that paragraph in the style.css file and shooting an email a la “Hey, you may not have realized, but you misspelled WordPress in your theme description. Could you please update it so that it is always spelled ‘WordPress’ in your description? Thanks!”

        It’s not really something to occasion worry, but it is a quality control issue.

        • Emil Uzelac 7:31 pm on February 16, 2012 Permalink | Log in to Reply

          If we do this let’s say, e-mailing the author’s and ask them to modify capital_p_dangit, will you be giving us @wordpress.org e-mail addresses, at least for admins? The reason why is simple, people don’t even respond when we e-mail them from our own addresses. I don’t blame them, I wouldn’t even bother responding to an e-mail address that doesn’t comes from WordPress itself because it’s looks and sounds like either SPAM or some type of phishing.

        • Edward Caissie 7:34 pm on February 16, 2012 Permalink | Log in to Reply

          If @otto42 is going to be tasked with finding a “code-based solution” to this issue, I would also suggest someone is tasked with finding a “code-based solution” to scraping the repository theme descriptions etc. and sending out a bulk email requesting theme authors make these “required” corrections.

        • Chip Bennett 7:49 pm on February 16, 2012 Permalink | Log in to Reply

          Wait: why would we need to send emails when we can just post a comment in the review ticket?

          If you’re referring to a retrospective review of descriptions of currently approved Themes: not going to happen. Especially considering that we still cannot clear the current review queue, such effort would be alarmingly counter-productive.

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel