Hi, I am not a big fan of such tags. Could you please elaborate on specific use cases and who will actively set and use these project tags for what exactly? Thanks.

As an administrator of two Wikibooks, I'm unable to tell you now how many tickets about Wikibooks have been opened, if there are some doubles, or if some of them need a community input to be treated (like https://phabricator.wikimedia.org/T280019).

So the main purpose of a new project would be to visualize and prioritize them clearly, as we do in software engineering with Kanban like https://phabricator.wikimedia.org/project/view/1115/.

And not searching 1h for one of them like today.

In a second time it would be able to provide more volunteers from the community participate to a roadmap. And it would be easier to sync with https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2023

Finally, a reporting could use this data to compare the benefits of the Wikibooks project regarding to its investments.

tickets about Wikibooks

Could you clarify please? Specifically only appearing on Wikibooks but not on other wiki families? I've seen folks adding such project tags to their tickets just because they experienced the issue on such a site, while the issue is not specific at all to that site. Which drastically decreases the usefulness of having such tags (and increases triage workload). :-/ For more background, see tasks such as T306969, T154549#5174170, T227158, T254555#6195459.

And not searching 1h for one of them like today.

To state the obvious, that's only going to improve if someone is long-term willing to constantly triage new incoming tickets and add (or remove!) that proposed project tag... is that the case? :)

The typical use case would be a ticket created by the Wikibooks community, only about Wikibooks (not other families), and tagged by it.

To avoid the use of this tag in more general tickets than Wikibooks, I can write a Phabricator task creation process in the English and French Wikibooks. And try to keep it clean after thanks to the Kanban.

Could you clarify who else (apart from you) across Wikibooks communities plans to actively use (and maintain) this project tag? I'm still torn on this, obviously...

Hello, actually I had posted this idea on:

• https://en.wikibooks.org/wiki/Wikibooks:Reading_room/Proposals#Relation_with_Phabricator
• https://fr.wikibooks.org/wiki/Wikilivres:Le_Bistro/2023#Comment_se_situer_par_rapport_aux_liens_%C2%AB_version_imprimable_%C2%BB

But only Lionel Scheepmans seemed interested for now.

Anyway, generally the whole community is involved to vote before creating a feature ticket. So at least one of us would have the process in mind.

Hello, I am not informed about the habits of computer scientists and I trust JackPotte on this point. My interest, as a new administrator of fr.wikibook is to help the community find the best compromise to improve the printable versions of their works.
I've started thinking about the long-standing abandonment of the pdf creator and open document .odt files. You know, some people prefer to read text on paper and the social sciences still live in the paper age. Also, I still believe that 100% digital is not viable for people living in precarious conditions.
So, if you can guide me through the phabricator to meet people interested in helping with this task of finding the best way to print the Wikimedia Project pages, I would be very grateful.
For instance, I would like to know where I can nitifie than the PDF generator of Chrome and edge are very much slower than with firefox.

It sounds like the topic of printable versions is a small subset of any kinds of technical issues on all and every Wikibooks (which this tag would be about)

Dans T330600#8718395, @Aklapper a écrit :

It sounds like the topic of printable versions is a small subset of any kinds of technical issues on all and every Wikibooks (which this tag would be about)

Exact @Aklapper . And not only Wikibooks, but also Wikiversity, Wikivoyage and other projects that produce contain that could be useful to export or print for an offline use. That could be also the case for certain Wikipedia's articles that could be print in a scholar context in the global south, for instance. But few people seem to care about that.

@JackPotte: I remain reluctant to create a project tag that sounds like only a single person would actively triage / use / maintain. :-/

@Aklapper given there are already #wikisource All-and-every-Wikisource and #wiktionary All-and-every-Wiktionary, I am guessing it makes sense to create one for Wikibooks as well? There seems to be at least two person interested and that might make their life easier? I imagine a good case is processing the Wikibooks specific tasks from Wikimedia-Site-requests which often requires community input, track tickets in LUA modules, gadgets or MediaWiki extensions specific to the family.

Dans T330600#8744854, @Aklapper a écrit :

@JackPotte: I remain reluctant to create a project tag that sounds like only a single person would actively triage / use / maintain. :-/

If it's the only problem, we can ask to other admins and users to notice their undorsment. But how works the making decision on phabricator ? Are we trying to found consensus as in pedagogical project? Or maybe it exist here a certain hierarchy or an other kind of principe that lead to the decision?

@hashar: No, I'd personally prefer not to repeat mistakes only based on the argumentation that they were made before. :)
I just cleaned up the All-and-every-Wiktionary workboard a bit, e.g. moving tasks out of "Up next" which were open in there since 2015.
Again, I believe such tags need a number of people who have plans how to use a project tag / workboard, and plans how to avoid creating yet another additional place where some community work may be planned and discussed in parallel to already existing community places (discussion fragmentation, acceptance).

@Aklapper , thanks for this information that contribute to this debat. I understand very well the idea of not creating many discussion, information and decision making place. Also, if it's create a aditionnal work of maintenance to phabricator to be finally not used, that's not the purpuse of course. Do you have an idea, if is not on phabricator, where the Wiktionnary's admins can gathering and discuss all servor side problems concerning their projets ?

An other question, if you want. Can you tell more, about how decisions are usually taked on phabricator ? Is there a certain hierarchy here ? Or the consensus is always the target of discussion as on many Wikimedia Projets ? Or maybe there is no rules and no habit ?

@Lionel_Scheepmans Hi, please bring up general Phabricator questions unrelated to this task on https://www.mediawiki.org/wiki/Talk:Phabricator/Help - thanks!

Do you have an idea, if is not on phabricator, where the Wiktionnary's admins can gathering and discuss all servor side problems concerning their projets ?

Phabricator is for bug reports, feature requests, planning actionable work items together. For general cross-wiki discussion I'd expect metawiki to be a venue. If Wiktionary admins want to use Phabricator for planning work that is definitely welcome! However I have not seen a number of Wiktionary admins expressing that...

Dans T330600#8750007, @Aklapper a écrit :

@Lionel_Scheepmans Hi, please bring up general Phabricator questions unrelated to this task on https://www.mediawiki.org/wiki/Talk:Phabricator/Help - thanks!

Do you have an idea, if is not on phabricator, where the Wiktionnary's admins can gathering and discuss all servor side problems concerning their projets ?

Phabricator is for bug reports, feature requests, planning actionable work items together. For general cross-wiki discussion I'd expect metawiki to be a venue. If Wiktionary admins want to use Phabricator for planning work that is definitely welcome! However I have not seen a number of Wiktionary admins expressing that...

We are almost two admins from fr.wikibooks to be interested by it. But, as I've sayed before, we can check if other admins are interested. I've alway post a message on fr.wikibook village pump about this. Do you thnik that there is a sens to create that list only for fr.wikibooks and not for all wikibooks ? Or maybe it worst for you ?

To clarify this, as discussion was about all-and-every-*: I am fine creating a #Wikibooks-fr group, similar to Wiktionary-fr, if that's wanted.

Do you thnik that there is a sens to create that list only for fr.wikibooks and not for all wikibooks ?

@Lionel_Scheepmans Again: Are several Wikibooks folks from different Wikibooks interested in having a shared Phabricator project, and how do they plan to use it in the long-run, and how will they avoid having n+1 places where things get planned instead of the current n places (fragmentation of discussions)?

@Aklapper , I totally understand your arguments and the common sense behind them. I wonder if it would not be more relevant and even more efficient in this case to create a page within the editorial projects that includes all the phabricator tasks that concern them. A way perhaps to unburden phabricator and to bring the technical information closer to the concerned editors. The problem is that creating this page by hand is time consuming and requires regular updates. Whereas a tag makes things much easier. Besides, it is also possible to make queries with keywords that allow to target a project. This is also functional it seems to me. This is my conclusion about this topic. Have a nice day !

I want to avoid projects that soon nobody will use anymore, and I want to avoid creating n+1 places where things get planned instead of n places to have even more fragmentation of discussions than already.

In T330600#8753586, @Lionel_Scheepmans wrote:

in this case to create a page within the editorial projects that includes all the phabricator tasks that concern them.

Duplicated lists of Phabricator tasks on-wiki will get outdated and are not a solution. Linking to a Phabricator query (which does not need any changing on-wiki) makes way more sense.

A way perhaps to unburden phabricator and to bring the technical information closer to the concerned editors.

There is no burden. :) I only ask for projects to be maintained, have clear use cases, broader interest, and not increase fragmentation of venues even more.

Whereas a tag makes things much easier. Besides, it is also possible to make queries with keywords that allow to target a project.

I entirely agree with you on all of this.

Ok. Roger out, and see you next.

@JackPotte: Hmm, any take on the last comments?

Hello, sorry but today I still don't know how many French or English Wikibooks tickets we have, so I can't close the deprecated ones or treat the others with my PHP and JavaScript skills.

I still don't know how many French or English Wikibooks tickets we have

I don't know who else apart from you would use such a tag, and I don't know which criteria define "French Wikibooks ticket"... Maybe these help?:

• Query for "frwikibooks": https://phabricator.wikimedia.org/maniphest/query/_BN3XvU.8fQ4/#R
• Query for "fr.wikibooks.org": https://phabricator.wikimedia.org/maniphest/query/5k3bc35oiRkL/#R
• Query for "French Wikibooks": https://phabricator.wikimedia.org/maniphest/query/15G0HLGgoH10/#R

@JackPotte: Could you comment on my last comments please? Thanks!

Hello, about the fragmentation of discussions you've mentioned several times, I do not have any better solution than the one I had proposed above: document the Phabricator relation system into the wiki and participate to it.

If nobody else explicitly plans to use Phabricator for tracking Wikibooks work and if there's no community/communities' discussion about this idea, then I'd probably decline this task. :-/

Ok.

@Aklapper hello, if I may you're wrong about the "no community discussion about this idea" concerning the French Wikibooks because two of the four active admins came here to support the discussion I had initiated and mentioned above.

But as you're the Phabricator expert, if you say it's better to use some pages like https://www.wikidata.org/wiki/Q8090154#sitelinks-wikipedia to manage our bugs and features, let's continue with it.

PS: your three queries above contained many many false positives, but at least one forgotten fr.wikibooks ticket we should answer, which I had in my many individual bookmarks, and nobody else of the community seems to know about (and that's actually the current system which looks more like a burden than an open collaborative industrial system).