Who oversees the Babel extension?

Hello! Tell me, please, who from the fund oversees the Babel extension? This extension has a lot of problems that have not been solved for a long time. The lack of some features and many bugs interferes with the normal deployment of extensions to multiple wikis.

You can look at the board to assess the scale of the problem: https://phabricator.wikimedia.org/project/board/317/

Hi Iniquity. I’ll start by mentioning: Every piece of software in the world has a large number of open bugs and open feature-requests, and this is completely normal. See for example these open-source projects:

  • Chromium has 60,000 open bugs [ref] (out of 940,000 ever filed), and another 50,000 were auto-archived after a year of inactivity (a terrible method of dealing with large backlogs, imo).
  • Ubuntu has 135,000 open bugs - [ref]
  • Firefox has over 10,000 open tasks (their search won’t show any more than that [ref], but it was 44,000+ in 2011)
  • Wordpress has 6,500 open tasks (and employs 849 people, as well as having a large volunteer dev community)
  • VLC has 3,400 open bugs[ref]
  • Gimp has 1,800 open tasks [ref]
  • Drupal has 185,000 open bugs [ref]
  • etc.

That said, this is the small team that oversees a large number of software features, including Babel: https://www.mediawiki.org/wiki/Wikimedia_Language_engineering#Projects

More help is always needed! Just the same as in the content projects themselves. If you know any volunteer developers/designers/PMs/QA specialists/etc, bring them in!
If you can personally help to make a specific bug-description any clearer, then please do so! (I.e. many people are not good at writing clear bug-reports, and the top-description is important – it’s like if a newcomer starts a stub-article: some bug-reports are like terrible stubs and need to be edited before other people can easily understand & appreciate them)

I hope that helps.

1 Like

Thanks for the link, yes this is what I was looking for, but I think it will not solve my problem.

I liked your statistics, thanks for collecting it. But it does not fit our case. The Foundation has established this extension for all projects and has ceased to support it. This is not a separate development. For several years less than ten tasks were closed.

Now this extension works only half of the plan. For three years, while I try to popularize the extension, the situation has not changed. It comes to ridiculous that we can not even apply the patch, since there is no one to put +1 on it: https://phabricator.wikimedia.org/T177596#5032658. Why do you add something that you are not going to support? I would understand if it was an unknown extension that is not used by anyone, but it is used by all participants (almost) in the Wikimedia movement.

Ah, I see at https://www.mediawiki.org/wiki/Developers/Maintainers that user:SPQRobin is listed as a maintainer, so it might help to ping him on that task.

However, as I mentioned before, and Before you ping anyone, I strongly suggest that you improve the task’s description, because it currently includes a link to an example that is no longer accurate and for a user who hasn’t edited in ~4 years - those kinds of details are important! – And go slowly, just ping him in a single task to start with, to avoid overwhelming him. :)

(And you can see at that link, a rough list of how many extensions/code-areas the movement has to support, which are all important to some group of users. Some of those extensions/code-areas are very complex. More help is always needed. (and sometimes angry editors can demoralize the existing volunteer-devs and staff-devs so much that it can lead to them quitting.) It’s a bunch of hard problems. HTH.)

2 Likes

I see at https://www.mediawiki.org/wiki/Developers/Maintainers

Thanks for the link! A lot of useful information.

that user:SPQRobin is listed as a maintainer, so it might help to ping him on that task.

I do not think he will help me. He is not active since 2015.

However , as I mentioned before, and Before you ping anyone, I strongly suggest that you improve the task’s description, because it currently includes a link to an example that is no longer accurate and for a user who hasn’t edited in ~4 years

Yes, useful advice, I’ll see, but I don’t think it’s possible to expand it too much.

(And you can see at that link, a rough list of how many extensions/code-areas the movement has to support, which are all important to some group of users. Some of those extensions/code-areas are very complex. More help is always needed. (and sometimes angry editors can demoralize the existing volunteer-devs and staff-devs so much that it can lead to them quitting.) It’s a bunch of hard problems. HTH.

Why do you add all this, if there are no resources to support it? You start to develop some new solutions when the old ones are junk. In a year, the same thing will happen with new solutions.

1 Like

About language team, you can see what they think about Babel in Maintenance responsibilities section: https://phabricator.wikimedia.org/tag/language-team/

Why do you add all this, if there are no resources to support it?

Extension:Babel is already more than a decade old. The original (userbox-template) implementation is even older. I don’t think we have a rule that nobody should do anything unless they can promise to maintain it forever, right?

I know it’s frustrating to not get your patch reviewed. There are a lot of extensions that are only supported in theory. But surely we don’t think that reducing support to minimal levels after more than a decade is a good reason to never build new things.

If the extension is causing problems for other tools, it’s a reasonable expectation to get it maintained or removed. The process for that is code stewardship review.

(late reply) Basically, because people keep wanting better software, and more features! E.g. Babel was simple when it started out, but people always ask for it to support more and more edge-cases, like the feature-request you’ve linked.

Additionally, there is still software around that was originally written by volunteers or staff members who are no longer active, so there’s the hard question of: “should someone(s) spend time learning how that piece of code works, and reading all the old bugs to learn about the difficulties and bug-fixes that might be relevant for all future work, and then try to remember all of that on top of their normal work?” And related hard questions like “how do we prioritize the thousands of different feature-requests and bugs that are in any given developer’s existing areas of knowledge?”

The more code there is, the harder everything is to maintain/develop; but also the more features there are, the happier the end-users might be. HTH.

He was thrown in half, without telling anyone that it should not be used.

If my memory serves me, then these functions were already in the original version of the templates.

If these features work.

I would not ask this question if there weren’t one huge problem: this is one of the most popular extensions in the whole project. And for several years now I’ve been trying to achieve some kind of solution for this extension.