Page MenuHomePhabricator

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 All-and-every-Wikisource. The All-and-every-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 All-and-every-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

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

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.)

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.)

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

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).

Example for tracking bug for French && Wiktionary: T76447

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.

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.

I also think that it is better to start creating projects for project families like All-and-every-Wikisource and All-and-every-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

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...

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

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

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)

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,

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.

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.

Aklapper raised the priority of this task from Medium to High.Feb 25 2015, 7:36 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.