Theme Review Team

Updates from June, 2015 Toggle Comment Threads | Keyboard Shortcuts

  • Tammie 7:18 pm on June 23, 2015 Permalink |  

    Theme review team weekly meeting notes

    The logs are here:

    Points from meeting:

    1. Directory survey: https://make.wordpress.org/themes/2015/06/22/survey-results-directory/

    • We should reconsider our keywords in our roadmap. Can we automate them? Can we have people able to update them?
    • We need to do a survey just on tags.
    • We began talking about how we should improve the admin interface for those with themes on org. The UI needs to be more friendly. How can they manage their entire theme?

    Actionables: @greenshady to think about tags and with me come up with survey suggestion. @grapplerulrich: to get an easy cull list of tags. Add to roadmap: tag survey, redoing tags, theme admin on org.

    2. Review survey: https://make.wordpress.org/themes/2015/06/22/survey-results-review/

    • Documentation is an issue. Could this be a language issue?
    • We talked about setting expectations for review time. This could be added to the uploader intro we are going to think about adding licenses to.
    • Would partial reviews be a solution, or do they cause more issues and create a bad experience?
    • Auto approving updates can speed up queues.
    • More we automate the better our queues.

    Actionables: @grappleulrich is moving the button to help with abandoned. v2 of the workflow will be put as make.blog post before our planning meeting on July 7th.

    3. Using WordPress.org themes survey: https://make.wordpress.org/themes/2015/06/22/survey-results-using-themes-from-wordpress-org/

    • We should consider in our roadmap the preview.
    • @otto42 is working on the preview and we should support what he is doing. This will bring the customizer to the front end securely. The user can then change things.
  • Tammie 10:45 pm on June 16, 2015 Permalink |  

    Theme review team weekly meeting notes

    The logs are here:

    Points from meeting:

    • Recent duplicate theme issue was talked about as raised by @otto42.
    • Proposed change: props @poena: Upload becomes ‘Add your theme’
    • Force theme uri field to be unique. Disallow same uri from being uploaded again
    • @karmatosed will make a meta ticket.
    • There will be no meeting this Thursday.
    • The doing_it_wrong theme and theme unit test are not our focus currently. Github is a good place to still add tickets though.
    • @grapplerulrich a link in the admin bar so long as not spammy we decided is valid.
    • The first meeting in July we will be a planning one.
  • Tammie 3:31 pm on May 29, 2015 Permalink |  

    Update queue automation. 

    Currently if you send an update in you have to wait for it to be reviewed again. What is being suggested would be that this gets removed. Themes that are updates get automatically updated.

    As we want to be transparent about any change, we are posting here for 24hours to get opinions before we implement this. We need to work out how to make it happen automatically, this may for a short while therefore be a manual batch process. The actual how is something we’re going to need to work out with this hopefully @otto42 can help us there?

    Other ideas include adding a check every 5 maybe updates to get human eyes on the theme. Is this something we should add as a clause?

    All opinions are welcome, so lets hear what you think.

    • Jami Gibbs 3:34 pm on May 29, 2015 Permalink | Log in to Reply

      I would also suggest adding a submission time limit before it gets kicked back into a review queue. For example, if the theme’s been on the repo for 6+ months, there may have been changes to the requirements since it was first reviewed (ie. customizer / theme options), so it should get a look over.

    • layerthemes 3:37 pm on May 29, 2015 Permalink | Log in to Reply

      +1 to the other idea!

    • Chip Bennett 3:38 pm on May 29, 2015 Permalink | Log in to Reply

      Great idea. It’s one less thing the team would have to worry about, and that much more incentive for developers to keep their Themes updated. I think the risk is minimal for auto-approving the update queue. It also lays the groundwork for possibly allowing direct SVN-commit access in the future. (The Holy Grail of Theme maintenance?)

      The primary risk that I see is bait-and-switch “gaming” the approval process, by submitting a basic/skeleton Theme, and then updating something else for auto-approval. Perhaps there are some ideas for how we could mitigate that? Perhaps some way of quantifying the amount of change in an update, and flagging if the changes are significant?

      • Piet Bos 3:17 am on May 30, 2015 Permalink | Log in to Reply

        Isn’t that risk already the same for plugins? Does it get abused in plugins often? I understand that there should be a focus on security at all times; on the other hand though I think that the amount of people that abuses or tried to game the system is far, far lower that the people with genuine intentions. Why then do people with genuine intentions seemingly always have to suffer the regulations put in place to catch a few bad apples. On top of that, I think that people with bad intentions will be able to game the system anyway, regardless of whether you make it difficult…

      • Justin Tadlock 4:00 am on May 30, 2015 Permalink | Log in to Reply

        I actually see the primary risk as frequent, trivial updates to bump download numbers. It’s something we were already dealing with a few months back. I remember one of the themes made a readme.txt change as an update.

        But, I think automation would be a good thing overall.

        • Towfiq I. 7:06 am on May 30, 2015 Permalink | Log in to Reply

          that sounds like a problem..it would be very easy to game the system.

        • Towfiq I. 7:51 pm on May 30, 2015 Permalink | Log in to Reply

          However this can be easily fixed if the “Active Installs” is introduced in the theme directory like plugin directory and Sort popular themes by active installs, not download count.

          SO +1 for Active Installs count in theme repo.

          • Justin Tadlock 8:48 pm on May 30, 2015 Permalink | Log in to Reply

            Yep, that fixes the issue if popularity is based on active installs rather than downloads.

          • Justin Tadlock 5:51 pm on May 31, 2015 Permalink | Log in to Reply

            More thoughts:

            While active install count is a better metric for a theme’s popularity, that can’t be the only metric for popularity. Otherwise, you have themes that get in the top and stay there forever with no chance of getting bumped out. Currently, I believe, it’s done weekly based off download counts. That can be gamed to some degree, but bad themes will generally fall out naturally. And, while it’s possible to stay in the popular themes list, this method provides opportunities for new themes to come and knock old themes out of the top spots. I wonder if there are weekly stats based on the number of new active installs.

            That’s why I’d love to see more filters – popular this week, popular this month, popular all time. Then, further sort popularity by installs and/or downloads. Sort by star ratings, user favorites, etc. That’s the good stuff.

    • dmccan 5:08 pm on May 29, 2015 Permalink | Log in to Reply

      Are there auto checks, that don’t give too many false positives, that could be kicked off when a new version is submitted? If so, that might help to prevent gaming and provide a minimal check.

    • Star Verte LLC 6:33 pm on May 29, 2015 Permalink | Log in to Reply

      What if we set a standard for major vs minor updates, with major updates in the x.x variety, and minor updates in the x.x.x variety? Feature updates are major, small improvements or bug fixes are minor. Part of the automated theme check looks at diff stats and verifies a minor update is truly minor—less than 20% change?—and minor updates are automatically approved after passing the theme check.

      We should also add a “tested up to” like plugins do and coordinate revisions of theme guidelines with core releases. Then, we encourage theme authors to make sure their theme still works with the latest version and implements new guidelines. We could even add automated tests that run checks based on this value, and force updates to support the latest 2-3 versions. This last point is based on the requirements regarding backwards compatibility.

      While it is not the role of this team, and plugins are completely different from themes, if we can figure out a process that works well for themes, we should look at modifying it for plugins. Particularly when it comes to security, plugins should be reviewed, at least programmatically, periodically as well.

    • Nilambar Sharma 3:44 am on May 30, 2015 Permalink | Log in to Reply

      Great idea. Check after some number of updates is crucial.

  • Justin Tadlock 7:03 pm on May 27, 2015 Permalink |  

    Front page demo content 

    It has recently come to my attention that several themes are adding full front-page demo content to show off their themes in the theme previewer. Basically, this is not cool.

    No, there’s no specific guideline in the handbook against it. I really don’t think there needs to be one. This falls under the universal don’t try to game the system guideline.

    What I’m seeing in several cases are theme authors outputting things so that their themes have an unfair advantage over other themes when previewed via the WordPress.org theme previewer. We take gaming-the-system issues pretty seriously around here.

    Update: I wanted to clarify that I’m not calling all devs who do this cheaters. I’m sure many are good people trying to do good things. As admins of the TRT, we have to take a stern look at things sometimes and view things at their possible worst.

    Update #2: Deleting/Rewriting the examples section because I’ve had a few theme authors ask for clarification. What specifically prompted this post are themes that are overwriting the front page with a demo HTML file, with things like a fake contact form, one that’s not even packaged with the theme. This doesn’t refer to themes that are outputting sane defaults for theme options that have not been configured.

    Essentially, a lot of this really comes down to themes not respecting the users “Settings > Reading” settings. By default, sites are going to show the blog posts index on the front page. This should be what is shown. It’s what is shown in the WordPress.org theme previewer. I highly recommend reading this tutorial.


    We have to catch this sort of thing. It’s next to impossible to miss when you install/activate a theme, which all reviewers should be doing.

    The WordPress.org preview doesn’t show off my theme

    We’re all aware of the issues. Believe me. I’m right there with you. I just ask for patience, discussion/participation about making the previewer better, and the use of sane defaults.

    Here’s the meta ticket if you want to get involved with better demo content.

    • Chip Bennett 7:23 pm on May 27, 2015 Permalink | Log in to Reply

      We really need to think about auto-output “demo” content (Lorem Ipsum, Theme promotion, etc.) in general. What is the user experience when the user installs a Theme initially, and the user’s site becomes “lorem ipsum”, or worse: a Theme promotion?

    • ThinkUpThemes 9:00 pm on May 27, 2015 Permalink | Log in to Reply

      Hi guys.

      I’m really unclear here. Many devs add some form of demo content which is useful to the user. Often saying things like “you can find me in…”, “turn me on / of from here…”. This is useful, and the user can disable it in seconds. I’m struggling to see how this can be viewed as deceitful and gaming the system.

      Where a theme only shows demo content that is shown in the screenshot, that seems very honest to me, not an attempt at seeking an unfair advantage.

      Just wanting clarification on this point.

      I do agree however, that theme previews where there are masses of content, row after row, not indicated at all in screenshot can be highly misleading and questionably lead to an unfair advantage. Although with a quick scan through the most popular list (to approx 20), it looks like around 50% have some form of demo content. If demo content is considered to significantly provide the theme with an unfair advantage then would one not expect to see a higher proportion of popular themes with the form of demo content you bring into question?

      Finally, if we’re claiming that those who use demo content are are gaming the system then this is essentially calling these devs cheaters (the lowest of the low). As such I’m sure you guys have a ton of evidence backing up this claim. Please do share this.

      By the way I’m not looking to have each of my above comments blasted, I’m just keen to understand this better.


      • Justin Tadlock 9:41 pm on May 27, 2015 Permalink | Log in to Reply

        Whether it’s done intentionally or unintentionally, the admins have to view this as a form of trying to game the system. It’s something that we’ve always had to deal with in one form or another. It’s just part of the job description. We have to deal with these things swiftly and, sometimes, severely.

        I’m sure any one of us will be more than happy look at something you have in mind if you think one of your themes might fall under this. This also doesn’t have anything to do with the screenshot. It’s primarily about creating a custom front page (that doesn’t respect Settings > Reading and, thus, not allowed) and putting a lot of demo content in when the theme options haven’t been configured.

        We will not be publicly sharing any themes and/or evidence about those themes. We do not “call people out” specifically. We will be dealing with these on a case-by-case basis. This is more or less an announcement that we’ve been made aware and are on the lookout for this sort of thing.

    • Omaar Osmaan 9:29 pm on May 27, 2015 Permalink | Log in to Reply

      Thanks to @otto42 to make a blog for creating the new demo-data for previewing Themes on the directory.
      Here’s the URL to take a peek and suggest what it could be: http://ottodestruct.com/democontent/

      I would really love to see a nice data set that can help to understand a lot of time how the theme can look and function before downloading the theme.

      And as a developer, I’m tempting to make my theme-demo looks good, too.

    • wpHoot 5:52 am on May 28, 2015 Permalink | Log in to Reply

      Hi Justin,
      Thanks for bringing this to notice.

      I dont have it in my themes yet, but I was thinking of adding something like this in the future.
      Honestly, in my head this was to have a better user experience, rather than the whole preview thing..

      Let me be specific using an example.
      1. If a user has “Your Latest Posts” selected:
      a) Have a slider saying something like “you can find me in…”, “turn me on / of from here…”
      b) Below this is the post list like one would expect
      2. If the user has a static page for front page, then that page is displayed without the demo content.

      I am assuming that even something like the slider in 2(a) above would have to go away… Correct?

      Thanks in advance.

    • Sami Keijonen 6:59 am on May 28, 2015 Permalink | Log in to Reply

      It’s no secret that some themes are doing pretty well if they stay high in popular themes list. Before it was features list also. I assume there are several reasons how can you stay up in popular themes list.

      • They are great themes
      • Good marketing and timing
      • Update often, more often than necessary. Same happened in plugins repo before
      • Mess with front-page.php, home.php or index.php template to get much much better theme preview in .org. This can involve sane or insane default also

      I’ve been also experimenting how to get better theme preview in .org.

      • Set default header image.
      • Set default background, at least for color.
      • Set default Widget in sidebar if there is one. I decided to set default Core widgets for Subsidiary (Footer) Sidebar.
      • Main menu should display pages as fallback. I personally don’t like this because user might not want to use main menu. And even user leaves the menu empty there would still be HTML markup in the front-end.

      I was really close to mess with front-page.php but it was bending default behaviour of WordPress in the wrong way: users can’t show latest post in front page unless you add additional setting in the Customizer. At least that was the case in my experiment.

      I have written more about my experiment in my blog.

      Anyways I’m glad that discussion about gaming the system is open.

    • Jami Gibbs 11:42 am on May 28, 2015 Permalink | Log in to Reply

      Having better demo content is a good start but this doesn’t solve the larger issue. Post demo content is really only valuable for blogging themes that are displaying posts on the home page in this way. If a theme’s home page doesn’t use posts on the home page like this (common for niche themes), then we’re back at square one.

      I’ve struggled with this issue too and came to the same conclusion as Sami in that I don’t want to add a bunch of extra demo content or conditionals into my theme just so the home page template displays as intended. So I just removed it all completely. The reward for not gaming the system is having an abysmal demo on .org.

      I really only see two avenues here:

      a) Change the demo link to the author’s own demo page (not the .org install).
      b) Allow the author to use their own demo content on the .org preview.

      • Jami Gibbs 11:58 am on May 28, 2015 Permalink | Log in to Reply

        A few more thoughts:

        c) Add both a repo demo link and an author demo link
        d) Add a theme setup instructions tab (similar to plugins). This way users will know to assign the home template page in the Reading setting or however the author recommends setting up the theme.

      • Samuel Wood (Otto) 2:12 pm on May 28, 2015 Permalink | Log in to Reply

        If a theme’s home page doesn’t use posts on the home page like this

        If I have the Settings->Reading “Front page displays” set to “Your latest posts” and the theme fails to do that, then the theme is broken and should not have been approved to be in the directory in the first place.

        • Jami Gibbs 5:39 pm on May 28, 2015 Permalink | Log in to Reply

          Apologies if I wasn’t entirely clear. I am talking about themes that respect “Settings > Reading” settings but the author intends for the theme to display a custom home page template. There’s no way for an author to apply that custom home page template right now.

          It does the theme designer a disservice and misrepresents the theme when demos are forced to display the default blog post listing. It doesn’t represent the theme.

          • Chip Bennett 5:51 pm on May 28, 2015 Permalink | Log in to Reply

            Bear in mind that we’re talking about the Theme previewer hosted on wp.org. There are obvious security concerns with allowing arbitrary content, even if there were an elegant way for Themes to indicate that they should display a static front page by default. These aren’t questions and issues that can be resolved by the TRT alone.

            If the wp.org previewer isn’t sufficient to show off a Theme’s potential (and everyone would agree that it isn’t, especially in its current state), developers always have the option to host their own Theme demos. I would even be supportive of adding some UI (such as a “Demo URI” keyword?) that would allow developers to point users to an external demo.

            But adding into the Theme code that bypass core settings, and that display static HTML that isn’t even being generated by the Theme, and many other things that we’ve encountered that try to do some kind of workaround, is not a viable solution. It’s not just the wp.org previewer we’re concerned about; it is also the behavior of the Theme in its default state as installed on end users’ sites.

            • Jami Gibbs 6:31 pm on May 28, 2015 Permalink

              I agree that displaying static HMTL is gross and not the solution. That’s not even something I’m talking about or suggesting.

              I just want a proper demo for my home page template. I’m not talking about overriding default WP behavior. I’m talking about a custom home page template that’s assigned to a page and set in the Reading settings.

              I don’t want to force the theme to apply this page. I’m not setting up a bunch of static HTML and conditional nonsense.

              Potential users of my themes should see the home page template in the demo. This template is applied manually. It’s not overriding or bypassing anything.

              In the current state, the author demo link isn’t very obvious and sometimes not easy to navigate to. You’d have to click the “Theme Homepage” link (below the prominent “Preview” button which is where users will go by default) and navigate your way around the author’s theme description page for the demo link (which will be setup differently from author to author).

              Allowing an author demo link (not just a theme description / homepage link) would be a good compromise. Something like a “Default Theme Demo” and “Author Theme Demo”. It should be clear to the user what they’re looking at.

      • Omaar Osmaan 12:02 am on May 29, 2015 Permalink | Log in to Reply

        Totally agree with “Author Theme Demo” idea- it could be a great edition to previewing theme before downloading a theme.

    • codeinwp 11:48 am on May 28, 2015 Permalink | Log in to Reply

      Hey Justin,

      While I appreciate that you are opening this for discussion, I don’t appreciate your attitude and way for looking at this.

      As @thinkupthemes is saying 50% of the most popular themes is doing it, have tried to ask yourself why ? Just because they like to game the system ? Do you really believe this ?

      I personally did that not to game the system, to get downloads, money or fame, but because the option that you are suggestion is useless and just waste people time, and I will explain why ( I already did that in the Responsive 2 ticket few month ago as well ) :

      User x sees Zerif image, he loves it and he wanna use the theme, based on your logic, they will be forced to see a useless preview, to install the theme and see again a useless preview and to go in forums/documentation and learn how to create a new page and set as front-page.

      Based on my logic and other authors, we deliver to users the experience that they expect/want/need/seen, without wasted time and extra steps, with the tools that we have ( using latest news section for latest news + other content ).

      I was looking on 100s of Zerif theme users and NOBODY is using the blog as homepage, nobody want this, why force them to do it ?

      Why instead of enforcing a bad experience/rule we can’t come with a solution ? Just because is harder and we don’t really care ? or pandora boxes and mystical stuff ? :)

      Allow the authors to change the reading settings automatically on the theme basic and everything will be fine, also what cyberchimps/ @grapplerulrich did here : https://themes.trac.wordpress.org/ticket/20991 was awesome, but you, @frank, @emiluzelac disagreed .


    • codeinwp 3:41 pm on May 28, 2015 Permalink | Log in to Reply

      It is a core issue, but that doesn’t mean we just need to pass the problem to somebody else, I think we as a team need to care and do whatever we can for the best user experience with the tools that we have, there are solutions even if the core team add this or not.

      • Chip Bennett 3:43 pm on May 28, 2015 Permalink | Log in to Reply

        If you care about a solution, then get involved with the core ticket. That is the path forward to enabling Themes to auto-select a static front page. We will not do anything contrary to what core does.

    • Carolina Nymark 3:44 pm on May 28, 2015 Permalink | Log in to Reply

      That is why we are having a ticket meeting tonight. Lets not sit and wait for others if we can contribute.

    • codeinwp 5:43 pm on May 28, 2015 Permalink | Log in to Reply

      Sure, as you see in the ticket, Hardeep which is part of our team, asked some updates few months ago and I got it in discussion here : https://themes.trac.wordpress.org/ticket/20991 and on different channels however people were totally against, so I just stopped trying to do something.

    • Justin Tadlock 6:12 pm on May 28, 2015 Permalink | Log in to Reply

      I’ve updated the post to provide some clarity of the issue that we’re specifically dealing with.

    • Chip Bennett 7:33 pm on May 28, 2015 Permalink | Log in to Reply

      I wonder if it is worth considering to change the base settings of the wp.org Theme previewer to display a static page, instead of the blog posts index, on the site front page?

      The page assigned as the front page can still have default demo content, so it will not look bad for Themes that don’t do anything special with front-page.php. And the blog posts index would still be displayed using the page assigned as the posts page.

      That’s probably a question for @otto42?

      • Samuel Wood (Otto) 7:38 pm on May 28, 2015 Permalink | Log in to Reply

        Actually, I was thinking about making it show the customizer screen, with some special handlers to eliminate things like file uploaders and the like.

        • Chip Bennett 7:40 pm on May 28, 2015 Permalink | Log in to Reply

          Even more elegant! That would let users test-drive all of the Theme settings, as well as front-page, etc.

          • Samuel Wood (Otto) 7:50 pm on May 28, 2015 Permalink | Log in to Reply

            That was my thinking. Still looking for a clean way to not show uploaders and such, but any uploads would fail anyway so it’s not a very big deal.

            Current plan:

            1. Get better preview data (in progress)
            2. Figure out how to show the customizer properly and eliminate weirdness (in progress)
            3. Lock the previewer database down to read-only mode. No modifications by anything, including themes. (todo)

            Note that number 3 means that theme defaults become a very big deal, as you well understand. Might be worth coming up with a test protocol for that, BTW. So that we can sort out problem themes before it becomes an actual problem. I can dig up the necessary MySQL commands to make you a read-only user to work on a test site, if needed.

            • Chip Bennett 7:54 pm on May 28, 2015 Permalink

              Once #1 is taken care of (one thing at a time), perhaps you could set up a test server for theme previews? Then we can use it to hash out some of the expected (and unexpected) issues?

            • Samuel Wood (Otto) 8:24 pm on May 28, 2015 Permalink

              If you want to try out a read-only user on your test setup, BTW, here’s the MySQL commands to make one:

              create user 'USERNAME'@'localhost' identified by 'PASSWORD';
              grant select on DB_NAME.* to 'USERNAME'@'localhost';
              flush privileges;

              Then just change the wp-config.php to use that new username and password. It will only have permissions to run “select” statements. Note that the admin area gets, well, a bit weird when you do this, but the front end seems to run okay for the most part.

            • Omaar Osmaan 12:17 am on May 29, 2015 Permalink

              Ah- that’s a great route! ‘Read-only’ mode and allowing to ‘Play with settings’-

            • Omaar Osmaan 12:40 am on May 29, 2015 Permalink

              You may know it probably,

              (1) Setting up a ‘WP user’ with ‘manage_options’, and ‘theme_mod” permission

              (2) Disregard/redirect any ‘Ajax’ calling

              allows the user to access the customize panel without any issue.

              The (2)nd step may be unnecessary when the DB sets to read-only mode.

              I’ve tested a setup where a ‘Customize’ button loads the customize panel and auto-sign-in the visitor to a ‘demo user’ mode, where the visitor able to test-drive customize options but not able to upload/save any of the settings.

    • tskk 1:13 am on June 3, 2015 Permalink | Log in to Reply

      Are theme authors allowed to have other sections around the section/area which respects “Settings > Reading” setting?

  • Tammie 9:22 pm on March 2, 2015 Permalink |  

    Agenda for this week’s meeting

    We’ve got a meeting at 18:00 UTC on Tuesday (tomorrow) in Slack #themereview.

    A suggested agenda:

    • Lets talk abandoned and missing in action tickets. How can we handle them better? What mechanism can we have to make this more robust?

    Any other subject people would like to talk about?

    • Tammie 9:22 pm on March 2, 2015 Permalink | Log in to Reply

    • Patryk Kachel 7:08 am on March 3, 2015 Permalink | Log in to Reply

      Maybe we can reassign abandoned tickets via button? First move them to “abandoned” queue and then assign via “request button”. Maybe we can even move tickets automatically to “abandoned queue” when there is no response for 7 day.

    • nitkr 8:50 am on March 3, 2015 Permalink | Log in to Reply

      +1 for Urlrich’s suggestion for abandoned ticket, but now it seems a reviewer cannot re-assign it.

      If a theme author is aware about their ticket queue priority(which will be high) for re-assignment, it will surely bring down the amount of re-assign notifications an admin receives.

      I also think, rather CC’ing an admin about re-assign and closed-newer-version-uploaded tag, if they are also made available for reviewers it could be handy.

      • Ulrich 10:53 am on March 3, 2015 Permalink | Log in to Reply

        The problem is that we are unable to set the themes to status new. @otto42 Do you think it would be possible to get an option added to the UI to be abe change the status from reviewing to new?

        • Tammie 10:56 am on March 3, 2015 Permalink | Log in to Reply

          I would be against that. It’s a psychological step back for any review to be then put as new again. We also have the knock on effect onto a few reports then. Lets not have that as an option.

      • Tammie 10:57 am on March 3, 2015 Permalink | Log in to Reply

        A reviewer shouldn’t be able to re-assign. Finding a way to do this without having re-assigning on the reviewer side is essential.

        • nitkr 11:44 am on March 3, 2015 Permalink | Log in to Reply

          I agree with you, as I could see admins are getting notifications for re-assignment, I guess re-assign option could ease an admins work(a bit).

          I did see those re-assign options for re-opened tickets of navsingh, so that made me ask.

    • Maria Antonietta Perna 10:24 am on March 3, 2015 Permalink | Log in to Reply

      Last week I plucked up my courage and decided to click the Request a theme to review button. I’m not an expert and I only had my first WP.org blogging theme approved less than a couple of weeks ago (it’s not live yet). However, I read about the presence of mentors for new reviewers and this convinced me to take the plunge. I pressed the button and I got assigned a feature-rich magazine theme with quite a few theme options and other stuff. At the same time, I don’t know who the mentor for this ticket is or if I can talk to him/her about my concerns. On the other hand, the options on the ticket are quite restrictive: approve or don’t approve and I don’t feel that I can make this decision by myself at this very early stage. I hope today’s meeting will be of help.

      • Ulrich 10:50 am on March 3, 2015 Permalink | Log in to Reply

        Great, We are working on improving the mentor process. When reviewing the theme you should leave it on status reviewing so that the ticket stays open and the theme author can upload updates. If you have any questions you can ask them in the Slack #themereview channel. There is always someone there who can help. Ping me on Slack if you have any more questions. :)

    • Maria Antonietta Perna 11:09 am on March 3, 2015 Permalink | Log in to Reply

      Thanks, Ulrich!

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc