 Hey folks, my name is Brian Davis. I'm a software engineer at the Wikimedia Foundation working on the technical engagement team. My pronouns are he, him, and I'm here today to talk to you about the Tool Hub project that I've been working on along with Shreve Sethi for about the last five or six months now. And I hope you folks will leave the session today with a general understanding of what GAPS Tool Hub is hoping to fill for the movement, how to get information about your own tools into the catalog, and where to look for discussion of future features and how to get involved in our project. So there's a really rich ecosystem of tools built by volunteers and staff within the Wikimedia movement to help fill in workflow gaps on the Wikis. There are thousands of bots, user scripts, web services, gadgets, desktop apps, and phone apps out there. Maybe even one that does the exact thing that you're trying, makes the exact thing that you're trying to do easier or possible. But how do you find them? The Wikitech L discussion that I took the poll quote on the previous slide from inspired user Rekorty Samoa to create a fabricator task that collected links to existing parcel solutions. I discovered this task in early 2016 while I was researching ways to help volunteer developers working in what we now call Tool Forge. And I think this was and still is a brilliant idea and a thing that many, many people have asked for over the years. So it led to Tool Hub 1.0 goals. Our target minimum viable first launch project, product for Tool Hub is focused on this list of goals on the slide here. We're working towards a core product that makes collecting and reusing information about tools as open as we can. Rather than creating yet another one-time list of tools, we wanna make a platform that makes it possible to extend and remix the catalog. And I think really critical to this openness is our choice of what's called kind of an API first design. So a web API is just a fancy way of saying that the web application has features that can be used by other software rather than just humans. And in our case, we're hoping that Wikimedia volunteers will be able to build tools that interact with the data that's stored in Tool Hub in many ways. So in thinking through and designing this, we've come up with several personas and use cases that we're hoping to support. One of the first ones is on Wiki editors. We want them to be able to search for templates, modules, gadgets, other tools that help them make specific editing related tasks on Wiki easier. We want them to be able to make and view public lists of tools in a category to learn about things for those kinds of specific tasks. We want editors to be able to contribute information back about the tools that they use. And kind of one of the wishlisty features, we'd really like it to be possible to write Lua modules that query Tool Hub for certain types of tools and then use that information on the Wikis in an automated way. Another one of our personas is developers. Some of you all, maybe all of you all are developers. We want developers to be able to build subsets of the catalog using the API for their personal use or communities. So basically to build tools outside of Tool Hub that gather Tool Hub's data and show it in some different, better, unique way. We'd like developers to be able to develop a gadget or a user script that makes it easy to register a tool in Tool Hub. We'd like developers to learn about the tools that are available in different programming languages that they might be good at contributing to. And we want developers to be able to connect with their users, with each other and with other resources like documentation. A third persona that we have is researchers. And we want researchers to be able to use Tool Hub as an entry point to learn about specific tools like bots that are available in the Wikimedia ecosystem. Movement organizers are another persona that we're hoping to reach, especially to allow them to search for lists of tools that help with organizing programs and events, maybe lists that are created by other existing organized groups like Wiki Loves Monuments or Wiki Women in Red. And readers of the Wikis are a persona that we care about. We want readers to be able to find tools that recommend them new articles, give them new ways to experience Wikimedia content. How are we doing this all right now? Well, we've got a small team and a tech stack working. We're actually running some social and technical experiments in how we're doing this project. We formed what we're calling an advisory board to help get input from people in key roles throughout the movement during our development. Our advisors currently include foundation staff as well as community volunteers. These folks, they provide us with feedback on our design and implementation ideas, especially in areas where they're subject matter experts. And we use this feedback to help us iterate on collectively thinking about the project from a broader set of perspectives. So we don't end up just making the thing that Brian wants the most, but hopefully we make something that all of us can agree is pretty good. We're also trying to leave behind documentation about why certain decisions were made in a form that we call the decision record. I really want Tool Hub to have a life behind beyond the contributions of any single member of the team. And we hope that documenting why we've made some of our technical choices will help future maintainers when they need to make their own editorial decisions in the project. We're trying to keep the advisors and anyone else who's interested in following along up to date with what Shristi and I have been working on by producing progress reports each week that on meta, and also posting a summary of that to a project's development specific mailing list that we have set up. Then kind of on the more technical side, we're trying to keep the development environment or requirements simple to make it easier for people to contribute. And we're using some newer technologies that are being adopted in other areas of the Wikimedia movement like Vue.js and container-based deployment tools. A little bit about the dev environment specifically. It uses Docker Compose to run a set of containers for the Django backend, the Vue front end, a MariaDB database, an Elasticsearch full-text search engine. And this is set up building on top of the blubber and pipeline lib configuration tools that are used in CI and will eventually be used for our production deployment as well. Then we've tried to set this up so that we've encapsulated as much as possible within the Docker container layer. So on your local machine, you should really only need Docker, Git, and GNU make. And everything else that's needed should be included in the Docker containers with make file targets that automate things like running your tasks and regenerating the localization files. All the coding standards that we're using are being enforced with winters that can be run locally and are also voting when things pass through Jenkins in the CI environment. And this is a cool thing because it means Trusty and I don't need to quibble with each other during code review over little things like formatting. If the liners have passed, then it must be okay. Or we need to go open a bug about adding a new linter because we don't like what's happening. So let's talk a little bit about the various features. Oh, and my screenshot isn't showing up on the screen. Interesting. So various features of the project. The start is a home page, a landing page that's got a search box on it, a paginated display of the cards showing small summaries of the tools that the system knows about now. I think today on the demo server that I'll give a link to in a little bit, there are about 762 tools, not about, there are 762 tools currently indexed. And this is in large part, thanks to our compatibility with Hayes Directory and its tool info JSON standard that we'll talk about in a little bit. Now I got one same slide with the screenshot, cool. Okay, next feature is tool info cards. So these are the little summaries about each tool. They have some information there, image, title, description, author, keywords, things like that. The next feature is a detail of a tool info. So from the tool info card, there's a button that you can click for more information, takes you to a full page display about the tool where you get a lot more information, potentially depending on how the tool info record has been created. And one of the things you can see maybe here in the screenshot is in the upper right corner when you're in a right to left, left to right view is a view history button, which is another feature. So we have edit history, right? People are used to working in MediaWiki. This should look kind of familiar. Get a detail page about the edits that have been made. And here you can do things if you have the proper rights, like revert and undo and get diffs. Faceted search is a huge and exciting feature for me in Tool Hub. So users can search through the tools using free form text search terms and then refine those searches by selecting common values from the matched documents. Those common values are things called facets. There's sort of search navigation that you've probably seen on e-commerce sites where there's like maybe a list of departments or sizes or colors shown along with your search results and you can click on them to refine your search and include only things with that particular attribute value. And another feature that we have is tool registration. We need to get data into this system. So there's interactive edit forms that allow you to create a new tool document initially and then go on and edit it to get that sort of edit history that we've seen in the previous feature. You can also get your tool info data into Tool Hub using externally hosted tool info JSON files. And so then in our user interface and user interface screenshot here is shown in Hebrew to show you that we have some right to left support working in the system. So if you host on Tool Forge or in your Git repository or wherever your external tool is hosted if you host a JSON data file conforming to a particular format you can then come to Tool Hub, tell us where that URL is and the system will go out and call your URL and bring that data in. That tool info JSON standard is something that was started by Hay or Husky depending on whether you know him from content wikis or the development side of the world with his tools directory project. But Hay's directory was an awesome innovation for the tools community that came out of discussions with Wikimania in 2014. And when James Hatter and I were working on the initial documentation design for Tool Hub we made a very deliberate decision to start from Hay's standard and build on it in a backwards compatible way. This helps Tool Hub by providing useful data even before we've launched the product for public use and we think this helps the community by showing that we can build on and extend the things that each of us make. More features that are in the UI, there's some status pages to show you what's going on with the web crawler and detail screens of those particular crawls so that you can see which URLs were crawled and whether they ended up in a completely good green state or some sort of intermediate failure state and you can, when you're looking at this view you can drill down into the what happened with a particular URL, especially if it's airing out so that you can see what the system saw if the file was a 404 or if it was badly formatted or something else happened. And we have an audit log stream similar kind of to special logs and special recent changes in the MediaWiki software kind of combined into one list of actions taken and we're working on adding more features to this that will eventually allow you to filter these logs by date range, by the user that took the action by the kinds of actions that were taken. 10 minutes left. Thank you, Prarita. I will move a little faster. So API documentation. I said API first design. The front end is built with JavaScript that talks to the back end APIs and built into the front end. We have a documentation browser where you can see what the APIs look like, what parameters they expect on the input, what they give on output and you can even use this little console to do live testing of how you might use the API. Related to that, there's developer settings that allow you to create OAuth consumers that will then work with ToolHub. That really kind of wraps up our features and then active work. We're working on content moderation support things. We're working on, and then we will move on to working on curated lists of tools and finally we hope to add community added information for tools in the form of a thing that we're calling annotations. So the core tool info records will be owned by whoever initially creates them, but then there's other information that we should allow everyone to contribute to. If you wanna help us make this all awesome, there's a demo server at toolhub-demo.wmcloud.org that you can check out. Our translations are done at translatewiki.net. You can go over there and help provide translations that are missing. There's a ToolHub tag in fabricator that you can see our existing backlog and you can add new bugs and ideas. And there's pages on Meta under ToolHub that you can see to follow our progress reports and other things. And there we go. We got to my credit slide, which means we are now ready to take questions. Avritha, do we have any questions from the community? Oh, that was a great talk. And I did have one question which was how they can call you when I think about it in the end. I want to talk more about it. We can't answer it. And I urge folks to start with our questions on that. Your audio broke up a little bit for me, Avritha, when you were saying what question there was to answer. Someone asked if I was interviewing and how we can have a better view of it towards the end. If you wanna talk more, we can. Yeah. Contributing the projects in Garrett, the bugs are tracked in Fabricator. There's a read me that maybe helps you get set up, but I'm BD808 on IRC. Come find me on IRC. Let's talk, let's chat, let's see how we can get you involved. I'm definitely interested in getting some community members excited about this project and helping contribute patches and make things better. So I don't think we have any more films, but I love your color. Someone who's a very cool member. And they love your results. Awesome, awesome. Well, thanks for having me talk today, folks. And I will see you around at the rest of the hackathon.