Wikimedia Cloud Services team/EnhancementProposals/Toolforge UI/Feedback

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]

I'm so glad to see you chime in, Lucas! Please allow me to focus on a couple of highlights from your message:

- Regarding 'Accessing a centralized logging dashboard': Rather than displaying logging data about Toolforge (the service), our plan would be to provide tool-specific logs (including information about system and component status and performance – more in line with T127367). I hope that still sounds useful!

- Making tool information available to others sounds very interesting, both as a means of learning from other tool maintainers' configurations and to streamline collaboration (e.g., by providing the ability to request becoming a co-maintainer). I think we should start exploring in which capacity could Toolforge UI integrate with a platform like Toolhub, or if instead a tool catalog should be available on the new platform itself 🤔

Thank you so much for answering the predefined questions and sharing such valuable feedback! 🙏🏻 SSanchez-WMF (talk) 14:23, 27 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]

Thank you so much for your feedback, @PPenloglou-WMF! It's really helpful to learn about your common tasks, and we took good note of your feature needs / requests. Thanks again! SSanchez-WMF (talk) 16:36, 5 February 2025 (UTC)[reply]