Project talk:WikiProject Extensions

Home

Discussion

Participants

Projects

Ideas & Requests

Workshops

Barnstars

Templates

First thought

Hi Varnent, this concept/proposal assumes that coders behave like wikipedians in a sense that they like editing wikis. My experience is that there are a lot of coders out there who do not behave like wikipedians. I even believe they represent the vast majority. They are more into coding which is understandable. Some extension pages do not even offer a utmost useful description and how to for that very reason. Since this concept requires even more involvement ... It would be good to have some comments on this be leading MW coders. They know their community even better and will be able to provide more elaborate comments on this. Cheers [[kgh]] 18:27, 5 December 2011 (UTC)

I think the rather poor and confusing documentation on mediawiki.org itself is proof that coders do not like editing wikis. In fact one of the major hurdles to editing or creating an extension is the documentation itself. Oh, the irony. 173.35.238.53 18:50, 25 February 2012 (UTC)

I think everyone is aware of the problems. I'm curious what ideas folks have for solutions.  :) Varnent (talk) 20:21, 26 February 2012 (UTC)

I think one of the only solutions to solidifying the developer community is to engage those developers on-wiki. IRC is a good vector for discussion, as well as the mailing lists, but for larger-scoped and more permanent discussions and project descriptions, we're all going to have to commit to editing the wiki. Now, the issue becomes, how do we entice get the developers to edit the wiki? One thing I can think of is attribution and/or recognition for their work. Barnstars are great, but don't really carry that much weight with the community. —Daniel ^talk/_email 00:48, 30 July 2012 (UTC)

Extension maintenance

One thing that is sorely lacking in the realm of extensions is a funded effort to ensure extensions are maintained and kept up-to-date with changes in MediaWiki. Lots of potential donors to the WMF could be coaxed into pulling the trigger if they were given assurance that their contributions would serve to keep their own MediaWiki projects running smoothly. There is no coordinated leadership in the maintenance of extensions, and not only can the WMF fulfill that role, the WMF can also use it as an opportunity for friends of the WMF to find a reason to donate.

Already, it appears the WMF's capability to drive MediaWiki development is outstripping the capability of volunteer extension writers to keep up. Here's a specific example of a popular extension that is perpetually lagging behind MediaWiki:

http://www.mediawiki.org/wiki/Extension:TreeAndMenu

"MediaWiki has undergone a lot of changes in recent versions...It takes a lot of work to write code and it's all done for free, so can take a long time to get the extension up to date with the current versions of MediaWiki."

Even though the WMF does not use all of these extensions, it is the cooperation with all interests that has made the WMF what it is today. There are lots of talented coders out there that have either come and gone from MediaWiki coding, or not come at all, I believe due to the lack of personal resources to devote to their pet projects. Even token bits of funding directed toward developers of popular extensions can do a lot to encourage them to find the time to maintain their extensions, or find someone who can. Badon (talk) 07:21, 23 February 2012 (UTC)

"Lots of potential donors to the WMF could be coaxed into pulling the trigger if they were given assurance that their contributions would serve to keep their own MediaWiki projects running smoothly."

That's not what WMF and it's 501(c)3 non-profit donated funds are there for. WMF donations are (in some countries) tax-deductible as a contribution to "adult education" as a charitable endeavour, but that's only possible because the money is supposedly going to assemble and give away a free encyclopaedia.

If the extension is actually needed for deployment on WMF sites, fine.

If not, what does any of this have to do with building an encyclopaedia? Carlb (talk) 15:30, 28 February 2012 (UTC)

No, that's not quite correct. Badon (talk) 21:33, 28 February 2012 (UTC)

I don't think that's really a fair interpretation of IRS code or WMF's mission statement..

"The mission of the Wikimedia Foundation is to empower and engage people around the world to collect and develop educational content under a free license or in the public domain, and to disseminate it effectively and globally.

In collaboration with a network of chapters, the Foundation provides the essential infrastructure and an organizational framework for the support and development of multilingual wiki projects and other endeavors which serve this mission. The Foundation will make and keep useful information from its projects available on the Internet free of charge, in perpetuity."

A lot of that language talks about broad applications, supporting an infrastructure, etc. To me, all of that covers the development of tools, like extensions, used by other free-content wiki participating in the broader MediaWiki community of projects that "empower and engage people around the world to collect and develop educational content under a free license or in the public domain."

I can wrap my head around this not applying to wikis that are private, or for-profit in nature. However, supporting tools available to any wiki and used by a several different wikis, then paying for it with donations by corporate interests isn't much different than WMF taking corporate donations from companies that have an interest in WMF's software, existence, etc. - such as Microsoft, Facebook and Google. This is pretty typical in the world of nonprofits. A community film festival sponsored by Sony, nonprofit museum's launch party sponsored by Absolut, college video game competition sponsored by Microsoft - there are a number of good examples of what I think Badon is referring to already being applied in similar nonprofits.

See my comments elsewhere for more thoughts on related topics.. Varnent (talk) 04:17, 29 February 2012 (UTC)

By "the development of tools, like extensions, used by other free-content wiki participating in the broader MediaWiki community of projects that 'empower and engage people around the world to collect and develop educational content under a free license or in the public domain'" would that not be Wikipedia or other *very similar in objectives* projects (such as Enciclopédia Libre in Seville)?

I can't see most of the fancruft on Wikia being "educational content" or that site's mission to take other people's content and bury it under ever-increasing quantities of advertising to be a charitable endeavour. Wikia's investors might love to see an extension invented that makes the site look exactly like Facebook... but what would that have to do with collecting and developing educational content of any kind?

Likewise, would Uncyclopedia and extension:RandomSelection qualify? They're amusing, but I have the sneaking suspicion that their only enduring educational accomplishment is to lower the collective IQ of Brazil at least two or three points since the first Desciclopédia article was written in 2005, with similar but lesser results in other countries where various languages of Uncyclopedia operate.

If this were something like Extension:Cite or Extension:Math, which is used in the encyclopaedia, sure - treat them as if they were core code. The same would not apply, though, to the seemingly-endless efforts to keep inventing and reinventing more extensions to turn a wiki into an endless collection of links to YouTube (for which we have too many extensions already). Carlb (talk) 15:36, 29 February 2012 (UTC)

The more closely aligned the extension is to the interests of the ones helping to maintain the extension, the more attention it will be given.

For WMF help, extension maintenance for Wikia, etc, may be limited to just advisory assistance with updates to keep them compatible with current versions of MediaWiki. For independent volunteers, they can do much more than that while receiving the same kind of advisory assistance from WMF.

Cite, Math, and anything else likely to have broad public benefit can have unlimited attention from WMF, as needed.

Hopefully it is clear to you that there's nothing about this that instantly leads to certain doom. Resources can be allocated according to the greatest benefit, but no one should be left out completely. Badon (talk) 21:23, 29 February 2012 (UTC)

template - extension code in wiki

I'm constantly being templated with {{Extension code in wiki }} but, on looking at https://blog.wikimedia.org/2012/02/15/wikimedia-engineering-moving-from-subversion-to-git/ I'm told "Right now, we’re asking people to stop creating any new extensions in Subversion right now, and to watch the wikitech-l mailing list for more updates."

Which is it? Go dump a pile of extensions into SVN, seemingly with no regard to either their usefulness or any duplication of functionality already in other extensions already there, or lay off on that idea entirely because WMF is in process of replacing SVN with git?

This is a very confusing mixed message.

Spamming templates onto large numbers of individual-extension pages telling authors to apply for SVN commit access might make no sense at all if SVN is about to go away or be replaced... so, perhaps lay off with the templates until this is done? Carlb (talk) 04:59, 28 February 2012 (UTC)

I can appreciate your concern. However, I hope that we do continue to place them, even during the migration.

Perhaps if for no other reason than the template is as a warning for system administrators as much as a request for extension developers. Also, you can now request access to git for your extensions, so there is a new solution. Documentation, including that template, is in the process of being updated. There are a couple weeks of overlapping messages during this transition while everything is being finalized. I'll admit, that's annoying.

Once the git migration is completed, there will be an effort to move any functional extensions that have code in wiki onto the git repository. It's better to house the code on the WMF tool designed to house code - if for no other reason than it makes it easier for folks to flag issues with it and tweak it. Whereas many folks are not comfortable doing that with code placed within wiki, and there's generally no awareness of the status of those extensions as again, they're outside the code repository. A part of assessing if an extension is "functional" will include a compatibility check and an effort to look into function overlap, etc. Some of this is being done now as a part of the same drive that's placing more of these templates. Extensions that are incompatible, not being maintained and do not show signs of active use (comments in user talk about its incompatibility, etc.) are being archived.

Regarding holding off, I'm hoping we don't hold off. We'd like to have all of these extensions tagged in time for some possible hackathons and other activities that could help address some of this workload. Again, I recognize during that time it's an inconvenience. However, it's volunteers reviewing hundreds of extension pages - so that effort alone won't be completed until after the git migration is completed.

Essentially, why wait until tomorrow what we can do and prepare for today? Varnent (talk) 09:27, 28 February 2012 (UTC)

Edit one or more extension: pages, get a {{Extension code in wiki }} saying <small>''The developer is encouraged and invited to get [[commit access]] to MediaWiki's [[Subversion|code repository]] to address this.''</small>.

Then what? I applied for SVN on the 14th, only to then see posted the next day https://blog.wikimedia.org/2012/02/15/wikimedia-engineering-moving-from-subversion-to-git/ with "Right now, we’re asking people to stop creating any new extensions in Subversion right now, and to watch the wikitech-l mailing list for more updates."

Looks like a waste of time.

I do not intend to re-apply for git.

Much of this on-wiki code is only here because it's something kludged together to keep an author's own wiki site up and running. In some cases (a namespace editor, for instance) the intent was only to use an extension as a stop-gap measure while waiting for core to add some needed functionality (whatever happened to the wikidata-style namespace editor, already pretty much working, which was supposed to be core in MW 1.07+ anyway?)

In most cases, the question of whether these code fragments are of any potential use to anyone else is merely an afterthought.

I can't comment on whether my own experience is typical of extension authors; some extensions were written by people who have vanished years ago and nothing will be done, others were written by WMF staff for deployment on WMF projects and are therefore core code in all but name. The rest of us land somewhere between those two extremes - we don't care whether some piece of code kludged together to keep one non-WMF project up and running is reused elsewhere - the code isn't trade secret, but at the same time the effort spent applying and re-applying for access to one or another code repository just to publish it on the off-chance someone wanted a peek at it is a pointless overhead cost with no benefit in return.

If you must keep templating {{Extension code in wiki }}, could you please remove the bit directing authors to subversion in light of the request "asking people to stop creating any new extensions in Subversion right now"? Carlb (talk) 14:58, 28 February 2012 (UTC)

Yes, all templates referring to SVN are being updated in the next couple of weeks. Varnent (talk) 04:03, 29 February 2012 (UTC)

Any reason for not removing the one line saying <small>''The developer is encouraged and invited to get [[commit access]] to MediaWiki's [[Subversion|code repository]] to address this.''</small> from {{Extension code in wiki }} now, or even two weeks ago (when the original request to stop checking new extensions into Subversion was made)?

Changing this now (to remove SVN) does not preclude updating it again once 'git' is fully operational. It's just one line in one template.

Also, why the sudden huge concern that an extension might have code on wiki while there is seemingly no concern about extensions where the code is hosted off-site somewhere. The latter should be the greater problem as we have no means to recover if the externally-hosted site goes away entirely (something which happens routinely, if authors are pointing these to their personal sites)? Carlb (talk) 15:11, 29 February 2012 (UTC)

I'm a little swamped with other things - but when ahead and updated that template since you feel so strongly about it.  :/ Remember anyone can help by updating templates - we're all volunteers.  :)

You're welcome to start an effort to combat the code that is hosted off-site. Some folks I spoke with felt that was a fair solution for people that didn't want others editing their code, but wanted it to be available on MW.org. One could certainly argue that's a problem worth addressing, but it's not the one this template or drive is intended to address... I think a template to highlight the dangers of those extensions is appropriate. If you create one, we can add it to the extension templates list. You can also request it in the project and I'll try to get to it in the next couple of weeks. Varnent (talk) 03:57, 1 March 2012 (UTC)

Template for Extensions needing documentation

Is there a template for extensions needing documentation? Someone created a bug requesting improved documentation and I'm sending them here. ☠MarkAHershberger☢(talk)☣ 03:42, 7 March 2012 (UTC)

These two seem to be the closest...but we could do something extensions specific too if that'd be helpful..

• {{CodeReviewNeeded }}
• {{Fixme }} Varnent (talk) 20:18, 7 March 2012 (UTC)

Concerning; Conflicts of Project Management

This inquiry is directed towards the Dispute Resolution committee(s) of this and other WikiMedia sites.

Accordingly; I recent signed on as a member of the 2012 Extension Page Review Drive project here on the mediawiki site, under the direction of User:Varnent and proceeded nonchalantly and without bias intent to try new extensions, reporting 'some' of those that did not work with MW1.19. I had positive results until approached by User:Jasper Deng who did accuse me of a gross misrepresentation (see; Concerning; Extension:SecurePoll).

There is an obvious conflict of Project Management in this case. I do not have any legal issues with the aforementioned editor, nor the original author of the extension(s) in question. I only intended to notify other editors and users that the published version was not completely cited for useability by using site authorized templates.

In addressing the editor's usage of Wikipedia material, there are more conservative [1] than accusations being drawn.

Please consider establishing a new Project Resolution process to avoid possible edit conflicts. Such a resolution may include a new showcase project for system or featured extensions, so reducing unsolicited traffic, notification for project members and providing administrative overhead for developers.

Disciplinary reliefs will not be sought in this matter. Habatchii (talk) 00:51, 11 August 2012 (UTC)

Convert this to a MediaWiki Group?

Hi, now we have MediaWiki Groups and this WikiProject is a good candidate to become one. What do you think?

More: Talk:Groups#Deprecating_MediaWiki_WikiProjects. Qgil (talk) 22:55, 13 December 2012 (UTC)

Unanswered question

Hi all

I am unfamiliar with how media-wiki support works. I believe I posted in the right place but, as questions there seem to go unanswered for quite some time, I thought maybe someone here could point me to where I can ask for the info?

Original question

Thanks Chaosdruid (talk) 19:05, 30 May 2013 (UTC)

See Project:Support desk. Qgil (talk) 22:19, 30 May 2013 (UTC)

extension list

I am going through the wiki installation and want to add extensions i think it would be good when the link at the front-page leads to a tutorial about extensions instead to the developers place. 27.109.112.113 20:20, 28 July 2013 (UTC)

Git submodules, subtree, or symlinks?

I have a MediaWiki installation that I want to keep linked to the mediawiki/core branch so that I can keep updated with the code. That MediaWiki installation would be used for testing of my extension that I'm writing which would be written in the regular /extensions/MyExtension directory but I would also like to use a local git repo to keep track of my extension's changes. Should I use git submodules, git subtree or symlinks so that I have a git repo in my /extensions/MyExtension as well as the mediawiki/core? What do you use/recommend? Thanks, -24^Talk 16:10, 6 August 2014 (UTC)

To write and live-test my extension, I have a symlink from core/extensions/MyExtension to my extension directory, but you can also `cd core/extensions; git clone /your/extension/MyExtension` if you want to keep control of the deployed version. You can be interested by MediaWiki-Vagrant (I cannot give advices with that, I didn’t succeed in installing it). ~ Seb35 [^_^] 21:06, 14 September 2014 (UTC)

There is a .gitignore file in mediawiki/extensions/ that ignores everything in 'extensions' so MyExtension will not "interfere" at all with updating your core checkout.

If your extension is brand new and you aren't hosting the code anywhere (meaning there is no "remote" for your code), just create a git repo in your project folder itself. ie.

# create a MyExtension directory in the extensions/ folder.  
MyExtension=AcmeWidgets
cd path/to/core/extensions
mkdir $MyExtension
cd $MyExtension
# hack hack hack
git init .
git add . -m "initial commit of $MyExtension code"
# hack hack hack
git commit -am "some more improvement, getting close to feature complete"

Later, when your extension is ready to be published, you can add a remote to your $MyExtension and push it there (including gerrit.mediawiki.org if you want to host there and follow guidelines)

I believe you would only use a submodule if $MyExtension were to be deployed with a specific release of MediaWiki proper.

If you want to develop $MyExtension against a specific release of MediaWiki, then after cloning core, checkout the branch you desire. GregRundlett (talk) 19:44, 11 December 2014 (UTC)

Statistics about extensions

Hi, I collected some statistics about the number of extensions (various figures from different sources) and their quality (mainly using categories here on MW.org). Are these statistics interesting from your point of view? if so, some script could be written to automate the process.

Do you see other figures, which could be interesting? I have some idea that the number of extensions with automated tests would be interesting (it’s a sign of very good health for an extension to have such tests), but I don’t think there is an easy way to create this number. A further step could then to have the number of extensions, which pass (e.g.) 95% of automated tests with MediaWiki last version. ~ Seb35 [^_^] 16:50, 4 March 2015 (UTC)

Very interesting; thanks Sébastien!

I have no use for these numbers (but then again WMF or MW.org might have a use,) but they are interesting. Almost 150 extensions used on WMF production sites - wow! I'm glad to see such a thorough overview of the extension landscape. Daniel Renfro 18:28, 5 March 2015 (UTC)

What happens after i join?

i clicked join on this page, and added my name. Does that trigger any further action besides adding my name to this page? What's next?

thx Johnywhy (talk) 21:58, 21 March 2018 (UTC)

Ask new extension into frwiki

Hello, where can I ask an extension be installed into frwiki with the localsettings.php ? I'd like that one https://www.mediawiki.org/wiki/Extension:MobileDetect Thanks Bouzinac (talk) 09:27, 29 August 2020 (UTC)

see meta:Requesting wiki configuration changes. that extension would also need to meet requirements to be deployed since it's not present on any Wikimedia project Taavi (talk!) 09:54, 29 August 2020 (UTC)

Cascades of Extension documentation?

At each stage of creation for a new/updated extension, documentation is created. Then a derivative is recreated at the next stage. The recursive documentation burden could be relieved with a cascade of documentation automation.

With documentation built into the source code in a GitHub Pull Request for an extension, a tool like Sphinx can generate a GitHub readme.md markdown document.

The GitHub extension for MediaWiki can reformat that readme.md for inclusion in MediaWiki. (or use the https://github.com/ProfessionalWiki/ExternalContent)

You'd want something like the MediaWiki template:extension to auto populate and insert into the a reconstituted Sphinx-generated readme.md content.

For our MediWiki documentation site... that was established in March 2007... we also want to integrate MantisBT bug management extension and the Discourse forum for support. (But updates to our site for the necessary Lua prerequisites have been... less than successful. So we use a more simplistic pre-Lua template.)

The documentation ecology is being further integrated with a extension to Discourse that auto-posts back to Pull Request threaded messages.

But all of this would be predicated on initial code having some internal documentation & the Pull Request submission triggering a cascade of documentation creation/synchronization. So I suppose it all start with the Extension API documentation.

An integrated look at flowing documentation through extension evolution should be outlined (if not explicitly defined, streamlined or automated) in this discussion: "blue sky" idea for an "extension" is floated, idea formally proposed, requirements specification, design, proof of concept, alpha test, revision, beta test, installation docs, user docs, public release, support, bugs & enhancements, incremental release cycle, obsolescence, retirement, archiving.

Much of the documentation should only be written once. But if there isn't a What to cascade the data, it may be written at each stage... creating an unbearable (and all-too-often, dodged) burden. BAMaustin (talk) 02:18, 22 December 2021 (UTC)

Mark this very wiki project as historical

Pages like https://www.mediawiki.org/wiki/Project:WikiProject_Extensions and https://www.mediawiki.org/wiki/Project:WikiProject_SysAdmins seem to be old, inactive, unmaintained places with outdated information (e.g. colliding workflows from 10 years ago about "extension review"). However there is no obvious sign of that, so readers who end up on these pages might be misled. Is my impression incorrect? If not, does anyone have thoughts how to proceed in such cases? Add a "historical" template? Redirect? (Heads up to @Varnent as the original author.) AKlapper (WMF) (talk) 17:59, 19 January 2022 (UTC)

No reply; marked as historical in 49 edits; more info in phab:T301984. AKlapper (WMF) (talk) 14:35, 17 February 2022 (UTC)