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.

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.

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

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.

I think everyone is aware of the problems. I'm curious what ideas folks have for solutions.  :)

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.

Is there a template for extensions needing documentation? Someone created a bug requesting improved documentation and I'm sending them here.

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

• {{CodeReviewNeeded}}
• {{Fixme}}

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?

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?

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"?

Yes, all templates referring to SVN are being updated in the next couple of weeks.

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

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.