WordPress.org

Making WordPress.org

Opened 8 months ago

Closed 8 months ago

#5369 closed enhancement (wontfix)

Have themes added to the latest page staggered more evenly by date/time

Reported by: wplevels Owned by:
Milestone: Priority: low
Component: Theme Directory Keywords: dev-feedback
Cc:

Description

New themes added to the latest page seem to come in chunks based on when someone has time to add them. Because of this, many themes can be added at once leaving some to be pushed down further and others to reap the benefits of being at the top for longer periods of time.

Have approved themes added to a queue that automatically stagger them more evenly so each theme gets to be listed at the top for a fair amount of time.

Change History (6)

#1 follow-up: @joyously
8 months ago

Why would we want to limit how many themes are shown, if they meet the requirements?
If the page causes problems for anyone, remove the page, but don't artificially limit which themes are shown.

#2 in reply to: ↑ 1 @wplevels
8 months ago

Replying to joyously:

Why would we want to limit how many themes are shown, if they meet the requirements?
If the page causes problems for anyone, remove the page, but don't artificially limit which themes are shown.

It was never implied to limit the amount of themes shown. It was to have all themes added under the latest tab to have equal amount of time at the top instead of being pushed down when someone adds 10 or however many at a time.

#3 @joyously
8 months ago

Yes, it is implying a limit because themes aren't "added to the page", they are set live once they pass review. If you are holding them somewhere to stagger them out, you are limiting them.

#4 @wplevels
8 months ago

A theme passes the review and then it is set live. Meaning, it is added to the "latest" page correct? Or am I not understanding the process correctly? Is there a language barrier here because these mean the exact same thing to me.

You first implied that I recommended limiting the amount of themes shown: "Why would we want to limit how many themes are shown"

That is not what I am presenting or what was brought up as the concern in the #themereview slack channel. 100% of the themes that pass review and that are "set live" would be shown, they would just be spread out slightly to display them in a fair amount of time for each one. Instead of all of them being added at once, so they each get a more fair proportion of exposure. Is there a process that I am too inexperienced with here that I am not understanding? If anything the way it currently is limits how many themes are shown because they get bumped right off the page or to the bottom.

#5 @joyously
8 months ago

Yes, you are misunderstanding, because yes "adding to the latest page" and "setting the theme live" are the same thing.
I am referring to limits because you suggested that they are in a queue, so setting them live would not necessarily add them to the page. To do that, you would have to decide how many and when, which is a limit. If the theme is determined to meet requirements, it should be set live, not wait in a queue.
There should not be artificial limitations on when it gets "added to the page". The users of the repository should see all the live themes, not just the ones that are timed to that day. It's pointless from a user perspective, and the user is the most important for this.

#6 @dd32
8 months ago

  • Resolution set to wontfix
  • Status changed from new to closed

Unfortunately I don't think this is something we can realistically do - drip-feeding the new releases would add significant complexity and little benefit when you consider the audience is world-wide.

Very few people would look at the new themes page often enough to know that only 1 is new in the last hour vs 15 new in the last hour.

If anything, I think the focus should be on improving the review tooling to improve the speed at which themes can be approved and ultimately show up.

I'm going to close this as wontfix with the proviso that it's hopefully a situation that will resolve itself in the future with alternative fixes, and that realistically, it's not technically feasible in a manner that would benefit the majority.

Note: See TracTickets for help on using tickets.