Talk:Wikimedia Cloud Services team/EnhancementProposals/Toolforge UI
We need your feedback
We’d like to understand your perspective, and discover the potential benefits 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:
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?
2. Of the features mentioned (e.g., tool creation, deployment logs, health monitoring), which are most critical to your workflow?
3. Are there additional features not listed that you believe would significantly enhance the usefulness of Toolforge's web platform? SSanchez-WMF (talk) 08:29, 12 December 2024 (UTC)
Already existing features
Why does the "Features to be included in follow-up iterations" list include several Toolforge admin console features that already exist? Taavi (talk!) 14:47, 22 December 2024 (UTC)
- Hey @Taavi! Thanks for your question. With Toolforge UI, we're looking to centralize core Toolforge functionality in a single web platform. This means that, over time, the new portal will also integrate relevant features that are currently available in Toolsadmin (all in order to streamline the creation and management of tools from the same domain). The process will be, of course, gradual: our team has been pondering strategies to integrate both platforms during an initial phase (i.e., Toolforge UI will rely on Toolsadmin to function). SSanchez-WMF (talk) 18:38, 2 January 2025 (UTC)
- Does this mean that there's been a decision made behind closed doors that the new UI will replace Striker? Why? Back when I was at the Foundation and we were initially discussing this project, the idea at least in my head was precisely to extend Striker instead of duplicating it. Taavi (talk!) 19:00, 2 January 2025 (UTC)
- My apologies for not providing a more nuanced answer: The decision is still in progress at this very early stage of the initiative, and the options and their implications will be communicated accordingly. Extending Striker is indeed one of the approaches that will be evaluated. Nevertheless, in our early exchanges, team members tentatively agreed that working with the current implementation would present complications and require quite some re-architecting to enable us to achieve the project's goals. Alternative approaches to an extension could be integrating Striker as is with Toolforge UI, or define a Striker API to be consumed by the new system. A Phabricator task with further details is in the making and will be shared shortly. SSanchez-WMF (talk) 13:06, 3 January 2025 (UTC)
- @Taavi Clarifying a bit, there's two decisions to make (not taken):
- Where to deploy/host the UI:
- Have the UI (be that extended striker, rewritten from scratch, or anything else) hosted on k8s itself with the rest of toolforge, and have a thin API doing the parts that need LDAP/prod access, so that might be like having `striker-ui` running in tools k8s, and `striker-api` running in prod implementing the prod-related bits
- Have everything hosted in production (like right now)
- What to code it with:
- Reuse the current striker code (django, etc.)
- Use a different codebase
- Both decisions affect each other, for example, if we want to have everything hosted in prod, would make a lot of sense to reuse all the code that's there already.
- If we decide to split it, then there's the opportunity to start the UI side (`striker-ui`) on a fresh codebase, given that we would have to split striker in two, specially if the UI flows that come up from the design are significantly different than what striker currently implements. The `striker-api` would still be reusing the code we have there most probably (as there's not much stuff to add, but mostly remove, all that logic can be reused). DCaro (WMF) (talk) 17:53, 8 January 2025 (UTC)
- My apologies for not providing a more nuanced answer: The decision is still in progress at this very early stage of the initiative, and the options and their implications will be communicated accordingly. Extending Striker is indeed one of the approaches that will be evaluated. Nevertheless, in our early exchanges, team members tentatively agreed that working with the current implementation would present complications and require quite some re-architecting to enable us to achieve the project's goals. Alternative approaches to an extension could be integrating Striker as is with Toolforge UI, or define a Striker API to be consumed by the new system. A Phabricator task with further details is in the making and will be shared shortly. SSanchez-WMF (talk) 13:06, 3 January 2025 (UTC)
- Does this mean that there's been a decision made behind closed doors that the new UI will replace Striker? Why? Back when I was at the Foundation and we were initially discussing this project, the idea at least in my head was precisely to extend Striker instead of duplicating it. Taavi (talk!) 19:00, 2 January 2025 (UTC)
Novem's comments
I posted some comments to Wikimedia Cloud Services team/EnhancementProposals/Toolforge UI/Feedback#Novem Linguae. Cross-posting here in case few people have that watchlisted. Novem Linguae (talk) 01:16, 14 January 2025 (UTC)