Wikimedia Cloud Services team/EnhancementProposals/Toolforge UI

Help us shape Toolforge UI!

The Cloud Services team is looking to improve the experience of Toolforge users by providing a web platform that complements existing command-line tools. The initiative is motivated by community feedback pointing out the complexity of current Toolforge’s deployment workflows, and it also seeks to update our hosting service to meet industry standards.

Our hope is that providing users with a UI platform that centralizes tool creation and management will streamline our community’s day-to-day tasks and interaction with Toolforge. We’d like to understand your expectations and requirements for such a solution, so we can tailor it to your needs.

Background

For the past few months, our team has been focusing on exploring the challenges faced by different user groups during the setup and maintenance of their tools in order to identify opportunities. Internal exchanges and existing user feedback helped us define two main hypotheses:

Providing a web-based platform will streamline tool deployment and management tasks for current Toolforge users, helping them optimize day-to-day maintenance.
A more guided, UI-based workflow will simplify the setup and deployment processes, lowering the barrier of entry for new users.

We are currently planning and conducting feedback collection activities (such as this announcement) to gather relevant insights from Toolforge maintainers that can help us inform both hypotheses and validate the opportunities we detected.

Design requirements

Our team is in the process of defining the scope of a pilot version of the solution, and designing low-fidelity mockups to reflect its fundamental user flows and features. We expect that the initial proof of concept of Toolforge UI would allow users to:

Sign in and manage their account details (Initially for registered users only)
Create and register tools using a simple form
Access an overview of all user-managed tools
Create and configure tool components (web services, background services, jobs)
Connect to their GitLab account and link repositories
Easily deploy changes (for build service components only)
View deployment logs
Define environment variables

Features to be included in follow-up iterations:

Sign up of new users (No Toolforge membership request required)
Create GitLab repositories
Deploy individual components
Set up and manage add-ons, like databases or storage
Access a centralized logging dashboard
Search, filter and download logs
Access basic health monitoring (e.g., CPU load, Memory usage)
Set up health monitoring alerts
Managing contributors

User preferences and technical requirements will continue to influence the initial scope outlined above.

We need your feedback

We would like to understand your perspective, and discover the potential opportunities that you recognize in this solution in order to cater to your expectations and needs.

To help us prioritize features that matter most to you, please share your thoughts on:

How do you think a graphic interface could improve your experience with Toolforge? What tasks in your current workflow would be the most streamlined if performed in a centralized UI?
Of the features mentioned (e.g., tool management, simplified deployment, observability), which are most critical to your workflow?
Are there additional features not listed that you believe would significantly enhance the usefulness of Toolforge's web platform?

Share your feedback

(Please note that your email address needs to be validated in Wikitech before you can share your message.)

Your observations will be instrumental in shaping a solution that best serves both new and experienced Toolforge users. Thank you for your contributions and support!

Novem Linguae

This is a great idea. A good UI would be more user friendly than the command line, making it easy to find things that need to be commonly done, and making it easy to click a couple buttons to do them. You can focus less on being a sysadmin and more on coding. You can read less docs, lowering the barrier to entry.

Things to put in the panel...

Cron jobs / jobs framework
Turn webservice on/off
Pick a programming language (PHP, Python, etc.) and click to spin it up
Pick a framework (Pywikibot, etc.) and click to install that
Set your web entry point. For example, if you want your /foo/bar/public_html folder to be what gets loaded when you visit novem.toolforge.org
phpmyadmin or similar to log into, browse, edit, and query your Toolforge user databases
Toolforge user database administration tools, such as creating/editing/deleting a user database, creating/editing/deleting a user, and assigning that user access to your user database

Consider if this can be built in the Toolsadmin system, which is kind of a similar idea to this, but with way less features.

Consider logging into software such as cPanel and poking around there for ideas of things to add.

Consider looking for and using an existing open source server control panel, so that the wheel doesn't need to be reinvented. There's probably months or years of work here if it were to be developed from scratch, and there are probably many web hosting companies that have blazed the trail already.

P.S. I found this quiet page via mw:Technical_Community_Newsletter/2025/January, so thanks for posting it there. Novem Linguae (talk) 01:07, 14 January 2025 (UTC)[reply]

Apologies for the late reply, and big thanks for the valuable feedback and great ideas shared, @Novem Linguae! 🙏🏻 Some of the features mentioned (e.g., Jobs, turning webservice on/off, managing databases) are under our team's radar, so it's great to find them listed in your message. We're planning to create a more detailed backlog and document our evaluation of the features requested during this feedback cycle. All relevant resources will be shared back on this page as soon as possible, to make our prioritization rationale more transparent and easier to follow.

The team is intending to investigate your point about extending Toolsadmin (see Toolforge UI: Investigate integration of Striker functionality). Regarding cPanel, we've been reviewing third party tools for inspiration and to identify good practices, but we had missed this one: thank you for the lead!

Reusing existing open source control panel software sounds like a great idea to reduce effort. I think we didn't prioritize this because we're operating under the assumption that any existing options might not be easy to tailor to Toolforge's new component paradigm (where individual components – webservice, job, background service – equal in practice to what other platforms treat as entire apps). But we might have been too quick to discard this option. Sounds worth looking into.

Thank you again! SSanchez-WMF (talk) 13:21, 20 January 2025 (UTC)[reply]

SD0001

Some features that could be added in the proposed UI that I haven't seen mentioned before:

A "Request to be co-maintainer" button – this creates a boilerplate email that you can customise to ask the tool maintainers to add you as a co-maintainer.
A "Invite co-maintainer" button – if you know someone who can be a good co-maintainer for your tool, there should be a way to send them a boilerplate email asking them to agree.

There's a "manual" equivalent for these – sending emails directly, but that generally requires more motivation. These ideas were inspired from a discussion we had in the Toolforge Standards Committee about shifting the culture away from the norm of single maintainership.

Apart from that, it would be great to:

Enable checking output and error logs from the UI. When you're at work or on mobile, it may not be feasible to SSH to the bastion to see what broke. Currently, I have a route in the webservice that shows me logs for cronjobs, eg. https://sdzerobot.toolforge.org/logs?type=out&log=job-mostimported. I still haven't figured out how to do it for the webservice where that's handled by k8s.
Enable webservice restarts from the UI. This apparently fixes various kinds of issues in legacy tools. (I haven't ever needed to do this though.)

SD0001 (talk) 18:07, 14 January 2025 (UTC)[reply]

+1 from me for the maintainership suggestions! Lucas Werkmeister (talk) 21:14, 17 January 2025 (UTC)[reply]

Thank you so much for the thoughtful feedback, @SD0001! We completely agree about the importance of adding features that promote a culture of co-maintenance. We've been evaluating similar functionality, which we had somewhat vaguely categorized under the broader requirement of "Managing contributors". We'll make sure to capture your detailed suggestions and incorporate them into the upcoming project's roadmap and backlog.

Regarding the ability to check output and error logs directly from the UI: Thank you for sharing your experience! Making logging information easily accessible has definitely been on our radar, and it’s incredibly helpful to have direct input like yours to reinforce this priority.

As for enabling webservice restarts from the UI: This has been discussed and even considered in our early design concept (which are still very much a work-in-progress and subject to change). Like logging, it’s uncertain whether this functionality will be included in the first releases of the new platform, but it’s something we’re keeping in view.

We truly appreciate your valuable input and your engagement in shaping this project 🙏🏻 SSanchez-WMF (talk) 15:21, 20 January 2025 (UTC)[reply]

Ahecht

I pretty much second everything that Novem Linguae said above. In addition, the following things would be helpful:

A file browser and text viewer. Read-only would be fine for 90% of the stuff I would need it for (checking various logs or looking at source/cfg files), but a file manager and text editor that would allow me to move/copy/upload/edit files without having to use SCP would be icing on the cake.
An online console similar to Terminal for cPanel, for cases where I'm logging in from a computer where I cannot use or install an SSH program.

Ahecht (talk) 20:21, 15 January 2025 (UTC)[reply]

Thank you so much for your feedback, @Ahecht! 🙌🏻 Apologies for the delayed response—we wanted to take the time to carefully review your suggestions.

Regarding file management and editing: In our current exploration of Toolforge UI, we'd like to streamline the use of Git (particularly GitLab) for managing files, as it better supports Toolforge’s principles like transparency and collaboration. GitLab also offers a robust way to move, copy, upload, and edit files while maintaining version history. That said, we also recognize that there are scenarios where uploading smaller files directly can be helpful. Supporting this as a "punctual" option is something we aim to keep in mind as we refine our prototype.

Regarding the browser terminal: This is a very practical idea that the team had considered exploring in the past! While we consider this outside the current scope of our UI-focused project, we’ll document the feature as a potential improvement for either a future phase of this project, or as a separate initiative to enhance accessibility for Toolforge users.

Once again, thank you for taking the time to share your feedback with us! Please don’t hesitate to share more thoughts or suggestions—they are invaluable to help us better understand the Toolforge community needs and prioritize future improvements 🙏🏻 SSanchez-WMF (talk) 12:45, 22 January 2025 (UTC)[reply]

Lucas Werkmeister

The upcoming thing I’m most looking forward to is push-to-deploy, so I’m mainly interested in the parts of Toolforge UI that will also help with that, to be honest ^^

1) How do you think a graphic interface could improve your experience with Toolforge? What tasks in your current workflow would be the most streamlined if performed in a centralized UI?

I think I’m one of the users who’s sufficiently comfortable with the command line that I wouldn’t use a graphic interface too much, but it would still be useful. Deploying with one click from the UI would probably be more convenient than deploying with two or three commands from the terminal.

2) Of the features mentioned (e.g., tool creation, deployment logs, health monitoring), which are most critical to your workflow?

Create and configure tool components sounds like a direct requirement for push-to-deploy (the system has to know that, to deploy a new version of QuickCategories, it has to restart both the webservice and the background runner), and a UI sounds like a nice way to configure this information. Easily deploy changes and View deployment logs also sound useful. I’ll also be very happy to see Access a centralized logging dashboard (T97861 has been open for a long time now).

3) Are there additional features not listed that you believe would significantly enhance the usefulness of Toolforge's web platform?

I think it could be useful to make some of the information about a tool also available to others (either logged-in Toolforge members who aren’t part of the tool, or even anyone at all) – e.g. which components the tool has, add-ons, environment variable names (without values). Not sure if this needs to be configurable per-tool (might be overkill). Lucas Werkmeister (talk) 21:13, 17 January 2025 (UTC)[reply]

PPenloglou-WMF

1) How do you think a graphic interface could improve your experience with Toolforge? What tasks in your current workflow would be the most streamlined if performed in a centralized UI?

Not that I mind handling operations via terminal but a web portal/UI would feel really nice to navigate in and perform common tasks. Some tasks I perform often are pulling changes from the tool repo I've pushed from local, building the webapp, starting/stopping the webservice.

2) Of the features mentioned (e.g., tool creation, deployment logs, health monitoring), which are most critical to your workflow?

Definitely reading webservice logs. Having logs be presentable on a UI will be a better reading experience than parsing it on a terminal for me.

Additionally (this may be out of scope), it'd be nice to be able to pick node versions higher than v18 before firing up a node app.

3) Are there additional features not listed that you believe would significantly enhance the usefulness of Toolforge's web platform?

Nothing comes to mind at the moment. Albeit I'm not the most sophisticated Toolforge user out there!

PPenloglou-WMF (talk) 13:02, 21 January 2025 (UTC)[reply]