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. |
 |
- [History↑]
Contents
| Thread title | Replies | Last modified |
|---|---|---|
| Convert this to a MediaWiki Group? | 0 | 22:55, 13 December 2012 |
| Concerning; Conflicts of Project Management | 0 | 00:51, 11 August 2012 |
| First thought | 3 | 00:48, 30 July 2012 |
| Template for Extensions needing documentation | 1 | 20:19, 7 March 2012 |
| template - extension code in wiki | 5 | 03:57, 1 March 2012 |
| Extension maintenance | 5 | 21:23, 29 February 2012 |
Hi, now we have MediaWiki Groups and this WikiProject is a good candidate to become one. What do you think?
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.
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"?
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.
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.
"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?
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..
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).
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.
