This task serves as an example to develop a small proof of concept for an app to ease the prioritization of non-product tasks on phabricator.
Description
Description
Event Timeline
Comment Actions
Hi @Celenduin, could you elaborate a bit about the problem to solve, and what "app" means (mobile? Toolforge?) Thanks!
Comment Actions
Hi @Aklapper, problem to solve is that prioritizing non-product tasks (e.g. refactorings, cleanup tasks, writing docs, etc.) consistently and transparently can be non-trivial. One possible approach to this would be to score the task along some dimensions (e.g. developer impact, did it cause issues before, how many extensions would it affect) and rank task according to that score. This is inspired by a concept called user pain.
An early system of this could be implemented in a spreadsheet. As usual, spreadsheets are great for very quick prototyping, but usually, things become quickly unmaintainable, and large usability issues appear.
This task is about looking into whether it is feasible and viable to create a tiny static web app for this purpose that would interact with Phabricator via the conduit API. This task is also intended as a sandbox for that.
Comment Actions
But I guess this is quickly answered as apparently not feasable as the "public" phabricator conduit API is missing the Access-Control-Allow-Origin header and browsers care about such a thing nowadays. Also, this doesn't even seem to be a configuration issue on the wikimedia side of things, but adding that header is a WONTFIX in phabricator itself: https://secure.phabricator.com/T7304. *throws hands up in the air in resignation*
Ah well. Learned something.
Comment Actions
Please help me understand why that's relevant and why browsers are mentioned if you plan to have some code running somewhere to pull stuff via the API.
Comment Actions
I was thinking of a simple static app (aka jamstack), meaning pure static js/html that is delivered as-is, runs purely in the browser and does not involve a server/backend. This could have been hosted on, for example, GitHub pages. With a (user provided, local) phabricator api-token it (=js in the browser) could have requested the data of a task (title, description, status, etc.), then the user could have made their prioritization via the interface and the app (=js in the browser) could have written it back to the task in some both human- and machine-readable way. But it doesn't work as simple as that, because of the reasons mentioned.
It might be doable with a small app that involves a small backend and server-to-server communication, but that has other challenges and is beyond the scope of this idea.