Topic on Project:Village Pump

Discussion has been moved to phabricator: https://phabricator.wikimedia.org/T260998

A good suggestion for improvement has developed from the deletion discussion of a template: At least in my reading there are several users who find it helpful to provide extension pages with an additional "used by" template.

What's this about? Similar to the already existing WMF template "OnWikimedia" the goal is to give extension pages a marker that this extension is also used in bundles, distributions, maybe even in larger websites or wiki farms. This way visitors of the page will see an information that the extension is "mission critical" or "best breed" in certain contexts. Especially since there is no real other way to know which extensions are widely used and which are not. This would hopefully also help us all to better understand which extensions need to be considered when technological structures change or which extensions need continuous maintainers. And, of course, in general, it is also positive feedback for the developers.

The deletion discussion made clear that such a template must be designed in a way that it does not promote a single project, but leaves room for as many projects as possible to be displayed in the template. And it could or should of course tend to bring together non-Wikimedia projects and Wikimedia projects, point to these projects, but must not overload the screen. It must also be clearly recognizable (in the documentation) that the template can be removed from the corresponding page at any time if the maintainer does not want the template there.

I have here a link for a first suggestion with three variants how this could look like, to give a visual impression of what we are talking about. First you see a variant with icons, a variant with text only and a variant with logo and text.

Now I would be interested in a first feedback, whether this intiative should be pursued at all and what advice and concerns there are about it. Then there is the question of whether the decision-making process should go through an RfC or whether we can already clarify this here, because everyone is for or against it anyway. I am looking forward to your opinions and help in order to move the issue forward in a timely manner.

> there is no real other way to know which extensions are widely used and which are not

That's not true. There's a "Check usage and version matrix" link in the extension infobox that tells you exactly that, and you can also look in which MediaWiki versions are being used.

If we're including such bundles or wiki farms, I guess we should also come with a policy about which bundles or wiki farms are considered relevant enough to grant them appearing on that template.

I like the idea of somehow providing a meaningful indicator of extension quality and support. Currently extension "status" is just up to the editor of the Extension page.

Also (a related tangential topic), the installer links to Category:Extensions by category - which has no filter capability (on quality or any other basis) and was first generated in 2007. The installer should be updated to direct users to a more meaningful directory of Extensions (and it would be nice if it had search / filtering capabilities).

@Ciencia Al Poder - I had seen that "Check usage and version matrix" link a thousand times but never thought to click on it! (Maybe because it's a boring name for a link.) I was surprised to see that it links to WikiApiary. It's certainly a useful link, and I'm glad it exists, but I think a "Used by" template would still be useful as a way to see additional information about usage.

The policy question is an interesting one, though. Even if there is a policy in place, the "Used by" template could still get overwhelmed by names (at least for certain extensions), if various consulting companies and/or hosting providers start to see this template as a way to advertise their services. If there's no policy, it could be worse - although then again, I can't imagine what such a policy would be. What could a consulting company provide to prove that they are legitimate, or large enough - a bank statement?

Any thoughts on this?

Thanks again for the reference to the link to WikiApiary. It is true that it gives you a first estimation about the distribution of extensions. But only via wikis that are accessible via the web. But not about systems that live behind firewalls. That's what I meant when I wrote that we only have limited possibilities so far. The extension bundles for public wikis and internal wikis are very different. And we have a view that takes both worlds into account.

@RichardHeigl - what do you think about the danger of this template getting overloaded? Perhaps it's not that big a fear; I don't know. One option is to have the template "collapse" if it has more than some number of values, like 20 values - if it does, it can say something like "This extension is used in many bundles and wiki farms; click here to see the full list."

As for the mockups you created - I think I prefer the 2nd one, which is just a list of text terms. The 1st one, with the logos, is nicer-looking, but it can be unclear: first because most people won't recognize the logos, and second because a single logo might not communicate enough. What if a company produces more than one bundle? (Hallo Welt might be in that situation, actually.) If you want to clarify which bundle(s) this extension is part of, that would be difficult to accomplish with just a logo.

The 3rd option I don't understand. What does "as needed" mean, and what would the other options be?

WikiApiary gives you an unsorted list of random wikis, I don't think it's sensible to expect people to glean any useful information from that. Although the same can be true for "used by" templates - the extension is part of MyMediaWikiBundle, so what? Does that imply some level of support? Does it imply some level of testing? Does it mean someone evaluated it? How long ago, against what criteria? UsedByWikimedia is not super helpful but at least tries to characterize what can be inferred from the presence of the template.

@Yaron_Koren: A good developer's question: What happens when there are a large number of entries? It can be done the way you suggest: So open a complete list at the push of a button. But at the moment I think this is still a luxury problem. And I also don't see the template as an instrument that should represent "completeness". I would be glad if five / six projects would voluntarily start to enrich extension entries with this additional information. "As needed" is only a placeholder for more entries.

Which brings me to the objection of @Tgr. What does it mean that an extension is part of a bundle or a project? For me it is the statement that the function is operational and its basic function is tested ("runs for me"), that its functionality is at least probably, if not guaranteed with other extensions and that through these projects people can be found who can remove incompatibilities, contribute patches or function extensions if necessary.

This has pretty much the same function for me as the hint that extension XY runs on Wikipedia. That means for me: It is tested and maybe even maintained there.

But there are many extensions that Wikipedia does not use or that only work on Wikimedia servers. In this respect, I see the added value of such a template in the possibility of being able to research whether an extension is also used in others and in which contexts. Unfortunately, Mediawiki.org does not offer any further possibilities to store and evaluate corresponding metadata.

Actually the problem is, I can see that, that the entries have to be kept up-to-date. That would be a showstopper.

Rereading Tgr's post again: Do I understand you correctly that such a template like the Wikimedia template should include a hint, which is implied? e.g. "This probably means that the extension is stable and works well enough to be used in <context>".

• A template mentioning multiple "used by" entries should show those entries in random order.
• I see the risk (as with any other human maintained list) that over time a lot of orphaned entries will render the list useless.

@Planentenxin: I disagree - I think the list should always be in alphabetical order, to make it easier to see if some specific company/package/farm supports this extension. If "Acme Consulting", or whoever it is, benefits by always being first, so be it - I don't think being first is that important.

I also have to disagree with, I guess, both Planetenxin and RichardHeigl that out-of-date entries would ruin this whole feature. There's a lot that's out of date on mediawiki.org in general, but that doesn't make the site useless. People who use "Used by" to find a package to download, a wiki farm to use, etc. will quickly discover if they were given bad information. And of course, it's a wiki, so it's easy to update things.

But I'm curious now about the fact that the proposer of this idea, RichardHeigl, now thinks that there's a big flaw in the plan. Does that mean that this idea is dead?

Hello, Yaron. The idea isn't dead and I don't think it has a fundamental flaw. We now have a number of good suggestions and advice, so I would make a revised draft (I think until next week). I personally prefer a text/picture version with notes and documentation as requested above. But these are then design issues.

The only problem I find so far is that I don't know how we should or can introduce this. It doesn't make much sense if we now put the new template on extension pages. That would then lead to further discussions. We would need the approval or commitment of some stakeholders in this process. So do we have to do an RfC after all? What is the best way forward here?

Okay, great. I'm looking forward to seeing the demo! After that, yes, an RfC might make sense.

@Yaron: position matters, see Serial-position effect. So the only fair way would be a changing random order.

I know that position matters (that's why there are so many companies in the English-speaking world named "Ace, "Acme" or "AAA", not to mention "Zenith"), but I think the benefits of having a consistent alphabetical order outweigh the drawbacks.

Reminder: This new template is all about making projects visible and bringing people together. And I'm largely there with all the proposals. To be honest, I don't like the random order, and not because I care that BlueSpice comes before Fandom. I really don't care about that at all. We can also put BlueSpice somewhere in the middle. But there should be a consistent, easy to follow order that doesn't produce arguments and long discussions. Except alphabetical order I can't think of anything else. Is random distribution technically possible? Relevance criteria are completely out of scope, that's causing a lot of trouble. But as I said, the order is not that important to me. I consider that at the moment a secondary topic. Let us focus on the main challenges. One of them: Who will actively support this template?

And I also think that it can be designed in such a way that nobody feels cut off here, especially because I assume that only a small number of projects will be shown, at least for the foreseeable future, because the main effort is to enter them and that has to be done first. This will surely remain rather clear at the beginning. The luxury problem of too many entries I would like to have first.

As I said, I hope that next week I will be able to deliver another draft and then we will see if the existing reservations can be removed. Personally, I would like to see a variant that offers colored pictures/logos and text. This makes recognition much easier and projects do not disappear in a text landscape. But let us see.

And then we will hopefully create a small contribution through which the sub-projects will become more integrated and refer more to each other. In no other community this seems to me to be as difficult as with MediaWiki. But we should overcome this quickly if MediaWiki is not to disappear outside of Wikimedia.

Well, no need to be dramatic. :) But I'm looking forward to the next drafts.

Here are now the other mockups, which meet different requirements: https://en.wiki.bluespice.com/wiki/MediaWiki-usedby#/media/File:UsedBy-option1.png

First a completely unobtrusive text variant, then a text variant with a pop-up mechanism and reference to different editions, then different variants with a logo/text combination and once again variants with "buttons".

We have added a sentence that should make it clear why this template exists and what the referencing of the projects should say. We have also tried to use a different sort logic (alphabetical, but starting in the middle and then "rotating").

The relevance criteria question (inclusion of a project) should still be difficult. I still consider this a luxury problem, but I imagine that in the template documentation there are minimum criteria such as installation numbers, download and visitor numbers that have to be met. And there are still discussion sites where you can negotiate borderline cases.

What do you think?

I now see an RfC as the next step. I have never done this on mediawiki.org before. Can anyone support me there?

Overall these look pretty good, I think. I don't think it makes sense to include "large websites" as an option, unless you have a precise metric for that (I guess that's what you were getting at in the end). I also don't think it makes sense to include that second sentence ("This means that this extension seems to be stable, the basic function is tested and running and the extension is or should be maintained") - people can judge for themselves what it means that extension X is used by Y and Z. As for the different layouts - they all seem fine to me. I'm glad that the name, not just the logo, is visible in all of them.

As for an RfC: just create a draft RfC page, and I think other people will be able to help at that point.

After some research I came to the conclusion, that an RfC does not seem to be the right way (as the procedure is reserved for technical issues). The discussion will now be continued in this ticket: https://phabricator.wikimedia.org/T260998