Name: Technical-Tool-Request
Description: Requests for technical tools to accomplish a specific thing related to wiki. Such tools might already exist, in which case people will be pointed at them, or might need to be created.
Type: Tag
Reason: I was helping conduct a technical training workshop with @Ijon for the tamil wiki community, and a central place for such requests / discussion was the most requested thing related to phabricator.
Quoting @Qgil:
Any idea how this would play together with Community-Tech and Possible-Tech-Projects?
There seem to be two aspects mixed: Discovery of existing projects and "requesting" (from who?) new projects or proposing new project ideas. I honestly don't know if both should be the same place.
Some examples might [usually do!] help. What specific requests are expected, or already received?
IIUC, this request has a partial overlap with, or some similarity to:
and these are the types of pages that might be consulted, to find out if the tools already exist:
and it would attempt to improve upon the historical/closed/inactive locations, such as:
See also:
[1] re: [[m:Tech]]... One main benefit of doing it onwiki, is that other random onlookers (page-watchers or by-passers) are more likely to learn and thereby benefit, from the responses. That is less likely to happen with a phabricator tag (currently? perhaps not in the future?).
I'm not against a phab tag for this if we think that we can find people willing/capable of patrolling it.
There is overlap with both groups in terms of subject matter (problems that on-wiki communities are looking to solve). In terms of patrolling audience however I think there is divergence. Community-Tech is a WMF staffed team focused on working an existing backlog of requests that were voted on by Wikimedians on meta. Possible-Tech-Projects is aimed mostly at candidates for GSoC, Outreachy and other potential internship programs. When I read "requests for technical tools" I think of the developers who are existing Toolforge users who are comfortable working with the Action API and database replicas and mashing them up with external resources and on-wiki processes. Depending on the problem that needs a solution it might be a potential fit for work by all three developer audiences.
I totally agree with @Quiddity that something where the discussions start onwiki would be better for including most Wikimedians. In my magical unicorns and rainbows perfect future® I would really like to see an on-wiki technical support board at wikitech that is something like mw:Project:Support_desk or en:Wikipedia:Village_pump_(technical) which could be a location for both community communication with tools developers and a location for the developers to communicate with each other. I even have cute names dreamed up for this: "Backsmith's shop" for the Wikimedia community to connect with tool developers and the things they have made and "The Forge" for the developer to developer technical support. I generally think that having Flow (T127792) and making wikitech a SUL wiki (no ticket yet but described on meta) are blockers to major work in this direction at least on wikitech.
Doing something like this on meta today would probably be possible, but for me personally the choice of the meta community to exclude Flow makes having useful discussions difficult. Flow has some issues for sure, but I find it much easier to create and follow discussions with it than plain talk pages.
What about renaming MediaWiki-extension-requests? Those requests aim to solve technical needs. Whether the need must be solved with an extension or something else, that is an implementation detail (that should not be decided beforehand).
MediaWiki-extension-requests has only one member and one watcher, which means that we'd better focus our attention in a single place.
With this in mind, I started this (unrelated) feature idea, T135321: Vocabulary assistant for Simple Wikipedia, based on Upgoer Text Editors. Just for the record. :)
Renamed and updated description: https://phabricator.wikimedia.org/tag/technical-tool-request/
Nobody had suggested renaming this established project, as far as I can see. It would be useful to know what's the expected benefit, compared to e.g. leaving the correct name while adding a hashtag for people who are unsure an extension is what they need.
To be fair, it's not true - T134103#2259389
It would be useful to know what's the expected benefit, compared to e.g. leaving the correct name while adding a hashtag for people who are unsure an extension is what they need.
I agree.
I came too late to this task, otherwise I would be against renaming. The fact, that tag has a single watcher or subscriber does not automatically imply that nobody else is watching it. Ie. I was checking the board time to time.
Sure we could do columns on the workboard, one for extension requests, one for other tools (or maybe break it down yet further), but that's not as practical as having separate tags for that.
I encourage to switch back to original name and create this project aside of it.
How a certain new functionality is implemented feels like a detail to sort out while discussing the way forward for each task.
Could you elaborate which specific workflow requires you to differentiate between extensions, tools, etc via separate Phabricator projects, and how this is more relevant than fragmentation across various project tags? For example, would you be interested in following tasks only about developing technical tools if they get implemented as a MediaWiki extension but not if they get implemented as a tool on Tool Labs? If so, why?
I am re-opening this for further discussion. I believe that changing the meaning of the original project like this, while well intentioned, ends up being more confusing for both requestors and implementors. Mostly, I see it as the current setup assumes that the person who is making the request either does not know the difference between the different options, or that they don't care. I do not believe that is true, and reviewing this task, I don't see that anyone has surveyed existing tasks in the project. I will do that and post my results here.
Sure. And once that is decided, it should be marked in a specific way that indicates "the proper way to implement this is a MediaWiki extension." How can that be done in the new project?
Could you elaborate which specific workflow requires you to differentiate between extensions, tools, etc via separate Phabricator projects, and how this is more relevant than fragmentation across various project tags? For example, would you be interested in following tasks only about developing technical tools if they get implemented as a MediaWiki extension but not if they get implemented as a tool on Tool Labs? If so, why?
Yes, because my experience has shown me that developing tool labs tools are fundamentally unsustainable in the long term, and that MediaWiki extensions are currently the best way to do this, so I recommend and assist people who are willing to take on that challenge.
Survey of existing tasks in Technical-Tool-Request: I have opened https://phabricator.wikimedia.org/maniphest/query/vm2bx1NIAcvW/#R, and will go through every 5th task, and analyze them.
I'm getting bored now and I think I've made my point that there is a specific need to track MediaWiki extensions separately.
I propose that the current Technical-Tool-Request (formerly MediaWiki-extensions-requests) be restated to it's old name. And then create a *separate* Technical-Tool-Request project that handles tool labs / scripts, etc. When a user files a task in either project, and if we doubt it should be implemented the way they proposed (or they simply don't know), we should help them by commenting and triaging their request accordingly.
As the person who proposed the rename with the best of my intentions, :) I have no problem in reverting this decision as per @Legoktm .
I propose that the current Technical-Tool-Request (formerly MediaWiki-extensions-requests) be restated to it's old name. And then create a *separate*
+1. Given we have Tools, the new project could also be called #tool-labs-tools-requests but that's a nitpick, fixable later.
Closing as resolved because the original request has been implemented.
MediaWiki-extension-requests is back to where it was, and there is now a new Technical-Tool-Request.
There are probably some tasks in the MediaWiki extension requests project that should be moved to the new Technical Tool Request one, and I would appreciate assistance from others in doing so.