Imagine that you go to the bank. There you get a ticket: A208 (for example), under this number you also will see such words: “You are 23 in the queue.” But actually you are not 23 (you may be 54), because there are tickets with other letters: D103, I406, G343 and so on. You are 23 person who has ticket with A letter. And in fact, you didn’t know where you are in the queue exactly to this ticket window. That is how banks work (at least in my country). And it’s normal.
You may simply write “There are 58 items before yours”. And after this message do a small button with ”?”. When mouse over this button, people can see the explanation that they are actually not 58, that this number can be higher in the future because… reason, reason, reason. And that is all!
Yup, I completely understand this concept and banks here work the same way. That said, there’s a specific purpose for this. You are given a number because they don’t want you to have to stand in a long line to wait your turn. Instead they provide you with the convenience of sitting down but still understanding when you’re up next because you physically have to get up and go to their counter.
A system like this is, for the most part, valueless in a digital queue where no action is required by the user. So what is the value to the user (you guys, the authors)? It’s in knowing how close your item(s) are to being reviewed. But you authors won’t be able to know that without knowing how long items take on average to be reviewed in recent history. There’s lots of considerations that start coming up in order to implement this well so that it doesn’t begin raising thousands of unnecessary questions based on everyone’s perceived judgement of the historical progress of the queues.
However, like I said before, we’re not saying this won’t happen, we’re just saying not in this particular iteration.
Thanks for understanding guys!
@ jremick: why don’t you simply show our position in queue like some years ago?
@jremick no one is expecting to see exact time when the review will be done, and as far as I remember no one asked for that. Authors only need to know some sort of numerical information related to their queue position. Whatever system you have and how complex it is, it is not relevant to simple fact that your system knows how many items are submitted as new items and as updates, and that it knows position of each item. Why you don’t want to show this is beyond me.
Again: no one expects exact information, but something that has a meaning for their current position in the queue. Even if item changes queues, new items are added and removed, but in every point item has to have position that can be easily determined, it doesn’t matter when it will get reviewed, only position in the queue.If you don’t want to do so, OK, it is your right, but at least rename the name of this topic: removing a feature and replacing it with something totally useless is not ‘fixing’. You fixed nothing, you choose not to fix it and only remove the whole feature. Let’s call things as they are.
First let me clarify that one reason we’ve chosen not to display some form of numerical information is available resources (people’s time) and project priority. Think of this as our “MVP” solution for this iteration on this component. No, it’s not ideal (we all, staff included, agree with you on that), but it’s the right decision given all the situation variables.
Thought it might seem simple to just add in a couple numbers, it can use more time than you might think. That isn’t to say it’s a large piece of work, but there’s many other, much higher value, pieces of work going on that are currently higher priority. But let’s be clear; we’re not saying that further improvements won’t ever happen. We very much intend on making future improvements!
As you might know, I used to be Review Manager (I’ve since changed roles) and I know the review system and its data intimately. I was responsible for initiating changes in the review system “flow” that increased its complexity (causing the need for the progress bar to change) but also improved review efficiency. The progress bar has long been a complaint, but more importantly it has been a resource consumer. We get support tickets, emails, forum complaints and tweets about it and due to it. When you combine all the time spent on those inquiries, it adds up to a massive amount of the team’s time that could be spent improving other areas of the system and authoring process.
However, the progress bar is not an easy one to fix. You can’t predict that a reviewer will get sick, causing a multi-day delay in review turnaround time for one or more categories. You can’t predict when a software release will cause a flood of high priority item updates, causing delays to everything else in the queues. The system complexity is at a point where accurately predicting when any given item might be reviewed is a difficult task. That isn’t to say it can’t be done, but that it’s not something we can quickly do and isn’t among our highest priorities (there are many more features you all have asked for that are more helpful and valuable, therefore higher priority).
So we need to reduce the resource consumption the progress bar was causing (so we can actually use those resources for making things better) but also fulfill the purpose of that little box you see once you’ve uploaded your item.
But what is its purpose?
- Provide accurate information about the current state of your uploaded item
- Set an expectation of when it would be reviewed
This change improves the available information about the current state of authors’ uploaded items but also, importantly, resets authors’ expectations about when we say their items will be reviewed. The accurate answer to that is we don’t exactly know and it’s not right for us to knowingly provide inaccurate information that sets expectations we may or may not be able to meet.
The progress bar may have felt good for some, but, unfortunately, gave a false sense of “progress”, which was more frustrating when something didn’t go as you expected (eg. the bar moved backwards). So I know this change might feel like a step backwards, but it’s really a step toward a better and more accurate system for indicating status and progress of your uploaded items. Sometimes you have to take a step back before you can take two forward.
From here we can consider the best ways to indicate estimated time to review, average turnaround times or other information. Most importantly, this enables us to spend more of our time making things better that are more helpful and valuable to all of you, rather than spend that time continually answering everyone’s questions about why the progress bar is jumping around like a neurotic monkey.
I understand you are allowing “upgrading” of files but not “downgrading”, however is there a list of what constitutes a sufficient alteration to a file?
The variations policy states “It has been rebuilt to primarily serve the purpose of the extended functionality (eg. eCommerce) ok so the judge of this is down to the reviewers knowledge and opinion? I think it would be wise to have a slightly more definitive explanation or criteria of change (unless I have been stupid and missed it)
We agree! The policy needs more definition and examples, which we will work on providing in the coming weeks.
A forum thread was recently started in which some members of the community wanted to discuss “lite” versions of themes being sold along side the full featured version.
This was a great question to ask as it has been a point of confusion for quite some time now.
But first, some history…Originally our undocumented policy around this was a strict No. However, over time, things have changed and the benefit to both authors and buyers, if done correctly, makes sense. Just like in every other major marketplace, versions of a core product or “upgrades” are commonly available. As the demand for eCommerce grew, so did the demand to sell a standard theme and an eCommerce version, separately.
Once the pricing for these features was reconsidered, we also eventually reconsidered allowing an eCommerce version to be sold separately as the work involved was often significant and justified a price increase. These themes commonly had an eCommerce focus rather than being an all-in-one like we see frequently today. eCommerce support is also much easier to add to a theme than it used to be.
As the marketplace landscape continues to change, there’s an increasing demand for theme variations and themes that focus on a certain purpose. To better accomodate this demand for both authors and buyers, a limited degree of theme variations would need to be allowed (ie. not strictly limited to eCommerce). However, as we had no documented policy for this, we have worked towards getting things like this both clarified and documented publicly.
The Updated WordPress Variations PolicyYou can read the recently published variations policy here.
Our goals for this were to:
- Document the existing policy publicly
- Clarify where the “line” is which justifies a new version
- Adjust the policy according to community feedback and demand
We have completed the first and are working on the second and third. We are listening to community feedback and discussing the future of the policy.
What is the policy?In short, “lite” theme versions are not permitted. However, multiple theme versions are permitted.
What we’re trying to be careful of here is the confusion around what a “lite” theme is. There has been many instances where a “disabled” version (most often called “lite”) of a theme has been requested to be sold (either separately or on its own) in which the buyer could then “unlock” the full set of features via subsequent purchase. We do not feel this approach is appropriate for ThemeForest and have not allowed it. So the term “lite” had become associated with “not fully functioning.”
We want to make clear that the minimum requirement for ThemeForest items is fully functional products (a “standard” product).
Beyond this, however, a theme can have significant additions in functionality and purpose that justify a new version being sold (just adding a plugin and a few extra styles will not cut it). If a new version of a theme is permitted, it does not mean it can be sold elsewhere when you are an exclusive author. The core product is still viewed as being the same and we feel this would breach your exclusivity with Envato. The only exception to this is when the theme has been rebuilt for another platform (eg. WordPress vs Drupal).
Questions that need to be answered…
- What is a “standard” WordPress theme?
- Won’t this flood the marketplace with versions of everyone’s themes?
- Are there future improvements planned for this policy? If so, what are they?
We will be working to answer these questions and clarify the policy documentation in the coming weeks. Please let me know if there’s any questions I’ve missed or clarifications you’re looking for in the policy documentation. Thanks, everyone!
Unfortunately I’ve not been able to respond to this thread as quickly or as often as I’d have liked. As you can imagine I’ve been very busy working on various projects for ThemeForest and, most importantly, discussing the feedback everyone has provided here with the different teams. This tends to take a little time, thus the delay in followup to this thread.
I realize this policy comes as a surprise to some of you, although it has actually been in practice for some time now (though without official clarification or documentation). This is an area the team is working hard at improving (documenting and improving submission requirements, policies, etc).
Tomorrow morning I will be clarifying the concerns in this thread via a new thread where the discussion can more appropriately continue, which will be easier for me to compile and discuss with the team so we can make the necessary appropriate changes.
Thanks for understanding, everyone!
Bwt just currious if there is any plan/possibility to dispay “Last two weeks processing time” chart (days from submited to approved) for any selected marketplace/category ? So authors would know about what to expect. Best Regards, Andrey
This is not planned for the near future, though it is something we’ve thought about in various implementations. If something similar to this becomes a reality, we will update the community.
How in this situation we should plan exact time of our releases? Progress bar have helped us at least to plan it. New system is destructing this process. Please do not implement it.
Planning for an exact time of release has been a guessing game of sorts with or without the progress bar. A better solution for this would be providing information somewhere on average review turnaround times over a period of time. However, a solution like that isn’t currently in the works at this time and likely wouldn’t be an ideal solution to solve the “release timing” issue. Functionality allowing authors to publish at a specific time (once approved) would make more sense, which is an idea I hope to investigate further soon.
One of my items still on the queue for the 6th day and the progress bar still on the same position (80%) from Wednesday but items on the home page getting in. So it is not improvement.
The change hasn’t been deployed yet. This thread was advanced notification that this would be happening soon.
I wonder if it’s possible to display a numerical review status for each item, based on how many items are going to be reviewed before it.
For example, I post a sound effect and at first, it begins with:
Reviews to go: 238
Every time an item is reviewed, the number will count downwards until it is the very next item to be reviewed. Once it has been reviewed, it will leave the queue.
There could be separate queues based on what kind of submission the item is, whether it be New, an Update, or a Resubmission.I think it would be a lot more satisfying to see where you stand in the queue, based on a number, than a “pending” status.
The current version (the “progress bar”) functions pretty much like that. However, we have improved the functionality of the review queues to be more dynamic in considering various information about an item or author. This improves how efficiently we’re working through the queues but makes it much more difficult to indicate exactly when an item will be reviewed.
I personally don’t see how this is an improvement, but let’s see where this goes.
It’s certainly not ideal vs indicating approximately when an item will be reviewed, so in that sense I would agree that it’s not an improvement. However, the current implementation of indicating when an item will be reviewed is not accurate and gives authors an expectation that will not be met due to the way the system functions. We would rather provide a solution that is accurate until we are able to implement something more ideal. We have a list of ideas I hope to explore further soon.
I also like to see how long has it actually been since I uploaded.
Don’t worry, you’ll still see the elapsed time since the item was uploaded.
Some time ago a few changes were implemented in review queue functionality that increased their complexity in favor of more efficient queue management. Unfortunately this affected the item review “progress bar” (displayed on the Author Dashboard sidebar) and gave an inaccurate and misleading indication of when submitted items might be reviewed.
As the complexity of the review queue functionality is expected to increase, it becomes significantly more difficult to indicate when submitted items will be reviewed. So we’ve decided that until we’re able to provide a more ideal solution, we would change the information provided to be more relevant and accurate.
What are we changing?
- The “progress bar” shown when an item moves through the review queues will be removed.
- In place of the “progress bar” we will show the state of the submitted item and the state of that item in the review queues.
We will also be publishing what these states are and what they mean in the Knowledgebase once the change is about to be deployed. I don’t yet have an exact ETA for deployment of the change but once I do, I will post an update in this thread.A few examples of how this new information might read is:
- Example Item Title – New, currently Pending
- Example Item Title – Update, currently Pending
- Example Item Title – Resubmission, currently Held
- Example Item Title – New, currently in Standby