@bd808 Thought a little about curated / favorite tools for display on the home page.

Some ideas for additional data points that can be associated with each tool:

• Views - tracked programmatically
• Likes / Loves - anyone can like/ love a tool
• Favorites - anyone can favorite a tool. There is a thin difference between likes/loves and favorites. The tools most favorited by users in a month can become featured tools for that month. This concept can be slightly improved.
• Coolest tool award winners - probably, for now, this change can be made by Toolhub administrators from the Django backend (as this will likely change once in a year).
• New tools - tools new on Toolhub, also to be tracked programmatically.
• Bookmarked - this is specific to a logged-in user. A user can see all their previously bookmarked tools from the user menu.

In addition to showing all this information on the tool card, tools could be made searchable based on these various criteria (see the top bar in the screenshot). We could also try to show tools in different categories on the home page. But, as we only show 12 or so tools per page, filtering makes the most sense to me.

Lots of cool ideas! I will add some notes and questions of my own to them. I think most of this is actually a separate idea from the idea of favorite/bookmarked toolinfo records, but they are good ideas that we should keep track of and work on refining so we can get them into future increments.

In T271490#7144476, @srishakatux wrote:

Some ideas for additional data points that can be associated with each tool:

• Views - tracked programmatically

Are you thinking about "views" of the toolinfo data in Toolhub or of actual usage of the tool (assuming it is a web thing of some sort)? The latter is one of the ideas that Birgit and I have discussed for the "quality signals" work that we are planning for FY21/22.

• Likes / Loves - anyone can like/ love a tool

I think collecting this data is one of the ideas on the wiki for T195681: Toolinfo annotations.

• Favorites - anyone can favorite a tool. There is a thin difference between likes/loves and favorites. The tools most favorited by users in a month can become featured tools for that month. This concept can be slightly improved.

I like the idea of some kind of "what's trending" signal.

• Coolest tool award winners - probably, for now, this change can be made by Toolhub administrators from the Django backend (as this will likely change once in a year).

Having curated lists of award winners is something I have certainly thought about. An annotation for coolest tool awards would be interesting too. The latter could probably support what you are thinking about here.

• New tools - tools new on Toolhub, also to be tracked programmatically.

This one is easy to do as an API filter (last modified >= some date), but a bit trickier to annotate on each and every toolinfo result. Maybe there is some neat hack we can come up with though to mix that data into result streams.

• Bookmarked - this is specific to a logged-in user. A user can see all their previously bookmarked tools from the user menu.

I think bookmark == favorite? I'm having a hard time thinking of a strong reason to have 3 different "I like this" signals.

In addition to showing all this information on the tool card, tools could be made searchable based on these various criteria (see the top bar in the screenshot). We could also try to show tools in different categories on the home page. But, as we only show 12 or so tools per page, filtering makes the most sense to me.

I sort of think that showing curated lists on landing page will be the best use of space eventually, but until we get some built there is a chicken and egg problem. :)

In T271490#7146143, @bd808 wrote:

Are you thinking about "views" of the toolinfo data in Toolhub or of actual usage of the tool (assuming it is a web thing of some sort)? The latter is one of the ideas that Birgit and I have discussed for the "quality signals" work that we are planning for FY21/22.

I was thinking about page visits for a tool info page to show on the tool card. Actual usage of the tool could be an interesting data to show as well.

I think bookmark == favorite? I'm having a hard time thinking of a strong reason to have 3 different "I like this" signals.

Agree! There can then be one that we pick - favorite. A user can see all their previously favorited tools from the user menu.

In addition to popular, featured / what's trending, views, winners, new tools, there can be another category for tools that meet all the quality signals in the distant future :)

Change 724583 had a related patch set uploaded (by Srishakatux; author: srishakatux):

[wikimedia/toolhub@main] UI for favorite tools

https://gerrit.wikimedia.org/r/724583

Change 724583 merged by jenkins-bot:

[wikimedia/toolhub@main] ui: Add favorite tools support

https://gerrit.wikimedia.org/r/724583

@sdkim This is ready for acceptance testing at https://toolhub-demo.wmcloud.org/

@bd808 Are we allowing the ability to share your favorites like we are with lists?

In T271490#7524101, @sdkim wrote:

@bd808 Are we allowing the ability to share your favorites like we are with lists?

Not currently, no. Favorites are currently implemented in the storage layer as a distinct subtype of list which is excluded from the API endpoints which can be used to edit the list "normally" including the ability to toggle the list's public flag.

Looks great @srishakatux @bd808

Does this feature now get deployed to the prod server? Should I go ahead and resolve it?

In T271490#7524424, @sdkim wrote:

Looks great @srishakatux @bd808

Does this feature now get deployed to the prod server?

It could go to the production server at any time, yes. We have done a few early bug fix releases, but we have not done any significant new feature releases yet. This is actually something I would like to discuss to decide if we want to do ad hoc deployments as things are "done" or batch things based on time (something like the MediaWiki weekly "train") or roadmaps (something like the 1.0 release that had a list of must have functionality for the increment). Any or a mix of all of these could work, but I would like us to try and be intentional in which model we are using. It would also be nice to decide on how we notify others of the changes we are deploying in any given increment.

Should I go ahead and resolve it?

Yes, if you are accepting this increment then I would say this task can be resolved. That to me is independent of the question of when we next push to the production servers.

Change 749220 had a related patch set uploaded (by BryanDavis; author: Bryan Davis):

[operations/deployment-charts@master] toolhub: Bump container version to 2021-12-20-122341-production

https://gerrit.wikimedia.org/r/749220

Change 749220 merged by jenkins-bot:

[operations/deployment-charts@master] toolhub: Bump container version to 2021-12-23-121200-production

https://gerrit.wikimedia.org/r/749220