Project:WikiProject Extensions/Ideas
| Home | Discussion | Participants | Projects | Ideas & Requests | Workshops | Barnstars | Templates |
| This is a place to share and brainstorm ideas on how to improve MediaWiki, MediaWiki.org and other related resources for extension developers. 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 |
|---|---|---|
| Spoiler Extension | 0 | 00:57, 6 May 2013 |
| Extension request: XMPP Watchlist | 2 | 11:19, 12 November 2012 |
| Seperation of Weclome page from Main Page | 0 | 05:43, 1 April 2012 |
| Link within Extension to allow developers to solicit donations | 32 | 02:59, 30 March 2012 |
| Extensions with no license | 6 | 02:40, 30 March 2012 |
| Zoomify inclusion | 1 | 22:52, 22 March 2012 |
| integrate wiki twitter SNS blog anonymous BBS by mediawiki | 2 | 07:20, 18 March 2012 |
| An extension migration guide? | 1 | 01:51, 21 February 2012 |
| Skeleton Extensions | 3 | 08:08, 5 February 2012 |
| A new/better syntax highlighter to be on par with WP. | 1 | 20:43, 5 January 2012 |
A few friends and I felt it would be a cool idea to create a tag extension that filters content based on season and episode preferences of a user for tv show wikis. Is anything like this already?
I've toying around with it here: https://github.com/litex2x/SpoilerFree
I was searching for a way to make the process of following changes in watchlisted articles on Wikipedia less painful, and I came across several pages discussing XMPP relay for "Recent Changes" feature.
The feature I want is an XMPP integration of Watchlist, which would present an alternative to periodic polling of watchlist (via web interface or API). The resulting extension should send users (individually, not to chat rooms) a message for each change that would be displayed in user's watchlist.
Though something functionally similar can be achieved with the help of WatchlistBot, an extension that would push notifications on the server side should be much more efficient performance-wise.
Sorry if I addressed the wrong forum. I'm new to this wiki and I don't know its layout, so I would appreciate if one points me towards a right place to file this request.
As you said, this is not a new idea. The most recent development on XMPP-based notifications is probably the work being done on the Echo project. I'm not working on it, but recently came across this page. Maybe it will be of some help.
In wiki their should be facility or extension to develop welcome page instead of main page only. Can anybody write extension for it?
It was brought up in #MediaWiki if it would be possible for developers to add a PayPal or similar "Donate" link to support their work. Specifically it was mentioned that Wordpress and Drupal permit this (although I can't speak to those details personally).
Here are some questions that I think will need to be addressed:
1. Does the Wikimedia Foundation have any policy, stance or legal considerations regarding this request?
2. Any thoughts on how we should proceed with it? Any preference on if a policy is set on how they could be collected (what services would be permitted, etc.)?
3. Is direct donations to developers the best approach? My understanding is they generate little revenue and I wonder if it will cause confusion with other WMF donation soliciting efforts Rather than allow developers to collect donations directly, perhaps the Foundation could solicit for donations to support developer efforts within each extension's page on MediaWiki.org. To fulfill that promise, then provide a new "participant grant" style fund that extension developers could apply to. Another option, although I see this as a supplemental to do anyway, is a revved up form of w:Wikipedia:Bounty board.
Geoff Brigham (WMF's GC) offered the following for consideration, with the disclaimer that it's not legal advice:
- 1. There would be a need to put in some controls on receiving payments. For example, in whose name are the donations made (and is that person willing to accept responsibility and potential liability)? How is distribution of the money decided? Where is the money kept? How do you prevent misapplication of funds? How do you ensure transparency?
- 2. To do this right, you would need to confirm whether state regulations required any type of registration for this type of "passive" fundraising. Maybe not, but you would need to confirm.
- 3. To do this right, you should have systems to protect donor data, including a privacy policy, security around the data, etc. If there is a data leak, you could be liable, so you may want to consider insurance. The risk would be minimal however if only Paypal - not you - saw the data.
My view: In general, I find direct PayPal links a bit iffy due to the issues around accountability. Is it the right person? Are they going to spend the money on working on that extension? Are donors going to assume that WMF did some degree of vetting? Etc. With disclaimers it might be manageable. It would be a lot cleaner if we're just linking to a trusted non-profit (e.g. OpenStreetMap) where that's possible.
If a developer wants to work on an extension that has relevance to WMF's mission, applying for a grant (even as an individual) through WMF's grants program is definitely a possibility, as well. I don't think there are many existing examples of that, but if someone put in an application, I'm sure we'd give it fair consideration.
I like the idea of more use by extension developers of WMF's grants program. It does beg the question about extensions which may be seen by some as falling outside WMF's mission. I could certainly be wrong, but it doesn't seem clear to me that extensions mostly helping 3rd party wikis would qualify. I suppose that's where a MediaWiki Bounty Board could come in - but I wonder how to help make that effective and interesting for developers.
Any thoughts on if the Foundation might be willing to get involved in supporting extensions that are used primarily (or exclusively) by 3rd party wikis?
Perhaps a two-way version of w:Wikipedia:Reward board where requests could be made both by those seeking an extension and those offering to build one?
Finally, if all of this is done outside of PayPal style direct funding - should (and if so how) this be promoted within extension pages?
Some extensions are intended more for corporate wikis and such, rather than WMF / Wikipedia purposes. Would WMF give grants for such extensions? Either a bounty board or keeping paypal links (but maybe verifying them?) might be more suitable, though grants are great too, if applicable.
If the author of an extension wants to beg for money, couldn't this be better done by placing just a stub of a description on the extension:... page here with a link back to their own site for the rest of the info, download, beg messages or whatever they want to say. That way, the begging takes place on their *own* site and not on bandwidth paid for through WMF. --Carlb 05:36, 14 February 2012 (UTC)
I tend to agree with Carlb, I don't really like the donation links on mw.org for individual authors. Too easy to get confused with general donations. (At most a small note saying this extensions author accepts donations on some other website should be the most on MW.org page imho)
We could possibly have a link to the developer's own Paypal donation page. Example: an extension creator could create a webpage with various Paypal donation buttons to their own account (or the account of an organization they do work for) and post a link to that page on the extension page here.
It looks like we've reasoned our way down to 2 different options:
- WMF DOES take a leadership role in MediaWiki extension development and maintenance:
- All extensions are treated more like a public, community effort, and less like a private project.
- Resources like time and money solicited from the stakeholders of WMF (the public) go directly to, or through, WMF.
- Extensions receive more, or less leadership from the WMF, depending on "qualifying" factors. "Qualifying" factors could include:
- Popularity (whatever helps people use MediaWiki).
- Present or future potential public benefit.
- Present or future potential to be used by WMF, other educational, public-service, or research organizations, or any of their stakeholders (this leads back to popularity again).
- WMF DOES NOT take a leadership role in MediaWiki extension development and maintenance:
- All extensions except those used by WMF are treated as individual pet projects.
- Resources like time and money solicited from the stakeholders of WMF (the public) go directly to individuals.
I'm opposed to #2 because:
- It makes WMF a defacto free hosting provider for private interests.
- It makes WMF a defacto free advertising platform for private interests.
- It causes confusion amongst WMF stakeholders about how their contributions will be accounted for (public accounting vs. no accounting).
- It causes confusion amongst WMF stakeholders about who their contributions will be applied to benefit (public interests vs. private interests).
- It causes confusion amongst WMF stakeholders about how their contributions will be used (publicly visible projects vs. private weekend pizza party).
...and I don't think I need to bother pointing out any more worms in the can, you get the point. I see a fork in the road where either WMF takes a leadership role, or it should at most just leave things the way they are. Off the top of my head, I don't see any clear way it can support private development by mixing public resources with private resources, without also creating a lot of unanswerable questions that could lead to reevaluation of WMF's 501(c)3 status.
I don't think anyone is in favor of simply leaving things the way they are. So, I'm in favor option #1, where WMF takes a leadership role.
I'm in favour of leaving things the way they are :P or at the very least a middle ground.
Some extensions are simply put bad ideas. Some extensions have goals opposite of wmf's goals. Some extensions are fine doing there own thing, and don't need the foundations help. There are literally thousands of extensions, wmf can't take a leadership role for all of them.
It could perhaps take a larger leadership role in more extensions, but it wouldn't be able to do it for all extensions, unless we started deleting extensions. (I suppose just limiting that to extensions in our svn would be reasonable though)
It seems to me that the MediaWiki "community" should start taking a more leadership role in extensions, before the WMF starts taking a role. Even if its just to work out what a "leadership role" would look like.
I'm not really sure of this, but of all those thousands of extensions, I would guess there's maybe 50 to 100 that could be called "significant". That narrows the scope quite a lot, but even without that narrowing, a "leadership role" could be defined in a way that achieves something useful for all extensions. I agree about the community needing to be part of this. Simply categorizing-away the obsolete and abandoned extensions is a start. What do we want? Here's some ideas:
- Some way to differentiate maintained extensions from unmaintained extensions.
- Notifying extension authors that their extension is not compatible with an upcoming version of MediaWiki.
- Establishing ongoing, coordinated dialog to identify needs and ways to efficiently address them.
Any others?
>Notifying extension authors that their extension is not compatible with an upcoming version of MediaWiki.
This would also be useful for the average end user. Even some sort of automated smoke test (Even if its just add extension to LocalSettings.php and if its a parser tag maybe test parsing one page with the tag on) just to make sure mediawiki doesn't fail in a ball of exceptions/fatal errors) would be helpful to end user if results were posted to the extensions page.
Noticing an extension doesn't even remotely work on current mediawiki is also a good metric for if its abandoned (albeit with lots of false negatives)
Bawolff wrote:
I'm in favour of leaving things the way they are :P or at the very least a middle ground.
Some extensions are simply put bad ideas. Some extensions have goals opposite of wmf's goals. Some extensions are fine doing there own thing, and don't need the foundations help. There are literally thousands of extensions, wmf can't take a leadership role for all of them. It could perhaps take a larger leadership role in more extensions, but it wouldn't be able to do it for all extensions, unless we started deleting extensions. (I suppose just limiting that to extensions in our svn would be reasonable though) It seems to me that the MediaWiki "community" should start taking a more leadership role in extensions, before the WMF starts taking a role. Even if its just to work out what a "leadership role" would look like.
I think that the community should definitely take a more active role. However, I think that WMF could also encourage it and also maybe take a role in overseeing the extensions on MW.org. For example, there's a lot of out of date extensions that don't work and don't seem to have any plans to be updated, and a significant number of extensions that are actually harmful to the wiki, such as ones for deleting users. Such extensions are also totally unnecessary with the ability to block users, log them out, change login and registration information, and their username.
It would be nice if we didn't have to wade through a few thousand obsolete extensions, if the functionality has been added to MediaWiki. I'm not sure what exactly could be done to fix that, though. I don't think deleting them is a judgment call that should be made yet. Instead, maybe we could recategorize them with a prefix of "OBSOLETE"?
Should we be actively archiving extensions with no license provided? Does it present a copyright problem similar to the ones faced by Wikimedia Commons?
I'd hesitate to extend Wikimedia Commons restrictions on licensing to other projects; do keep in mind that even material which is perfectly valid in Wikipedia itself (such as the logo of a company appearing on the encyclopaedia page about that company, proprietary but fair use) is banned from Commons.
There are a few cases in which what appears to be an extension is merely a MediaWiki-like wrapper placed around some existing third-party API. This is true of extensions to check Akismet (a Wordpress spambot blacklist) or other lists to check spambots. The externally-supplied API isn't ours to force some arbitrary license onto, however much some contributors here seem to swear by commercial versions of licences like GPL, GFDL, CC-BY-SA which serve to feed your free content to every scraper site on the planet to be mangled and plastered with ads.
This already raises an issue with the current {{extension code in wiki}} crusade in that we cannot check the whole package (extension wrapper + third-party base API) into Git/SVN/whatever as the API isn't ours to re-license. We have every right to call the API from our open-source code (that's what it's there for) but it might not explicitly specify any license terms beyond that. Either we check in just a wrapper (which is problematic if the originating site stops distributing the API later, leaving just a hollow shell in the Git repository) or we keep these out of the version control system entirely.
Nonetheless, I don't agree that they deserve to be pulled from the site. We are using the third-party API as its authors intended by calling it from our code; most often, that site will link back to us in their FAQ to indicate "this is what you do to get this working on MediaWiki".
If the vague licensing terms (here's a third-party API, possibly as source code, and whomever created it invites you to wrap your code around it but specifies no specific license beyond that) upset you, perhaps the third-party site could be approached about distributing the MediaWiki extension "wrapper" with the API instead of it being hosted here.
Killing good code just because Wikimedia Commons is CC-BY-SA and thinks that specific license should be forced onto every website on the planet is a bit much, though.
I'm not suggesting the two sites are similar or related. I'm asking, from a legal perspective, are the concerns faced by other WMF projects in regards to hosting content with no licensing. Commons is the example that first came to mind, but in general I'm speaking of the issue faced by all the projects WMF hosts - including MW.org.
Not even getting into the topic of should we house it - I'm asking - technically (legally) - are we really able to at all anyway?
Also, I'm not sure what your dig is on the extension in code template. There's no crusade either, lol. This is starting to sound like cabal talk. There are 2-3 new templates being placed in several places. Efforts to help communication with sysadmins I suppose could be seen as a crusade...but I'm still at a lose for why it should be discouraged. :/
Legally? If the source code was posted by the author to the wiki, it can remain on the wiki under whatever licence (GFDL or CC-BY-SA) was in use at the time it was posted.
If you want to move the code elsewhere, then the original license and attribution must be retained. That may mean we have (if not otherwise indicated) bits of programme code under what was intended to be a documentation license - but that's not the same as unlicensed code.
I think the WMF needs to take ownership of anything submitted, and should consider rejecting anything not released that way.
Specifically, anything donated to the WMF should become property of the WMF to release however it chooses. Then, the donator can specify some license they prefer, or inform the WMF that the donation is already infected with a self-propagating license. In the case of license preferences, the WMF can re-release under GPL, BSD, MIT, CC, Public Domain, or all of those, depending on the non-binding wishes of the donator. For things with a self-propagating license, the list of acceptable licenses should be restricted to the ones already widely accepted and understood.
Having license control means the WMF can release according to the maximum public benefit, and it helps to prevent license proliferation. In addition, it allows the WMF to change licenses if some legal issue is imposed that requires it.
I agree with WMF taking ownership of content posted. So by that - could we then just assign GPL to any extensions that don't currently list a license?
I'm not too opposed to GPL licensing, since it's so well understood and widely accepted, but I think it might be better to make it public domain, like we're already doing for Help:Contents documentation that is meant to be planted into every MediaWiki install (if desired). Making unspecified contributions public domain by default:
- Assumes nothing.
- Imposes nothing.
- Can be changed later, if needed.
In short, if a contribution does not come with any specific licensing restrictions, there's no reason impose any. But, with that said, I think just choosing SOMETHING is better than just leaving it an orphan that everyone is afraid to use because it might turn into an intellectual property minefield.
I would like to see a picture zooming tool included. Currently there is only thumbnail, fixed size, full screen or full resolution. A zooming tool would make picture vieweing within the wiki much more practial. Just a suggestion. Schmelzle 10:37, 24 January 2012 (UTC)
Hi Schmelzle, I just created a page for Extension:JBZV, which is based on Zoomify. I've no idea whether or not it works in the most recent versions of MW 1.17 or 1.18.
Social Religious Network System To integrate all project to 1 project. I need this.
If we could debate on wikipedia directry. We can easy to assemble, stuck and classify opinion.
In this way , mediawiki could be represent all web service.
First to make this. I want sort article by timelime. Now I found, tag searchengine.
It can be time feeder like facebook.
Anybody knows extention,sort result by time?
I don't personally - but you may want to try the IRC channels.
I've noticed the interface between MediaWiki and the individual extensions appears not to be stable across revisions. Often, an extension will call some piece of core functionality or access some global which was perfectly valid in the then-current version of MediaWiki only to break once a newer MediaWiki version is released.
These issues tend to affect multiple extensions at once, for instance:
- (1.14) Hook functions *must* return a value. Extensions written for old MW versions suddenly fail with errors if this value is omitted, even though they worked on the original targetted version of MediaWiki.
- (1.18) $wgMessageCache->addMessage(); can no longer be used to create localisable strings in MediaWiki: - this was used in quite a few old extensions from before the (whatever).i18n.php format became common and all are broken as the underlying global no longer exists.
- (1.18) Xml::hidden used to be called from extension code in at least three or four existing extensions. The function is now Html::hidden and any code still looking for Xml::hidden is breaking.
- (proposed for 1.20) Removal of wfLoadExtensionMessages(), done here for extensions in SVN, but with no means to notify developers of other extensions that the interface has once again been changed. This may mean any new extension version that works for MW1.20-1.21+ doesn't work on MW1.15 or earlier due to lack of a consistent interface design.
At the moment, the issue is only being addressed one extension at a time, only if someone is actively maintaining the extension and (for the most part) only after things break. There is no constant, clearly-defined API to say "extensions coded to use this specific interface to MediaWiki will continue to work on all new versions"; globals may be renamed or go away entirely, callback functions may change and (because MW as deployed as source-code, not compiled) an extension author may be calling just about anything in the core code at any time.
I'd suspect there is some level of indifference on both sides - developers of core MediaWiki code and extension authors - until things break.
From the MW developer side, the extensions are often perceived as badly-written code and no surprise is expressed when things break.
The extension authors, on the other hand, likely are not following every revision posted to trunk as they merely created some small fragment of code to do a specific task on sites they are hosting - if the author is even still around. Most do not presume that an extension which works on the current MW version will be broken by a change to core code in subsequent MediaWiki versions, nor do they presume there to be much or anything that can be done to prevent this from happening.
Annoyingly, the same migration issues crop up repeatedly... but with different extensions. Each broken extension is handled (or neglected) as a separate incident, usually as a separate attempt to either debug the one among a batch of affected extensions or replace it with an equivalent. If there were one master list of changes which had broken (or will break) one or more extensions, it would be possible for someone dealing with a broken extension after upgrade to look at that guide, see "$wgMessageCache went away in 1.18 and everything using it broke, here are the alternatives to fix your extension..." without having to go through the entire revision history of MediaWiki (most of which is bug fixes and enhancements, not changes to the interface to break old extensions) to try to guess what went wrong.
At one time I kept a folder full of what I called skeleton extensions These were stub-like php files which outlined the basics of each of the types of extensions, for use when I wanted to create a new one. This came in handy, but quickly fell out of date with best-practices (around 1.16.0 if I remember.) Since then I just go to the appropriate page for the extension and follow the directions (typically copy-and-pasting code into my editor.)
I wonder if there is any interest in keeping some of these skeleton extensions around, or maybe writing a maintenance script that would produce a skeleton?
I think that's a good idea. Perhaps we could organize or keep a list of developers that would help review them before each release for needed tweaks?
I think your referring to the examples directory of the extension repo - http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/examples/ (which are probably a little dated - otoh the examples in the wiki are also a little dated)
alexgorbatchev's syntax highlighter as a media wiki extension http://alexgorbatchev.com/SyntaxHighlighter/
How would you see this differing from Extension:SyntaxHighlight GeSHi?
