A few points: First, if someone believes that a ticket was closed prematurely, or based on mostly non-critical issues, the first recourse is to leave a comment, stating such, in the ticket. That is the primary - if not the only - way to engage in such dialogue. Reviewers are volunteers, are all human, and are subject to mistakes and inconsistencies. It never hurts to ask. Second, if someone is unsure about how to meet certain guidelines, or what certain guidelines mean, ASK. Ask in the review ticket following a review. Ask on the mail-list before submission. The Theme Review Team can't know what developers are struggling with if they don't ask us - and when they DO ask us, we are always willing to help answer those questions. Without such communication, we can't differentiate between the developers who are truly trying to play by the rules but are struggling to do so, and the developers who are simply throwing pasta against the wall to see what will stick. And given the workload of the review queue, unless we know that a developer wants help, we don't have a lot of time to spare to try to differentiate. Third, Reviewers *should* be more active now, both with following up on subsequent tickets and also with holding tickets open to allow for submission of follow-up tickets. But these actions are completely at the discretion of each reviewer. Again, the best way to ensure that a reviewer will exercise that discretion is to communicate in the ticket, so that the reviewer knows that you are doing what you can to pass the review successfully. These two issues: review turn-around time, and number of times through the review "cycle", are at odds with each other. The more we focus on shortening the turn-around time, the less time is spent with each ticket, thereby increasing the number of times a Theme may undergo a review before ultimate approval; conversely, the more time we spend ensuring that reviews are thorough and complete, so that a Theme undergoes fewer reviews before approval, the longer the review queue grows, and therefore the greater the turn-around time becomes. Ultimately, the way to short-circuit those competing odds is to *communicate*, in the ticket, with the reviewer. Chip On Mon, Mar 19, 2012 at 1:49 PM, Mario Peshev <mario at peshev.net> wrote: > At some degree Chip is right about the fact that the volunteerism in the > theme review process takes a lot of time and adding 2 or 3 revisions to the > long cycle takes sometimes months for a theme to get to /extend . However > this is somehow annoying when 2 or 3 reviewer remarks mark a theme as > non-approved and require a new submission and few weeks of review next. > > Changing few lines in a ready theme might cause side effects to other > portions of the site. Building a theme is a small ecosystem and a small > changes in a file could break the entire flow in some cases . > > All I'm saying here is that I see people publishing their own themes on > 3rd party markets instead of adapting them to WPORG as it seems long and > hard. Correct me if I'm wrong but the second major purpose of /extend > themes repo is helping people submitting and receiving back and speeding up > the process is a priority task. Step 1 is keeping the repo error free and > standardized - and that's a cross point decentralized what we have, in my > opinion. > > The 'easier' is taking the approach "approved but fix in next update" when > we don't have crucial things instead of "non-approved, fix, resubmit and > wait 2 more weeks". Some tickets are closed due to 2 or 3 non-critical > errors at least to my understanding: > > > > > Sometimes I see reviews too harsh and cold although helpful and pushing > people back. It causes the psychological phenomenon 'fear of rejection' at > the end. > > I don't mind reviewing according to the Guidelines. I don't mind building > themes from scratch with the Theme Review list in mind. All I see are free > themes that work being secure enough and used online without being able to > get inside of the repo. > > > Mario Peshev > Training and Consulting Services @ DevriX > > > > > > > On Mon, Mar 19, 2012 at 7:02 PM, Merci Javier <mercijavier at gmail.com>wrote: > >> >> I'm not sure what you mean by "easier rules for working Themes" either. >> BuddyPress themes submitted to the WP Repo go through the same thorough >> reviews - Theme Unit Tests. Debogger, etc. Some BP themes which had been >> approved some time ago have even been removed from WP Themes Extend page >> because they have not been updated to the latest BP version. >> >> >> *>>* *have to spend tens (if not more) hours to keep all the rules in >> place, such as defining classes for byauthor and sticky and many many more >> irrelevant for themes being used as web site templates.* >> >> Less than an hour to add minimum theme requirements of index.php, >> comments.php and screenshot plus style.css - >> >> >> >> _______________________________________________ >> theme-reviewers mailing list >> theme-reviewers at lists.wordpress.org >> >> >> > > _______________________________________________ > theme-reviewers mailing list > theme-reviewers at lists.wordpress.org > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <>