Phabricator projects for Wikimedia sister projects
Closed, ResolvedPublic


The idea of having Phabricator projects for Wikimedia sister projects has been suggested several times for several reasons, and it starts to be the time to discuss it properly.

From a Project-Admins point of view the answer is simple: if Wikimedia sister projects want to have Phabricator projects, they can have them. It's just that there is hundreds of them, and they have a potential of opening cans and boxes with unexpected content inside. :) For instance, are we ready to receive hundreds of tasks in dozens of languages and a request to localize Phabricator? Or to have users starting VillagePump-like discussions when the admins of those projects are not even following here? We need some coordination before approving the first project.

As usual, a good first step is to define needs and specific usecases.

  • Better organization for some specific projects., Meta, Commons, have very specific needs and well organized communities used to work in English first. We might just want to open the door to them right away.
  • A bridge between non-technical users and developers. Not many users will know that a problem is related with the Proofread extension, but most of them will be able to tell that their problem is happening in Wikisource. The Wikisource project can be watched by tech ambassadors and other users knowing well that community and its technical links, people that are in a good position to help those users and triage those tasks.
  • Localization step 1. As of today, Bugzilla and etc are English-only tools, but only the simple fact of having editable descriptions provides an opportunity to be more flexible. What if a user would be able to file a task in French for (and/or #French Wikisource, another detail to be defined)? Then the contributors watching these projects could help triaging the task in French for that user, and translate to English if there is a valid new bug.

Feel free to add more.

PS: marking this task as Low priority only to reflect that the ongoing migrations have a higher priority. The own editors of sister projects will probably understand better this discussions and what they want to do with Phabricator once they see Bugzilla and a critical mass of Trello / Mingle projects migrated here.

Related Objects

There are a very large number of changes, so older changes are hidden. Show Older Changes
Aklapper claimed this task.Nov 25 2014, 3:58 PM

If we want to have this, we need to define a clear use and intention.
Going with projects there likely should be a separate project/tag symbol. The current project types can be seen here (and the idea to categorize by human languages is the same).

For example, I've seen the pattern on Bugzilla that bug reporters set the "Browser" field to the browser they were using (without having tested whether the problem also happened in another browser), while developers expected the browser field to be set when the problem refers to a specific browser.
I'm afraid of similar problems here, and inconsistent use makes a list of tagged tickets not very helpful in the end.

Qgil added a comment.Nov 26 2014, 9:09 AM

Discussing this here without "the projects" is pointless. Then again, who are "the projects"? Should we send an email to wikimedia-l? @He7d3r, @Quiddity, others, any ideas?

I mentioned this task in the talk page of the ptwiki:
I think sending an e-mail to e.g. wikitech-ambassadors, commons and wikisource lists too wouldn't hurt.

I think the scope of this task is currently excessively broad. I suggest that we try converting one of the former tracking bugs (e.g. those above, ) into projects if the respective subscribers etc. agree; then assess if the model works and can be extended.

As for localisation, I had the crazy idea the other day that I could offer to watch a project #italiano where users can file reports in Italian and I translate them (as pilot language). A translation service doesn't require consensus, but the pilot would be easier to assess for a smaller language (where you can be sure most people know about it, etc.).

Yes, thank you for cross-referencing this. (Now T40994.)

Qgil added a comment.Nov 26 2014, 10:36 PM

Personally, I'm happy to try experiments both for projects and for languages. As @Nemo_bis says, the requirement would be strong backing from the project / language community, and known maintainers committing to the task.

PS: ref language, I had the same wild idea and, in fact, I started suggesting it to Amical Wikimedia and other #Catalan speaking wikimedians at the recent Viquitrobada (annual meeting of the Catalan speaking community).

(Turns out some of the contributors are already registered here. Hola! See above.)

Qgil updated the task description. (Show Details)Nov 27 2014, 9:04 AM
Qgil removed a project: Phabricator.

Note that we have, which is about the website and not the software.

Qgil added a comment.Dec 1 2014, 7:55 AM

Moving a comment here because the discussion can be applied to any project, not just Wiktionary.

Please elaborate how this tag would be used in Phabricator exactly.

I'm not really sure how to answer that. It will be used to track tasks related to Wiktionary (e.g. T986 and its dependencies). What other information are you looking for?

I might be against fulfilling this request without having a general plan for T802 in place first.

It's not intended to replace any existing wiki-based discussion mechanisms, necessarily. It's meant to be used as a bug/task tracker, as Bugzilla/Phabricator are intended to be used.

The two main risks we want to avoid are

  • Tags of Wikimedia project families being created here without any involvement and awareness of the projects affected, probably leading to tags not being watched and maintained.
  • Users reporting tasks under i.e. a "Wikipedia" project when they are not Wikipedia specific, only because they found the problem in Wikipedia. This problem aggravates when there are no active watchers cleaning up.

The first problem can be resolved acting upon tags being requested (like Wiktionary now, T75872), checking that there is community support. How that support is registered across different languages I don't know, but I'm sure there is enough people capable of assessing this.

The second problem can be partially resolved by using a more explicit tag, like for instance #Wiktionary-Specific, #Wwwwww-Specific.

Lydia_Pintscher removed a subscriber: Unknown Object (MLST).
jayvdb added a subscriber: jayvdb.Dec 2 2014, 3:32 AM

Example for tracking bug for French && Wiktionary: T76447

Qgil awarded a token.Dec 13 2014, 10:46 PM

As a contributor of the French Wiktionary, I want to be able to find and organize bugs/requests about both the French Wiktionary (e.g. Extension requests like T73330) and the Wiktionary projects in general, all languages included (e.g. category sorting T30397).

As such I created and T76447 (fr.wikt) and T78531 (All). There may be a better way to arrange things (projects?), but I see both tracking tasks as separate and necessary.

Qgil added a comment.Dec 19 2014, 10:32 AM

If we are talking here about tracking software bugs, the big majority of them are not tied to a single language. Also, while we have a dozen project families, there are hundreds of project-language combinations.

Since this task includes a possibility create tags for languages, users interested in watching i.e. Wiktionary-fr relevant tasks could still create saved queries for Wiktionary AND French, helping both the Wiktionary and French families by taking care of a specific corner.

Had drafted some comments for T78482, now pasting them here:

I'd be willing to give this a try if wanted by some communities as it's an idea to improve the communication/escalation of requests popular in certain communities towards developers and product mgmt/maintainers. I'd also be very interested in existing approaches I'm not aware of (Community Engagement?), this might not be engineering territory only but also editor and reader territory).

I'd want clear scope definitions for such tags. "happens on Wikisource" is not clear enough. Tagging every ticket in the Extension-FooBar project with a "Wikisource" tag just because Extension-FooBar is installed on Wikisource will only bring noise.

We'll face the usual problems of "measuring popularity" here, something that IMO already failed in Bugzilla with its busted "voting" functionality. Will "5 communities have this on their radar" suddenly influence decisions? I do not think so, hence it should be clearly communicated that if you want something badly you need to argument why instead of only adding a project to a task.

The difference in the UI to tokens or Bugzilla's voting would be that these "expressions of interest" won't be "anonymous" (requiring a click to see the voters or mouse-over to see token creators) but showing names of communities. That also allow interpretations/judgement (size of community? Organization level? Age?). Don't know if that's good or bad and not asking that, just pointing it out.

Naming scheme: Something like "wiktionary-fr" (must be a clear scheme, "site-lang") with its own "community interest" project color and icon?

I will respond with my Wikisource hat on.

To this point of time there has been a broad and shared approach to improvements to Wikisource in the cross-language community. We had one (joint) meetup at Wikimania, not per language. The communities are not excessive size, we have shared visions on numerous issues, be it improving participation, sources, tools, help pages, etc. We do have a couple of predominant communities developing Wikisource help content and having a space to specifically point to the project aspects would have an advantage to the smaller language wikis. In a means we have been undertaking some project coordination at mulWS, and via Wikisource-L, a project tool makes more sense for numbers of components. We have a history of a cooperative approach, and shared success, and sharing skills to new wikis in assisting their set-up. We have seen some language wikis act run pilots, with adaptation by wikis of tools and scripts, and again, this seems something that a project-based approach in Phabricator can nicely emphasise, record, and have an improved approach to proactively share.

We have tracked bugs successfully in bugzilla using the one ticket. I think that (with some guidance) we would look to wisely utilise and tag components, and see that your guidance is relevant across of all of phabricator, not just projects, and training and vigilance, and gentle prodding will make it work fine.

If it comes to subcommunities of WS, I would agree with your suggestion for nomenclature.

Raymond removed a subscriber: Raymond.Dec 20 2014, 12:22 PM
Qgil added a comment.EditedDec 20 2014, 3:07 PM

I also think that it is better to start creating projects for project families like Wikisource and Wiktionary, and see how it goes before jumping to specific project-language pairs.

I'm not sure about bringing another icon-color label. Communities are people, teams are people, so maybe we could just the people-violet combination as in Project-Admins.

For example, I've seen the pattern on Bugzilla that bug reporters set the "Browser" field to the browser they were using

In case that having projects for sister projects increases participation in Phabricator, this specific item would probably be less an issue as a second user quickly notes that it's obviously also affecting their browser. Generally it takes me too much of my spare time to reproduce issues on other browsers or under other conditions and I'd be happy if someone else who just experienced the same but with a different system, or under different conditions could add to the task by generalization of the task description (or just adding a comment).

For what is worth, I mentioned this discussion on

Krinkle removed a subscriber: Krinkle.Dec 21 2014, 4:21 AM
In T802#937886, @Rillke wrote:

Wikidata have a own project, so i think it should be possible for commons too.

In T802#937818, @Qgil wrote:

I'm not sure about bringing another icon-color label. Communities are people, teams are people, so maybe we could just the people-violet combination as in Project-Admins.

Makes sense. Though still wondering about some suffix like "Wiktionary-community" or such as we already have some ambiguity like the Wikidata codebases/projects vs the website and such. And .org won't work as does not exist...

Qgil added a comment.Dec 29 2014, 1:30 PM

Maybe Wikidata is the exception here, since development and community are so tightly integrated?

I would just try with Wiktionary, Wikisource, Commons, etc, and see what happens. Renaming is easy.

Steinsplitter added a comment.EditedDec 31 2014, 9:56 AM
In T802#937818, @Qgil wrote:

I'm not sure about bringing another icon-color label. Communities are people, teams are people, so maybe we could just the people-violet combination as in Project-Admins.

Makes sense. Though still wondering about some suffix like "Wiktionary-community" or such as we already have some ambiguity like the Wikidata codebases/projects vs the website and such. And .org won't work as does not exist...

Why not Wikimedia-Commons or (- because " " is not allowed)

Qgil added a comment.Dec 31 2014, 2:35 PM

Is there any problem with "Commons" for starters?

In T802#950659, @Qgil wrote:

Is there any problem with "Commons" for starters?

I don't think so, for example [[:commons:]] is used onwiki for crosswiki linking to commons,

Krinkle removed a subscriber: Krinkle.Jan 9 2015, 3:55 AM
revi added a subscriber: revi.Jan 25 2015, 10:38 AM

An aspect to NOT cover here but probably for a followup task once this one is sorted out: All WMF sites for a certain language, like T43348 for Hindi.

Aklapper added a comment.EditedFeb 24 2015, 3:21 PM

Proposed list of projects to start with:

Further projects could be created on request and if interest is expressed to follow these projects.
Quoting again:

In T802#789577, @Qgil wrote:

the requirement would be strong backing from the project / language community, and known maintainers committing to the task.

For example I admit that I am very reluctant to create a "Wikipedia" project because everybody might just drop their stuff without reading the description.

Potential future step (just dropping it here): Language level. Existing tracking tasks I am aware of:

Great Bikeshed potential!: Full language names with different spelling variants (e.g.: Oriya? Odia?); short versions language vs. country code (e.g. cs vs. cz); Norwegian's no vs. nb vs nn; language and script variants (zh-min-nan vs. zh-yue etc.; sr-latin vs. sr-cyrillic etc.); findability of each concept for task reporters; etc etc.! Not as trivial as it sounds. Just saying.

Initial batch sounds reasonable.

Aklapper raised the priority of this task from Normal to High.Feb 25 2015, 7:36 PM

Potential future step: Language level.

Split into T91286. Please follow up there.

Aklapper moved this task from Backlog to Ready To Go on the ECT-March-2015 board.Mar 3 2015, 4:13 PM
Aklapper closed this task as Resolved.Mar 10 2015, 4:53 PM

All three blocking requests have been resolved so I'm closing this ticket.

Though I wonder whether to document / advertise the option to create further such projects somewhere and the conditions / expectations / goals described in this ticket (or just linking to this ticket). feels like the obvious place for it? Not sure though what to put there.

Plus as mention before, T91286 might be a next step but that needs way more thoughts first.

Happy project management everybody! :)

Thank you!

I would prefer not to touch that page with something as specific as this. You could send an email to wikitech-ambassadors sharing the news and inviting other projects to discuss whether they want to join as well. That, and the mention in Tech News that the use of User-notice should bring, are probably enough for now.

Keegan moved this task from Backlog to Done! on the Community-Liaisons board.Mar 12 2015, 5:50 AM
In T802#1105647, @Qgil wrote:

You could send an email to wikitech-ambassadors

...and finally done now: