Project talk:WikiProject Extensions

Home

Discussion

Participants

Projects

Ideas & Requests

Workshops

Barnstars

Templates

This is a place to share and brainstorm ideas specifically related to WikiProject Extensions and its projects. Please use the support desk for any MediaWiki software related help inquiries and the current issues noticeboard for discussing issues related to MediaWiki.org site.

Previous page history was archived for backup purposes at Project talk:WikiProject Extensions/LQT Archive 1 on 2015-07-10.

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

No reply; marked as historical in 49 edits; more info in phab:T301984.

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.

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

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

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

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.

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.

This post was posted by Qgil-WMF, but signed as Qgil.

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.

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.

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,

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

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.

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

See Project:Support desk.

This post was posted by Qgil-WMF, but signed as Qgil.

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