I volunteer to help with any kind of content needs for this project, whether it's creating descriptions, keywords, a taxonomy, etc.

I worked on this at my previous job, where we used .yml files for each repo to keep track of information:

https://github.com/openopps/openopps-platform/blob/dev/.about.yml - example
Example of tool directory: http://brigade.codeforamerica.org/brigade/projects
Example of tool directory: https://18f.gsa.gov/what-we-deliver/

Cool directories for external collections that @MelodyKramer showed me:

• https://dirtdirectory.org/
• http://library.pdx.edu/diy/

The interesting thing about both of these is that they appear to be curated in that there are use-case driven organization which is a bit different from the freeform tags of toolinfo.json.

In relation to T158149: Find an owner for top 10 Developer Wishlist 2017 proposals, I dare to ask: what is the current status? :)

I would be happy to assist in some attempt at this problem, but I do not have the free time to actually commit to doing anything close to the majority of the work.

This wish is still missing a reasonable description of what use cases need to be solved and in what order. As it stands now there is a very large problem space that has a few partial solutions, but no clear description of what would be better. That in my mind is the first part of the problem that needs to be tackled.

• Hay's Directory solves a problem: it allows the developer of a tool to maintain a standardized collection of metadata that can be aggregated by a central system and displayed to others.
• The toolinfo system in toolsadmin (Striker) solves a related problem: it allows the technical community to collaborate on adding tags and updating the description of a toolinfo.json record for a given tool hosted on Toolforge if the tool's maintainers have made an initial record.
• Magnus' hay directory user page solves a similar problem to the one solved by toolsadmin: it allows the technical community (users with accounts on Wikitech) to add and edit toolinfo.json metadata in a central wiki page. This allows collaborative editing, but with a user interface that is somewhat lacking.

• Neither toolsadmin nor Magnus' page help typical Wikimedia users who do not have a technical contributor account participate in creating or curating toolinfo records.
• None of these solutions enforce a common taxonomy for tools.
• None of these solutions are particularly good at answering human questions like "How can I do X?" or "What is the most powerful Y?"

Many good points have been made thus far about why a better system would be nice. There are also some well informed opinions here about how making Yet Another Thing to solve the problem is likely to fail without a larger social component. This does not seem to me like the kind of problem that can be solved purely with software. Its just as much a culture and time problem. Tool creators/maintainers need to want to advertise. Tool users need to want to find new/different solutions for their workflows. Everyone needs to want to keep the information up to date.

I recently listed and researched GLAM-, Commons- and Wikidata-oriented tools in the context of SDC General (see T180197: [Epic] Support needed changes to volunteer tools for Wikimedia Commons and Wikidata that will benefit from operating with structured data on Commons). FWIW, I also categorized these myself in order to be able to group them better by functionality and their place in general workflows on Commons and Wikidata. Categories I outlined are:

• get source media / metadata
• source data cleaning
• matching with Wikidata
• media upload
• data upload
• "enhance - categorization"
• admin / moderation
• curation / organization
• bulk / quick editing
• generate attribution
• statistics (Commons)
• statistics (Wikidata)
• reuse / visualization
• search

You can explore the entire tool spreadsheet here; might be helpful. https://docs.google.com/spreadsheets/d/1GVR0jghBWuAGqJaT7KVXigMYWWNzdnrnwI9nWqfJrCo/edit#gid=0

In T115650#3867015, @SandraF_WMF wrote:

You can explore the entire tool spreadsheet here; might be helpful. https://docs.google.com/spreadsheets/d/1GVR0jghBWuAGqJaT7KVXigMYWWNzdnrnwI9nWqfJrCo/edit#gid=0

@SandraF_WMF , the spreadsheet is not "shared". I'm assuming you meant to turn on public visibility for that spreadsheet.

In T115650#3867095, @freephile wrote:

In T115650#3867015, @SandraF_WMF wrote:

You can explore the entire tool spreadsheet here; might be helpful. https://docs.google.com/spreadsheets/d/1GVR0jghBWuAGqJaT7KVXigMYWWNzdnrnwI9nWqfJrCo/edit#gid=0

@SandraF_WMF , the spreadsheet is not "shared". I'm assuming you meant to turn on public visibility for that spreadsheet.

Thanks for the heads up! I have made the spreadsheet publicly accessible now.

Thanks for the heads up! I have made the spreadsheet publicly accessible now.

Really nice, thanks for sharing.

@Abit You may want to share the Sheet you created a few years back!

You may want to share the Sheet you created a few years back!

How have I not shared that here yet? This list is incomplete and mostly out of date, but I was interested in tools that program organizers used to manage, track, and measure their programs. It is here: https://docs.google.com/spreadsheets/d/1iUvZZStf8k6RYdJYl2DLIxRdtCgWSYzEay5cCQg8MyE/edit?usp=sharing

Ha, came here to add James :)

How the heck did cloud service remove itself by me trying to improve on the text in the task? :(. Adding it back.

Hmmm... This is weired, now the "Tools" project tag has been removed :(, why is this happening? Is it that "Tools" tag and "Cloud-Services" tag can't be on the same ticket? I didn't deliberately remove these tags, I just tried editing the task to improve on it then they get removed on their own? :(

<threadjack>

In T115650#3909826, @D3r1ck01 wrote:

How the heck did cloud service remove itself by me trying to improve on the text in the task? :(. Adding it back.

This is a Phabricator "feature" that is not obvious at all, but makes some sense once it is explained. The Cloud-Services project is an umbrella project with things like Toolforge, Cloud-VPS, and Tools as sub projects. This nesting can go down multiple additional levels (e.g. Cloud-VPS (Quota-requests) is a child of the Cloud-VPS project). When a child project is on a task it shows up in the search results (and workboards if the child project is also a milestone project) for all of the parent and grandparent projects as well. Phabricator only shows the most deeply nested child project on the task itself.
</threadjack>

Sort of related to T116598: Document support levels for Cloud Services products.

Hey everyone, there's a page on Meta about Toolhub, https://meta.wikimedia.org/wiki/Toolhub

Of note, we have published a data model here: https://meta.wikimedia.org/wiki/Toolhub/Data_model. The data model is the list of different ways to describe each tool. Can you think of more ways tools can be described? What pieces of information help let you know that you've found the tool you're looking for?

In T115650#4216180, @Harej wrote:

Hey everyone, there's a page on Meta about Toolhub, https://meta.wikimedia.org/wiki/Toolhub

Of note, we have published a data model here: https://meta.wikimedia.org/wiki/Toolhub/Data_model. The data model is the list of different ways to describe each tool. Can you think of more ways tools can be described? What pieces of information help let you know that you've found the tool you're looking for?

Do you have a "Collect feedback around the data model page" kind of task? That'd be easier to point to people, add to Tech News, etc. Thanks.

T186382 I think would be the most relevant task.

What's up? (@Harej)

In T115650#5049541, @Dvorapa wrote:

What's up? (@Harej)

This project stalled out due to lack of software engineers to work on implementation. The Cloud Services team asked for Software Engineers in both the fiscal year 2017-2018 and 2018-2019 Wikimedia Foundation annual planning cycles, but did not win the "requisition number lottery" either time. I will be asking again in the 2019-2020 annual planning process for new staff to help build projects like this one and to take care of existing Cloud Services software projects that also have no assigned staff like Quarry and PAWS. Maybe the 3rd time I will find a way to be more persuasive. :)

I see, I wish you luck then :)

I am (slowly) getting work restarted on this project. Building a "minimum viable product" version of the Toolhub catalog is a fiscal year 2020-2021 goal for the Wikimedia Foundation's Technical Engagement team. I will be acting as the project lead with help from @srishakatux and others. I plan on posting periodic project updates at https://meta.wikimedia.org/wiki/Toolhub as work progresses.

It has been nearly a year since I last gave a project status update here. A lot of work has happened!

• A live demo of the Toolhub application is operational at https://toolhub-demo.wmcloud.org/.
• A recorded talk and slides with speaker notes describing the application as of May 2021 are available on commons.
• Numerous status reports are published at https://meta.wikimedia.org/wiki/Toolhub/Progress_reports.
• Production deployment of the "1.0" version of the application is tentatively planned for August 2021. This is pending things like security review and final coordination with Foundation teams on external dependencies of the application (database storage, elasticsearch storage, traffic routing, etc).

Look for additional announcements about how you can get involved in using and improving Toolhub in the coming weeks on the wikitech-l mailing list. We have plans for additional functionality beyond the 1.0 version of the application, and we will be trying to connect with many different groups of editors and technical contributors as we move from high level planning to actionable feature requirements.

Adding my own list of my tools, matched to the toolhub name where I could. Note that some of these are deactivated/broken (see notes), some are JavaScript on-wiki so not sure if that counts. The "open/closed' tickets are biased towards "open" while I go through them over time, but could become a quality score indicator down the line.

https://magnustools.toolforge.org/buggregator/api.php?action=get_tools

This API and tool list are actively maintained for my own bug aggregator ("Buggregator") here:
https://magnustools.toolforge.org/buggregator/

In T115650#7216272, @bd808 wrote:

• Production deployment of the "1.0" version of the application is tentatively planned for August 2021. This is pending things like security review and final coordination with Foundation teams on external dependencies of the application (database storage, elasticsearch storage, traffic routing, etc).

I was hoping that today would be the deployment day, but we are not quite ready. Progress will be stalled by Wikimania 2021, but things are expected to start moving again to finalize the few remaining issues soon after.

I would like to invite all interested parties to join one of the Toolhub unconference sessions during Wikimania to learn more about the features that Toolhub 1.0 has and how we hope it will be used. We are also holding two information gathering unconference sessions led by @sdkim and @srishakatux to ask questions about what makes a tool "good" that will be used, along with other feedback, to help define features for the next major release of Toolhub.