I attempted a fix on an extension, but my fix did not seem to work. Any suggestions?
|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.
I attempted a fix on an extension, but my fix did not seem to work. Any suggestions?
Be able to show the document with, for all deferences with the previous version, another background. Easier to see that all the modification and more clear . Helpful if we use a Wiki for ISO documents.
For example we have a "process description" for our employee and we make some change in the process (just changing some sentences.
Actually, we have to inform all our employee that this process has change and they have to read it completely.
The best way is to highlight automatically the differences between the actual and the previous version.
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?
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:
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)
What would your definition of "some other website" be? Would PayPal be sufficient? Or are we thinking of a more in-depth donation page?
WMF should handle donations, and it should dole out funding to coordinate extension maintenance. If I want to toss $10 into the fund from time to time, I don't have to worry about whether it's going to help keep my favorite extensions maintained, if WMF makes that a priority.
MediaWiki has an ecosystem of extensions that WMF does not use - but every member of an ecosystem is vital to the health of the entire ecosystem. WMF needs to take the lead, and can solicit donations on behalf of extension authors, who WMF can reward for keeping their extensions up-to-date and bug-free.
If such a program turns out to be successful, WMF may want to consider having a staff member dedicated to coordinating maintenance of extensions. This WikiProject is a step in the right direction, and makes me feel confident that the WMF is interested in dealing with this issue.
Much of that "ecosystem of extensions that WMF does not use" are merely fragments of code kludged together because the operator of an individual wiki needed something to perform a particular task on that one site. Unless we're dealing with commercial for-profit entities (for instance, wikitravel) authors usually have been willing to divulge the source code for any extensions being added onto MediaWiki on the off-chance they will be useful to someone else.
Sadly, much of that code is not actively maintained as often the authors aren't still around. This wouldn't be such an issue were it not for changes to core MediaWiki code which affect extensions ($wgMessageCache going away in MW 1.18+, for instance, broke extensions which had used it to add localisable strings in some now-obsolete manner).
I'm not sure if soliciting donations is going to help - unless the idea is to use them to pay someone else to take abandonware extensions, determine which are useful, bring them up to MediaWiki 1.18-1.20 standards and check them into SVN. Even then, to determine what of this mess of two thousand extensions is worthwhile would be no small task - many are either obsolete or simply duplicative of other extensions already in version control.
I don't agree with the idea of having paid WMF staff members take responsibility for a huge base of extensions which WMF has no intention of ever deploying on its wikis. That would lead to donated funds being used to subsidise non-WMF efforts such as Wikia and other for-profit wiki-farms, something which is outside its 501(c)3 charitable mandate.
"I'm not sure if soliciting donations is going to help - unless the idea is to use them to pay someone else to take abandonware extensions, determine which are useful, bring them up to MediaWiki 1.18-1.20 standards and check them into SVN. Even then, to determine what of this mess of two thousand extensions is worthwhile would be no small task - many are either obsolete or simply duplicative of other extensions already in version control."
"I don't agree with the idea of having paid WMF staff members take responsibility for a huge base of extensions which WMF has no intention of ever deploying on its wikis. That would lead to donated funds being used to subsidise non-WMF efforts such as Wikia and other for-profit wiki-farms, something which is outside its 501(c)3 charitable mandate."
I tend to agree that Wikimedia doling out money to random extension developers is not a good idea. There are many extensions that are not even remotely useful to Wikimedia websites, many that are not very well executed (just look at extensions with security issue templates). Now if some sort of third party (or heck even a "chapter" like organization interested in supported wiki-related activities) wanted to manage such a fund, I think that might work better, but this sort of thing is out of the scope of the wmf (imho)
Hmm, what if instead of money, there were some other sort of recognition? Prestige can be worth more than money, anyway. The "chapter" idea is interesting. We could call it the WMF "Order of Extensionhoodliness". Other than thinking up important-sounding titles for ourselves, what would such an order or chapter do?
I'm not sure a non-money substitute would really address this specific issue.
The chapter idea is..interesting..but sounds more complicated than necessary.
I can understand and certainly respect that perspective, but I also think there's been valid points about the value third-party extension developers bring to WMF. It's true that not every extension developer is a gem, but neither is every enWP admin (and editors..well....) or recipient of volunteer (participation, etc.) grants. Maybe we should do a study so we can cite a stat here, but I suspect a reasonable percentage are lured because of third-party projects. I suspect that will only increase as companies like Microsoft begin to further implement MediaWiki as a package offered in their cloud server solutions.
Plus, you could argue, that the above about poor maintenance and lack of quality could in part be resolved by things like grants. Money is a great incentive to encourage folks to step up their game and bring more to the table. :)
Generally, WMF now has grants to support a number of initiatives. I think asking for one that supports something developer specific isn't unreasonable - and this seems like a good place that wouldn't overwhelm the core dev team.
All of that said, I'm still on the fence about what would be a wise way to approach this...
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:
I'm opposed to #2 because:
...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:
>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)
I'm a big fan of starting small. That sounds both small, and widely beneficial for all extensions, and their users. It allows WMF to fulfill an leadership role, while doing only the minimum necessary to be effective. Great idea!
I test extensions pretty regularly, and find problems all the time. One angle we could come at this problem is by requiring some sort of connection between the extension page and the bugzilla page for its list of bugs. A few extension developers are annoyed by that, but I don't think its too much to ask them to tolerate if they want a cooperative relationship with WMF.
As an example, Extension:StringFunctions has some prominent notices that could be templatized to warn of any bugs that cause a schism between the promise of the extension, and what it actually delivers. Potential users should be aware of those things to minimize their time wasted trying extensions that won't work for them. That will have the effect of congealing the "community" around well-maintained extensions in a focused manner, while also helping the more adventurous people find interesting extensions that are worthy of consideration for their attention to bring it back up to some level of acceptable quality, in relation to its promises.
In dealing with the personal interests of the developer, there are 2 things that the WMF needs to take sides on:
Both of those are required in order to align an extension with the cooperative interests of the WMF community. In particular, they are required to make it possible to BEGIN the process of developing a community around the extensions that are interested and ALLOWED to find ways to ensure they're meeting the needs of WMF stakeholders, according to the WMF's public charity mission.
Deleting extension documentation on public WMF sites, in favor of links to private sites, is contrary to the goals of the WMF in cultivating the extension community for public benefit, and should be rejected as a matter of policy. Deleting information about flaws of the extension, especially when they cause the extension to not meet the proclaimed promise, should be rejected as a matter of policy.
Surely that's already the case. We don't delete extensions against the authors will unless there is serious issues (I'm not aware of that ever happening). Of course in cases where the primary documentation is elsewhere (say like with SMW), it does not make sense to duplicate the documentation here, where it will just get out of date. (In the case where the extension author wants nothing to do with us, I think it would be polite to delete the extension page, particularly if no one else is really depending on it. right to leave and all) I also can't imagine any case where we would allow an extension author to make misleading claims about the extension.
I had SMW in mind specifically when writing up those two suggested policies. The SMW site is poorly maintained, and the people involved actively obstruct attempts to maintain documentation here. That's why people have to go to my user page to find out about critical bugs and undocumented changes. The problem is not that no one will maintain it here - the problem is that external interests have dictated that no one will maintain it here. But, this is not their private territory, and the official policies should stand behind that.
Without the policies set out above, I have no interest in participating beyond my own user page. The acrimony is not worth it. You end up on the SMW shitlist if you try to challenge how they handle documentation. Who is that good for? In fact, just thinking about it makes me want to go do something else...
Let me know when the policies are in place, and I'll come back. I want nothing to do with it when it leads to WMF-supported confrontation.
Noting incompatibility should be a part of an all-out extension review. My hope is we can organize one after the page drive is completed and the first step of labeling and archiving extensions occurs. A review and test of each extension's code - as well as uploading extensions from wikicode to git - would be a great MW-wide effort.
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"?
Something definitely has to be done. Occasionally, an extension will do the job better than the built in function. For example, the spam regex extension allows permitted users to add words and phrases that cannot be used, rather than just the system administrator. It also works better since I think the $wgSpamRegex eventually fails if you add too much to it.
What's wrong with the obsolete template used on some extension pages?
Such extensions are also totally unnecessary with the ability to block users, log them out, change login and registration information, and their username.
Lots of extensions implement ideas that were rejected from core for being (to put it bluntly) a bad idea. That's one of the main reasons for having extensions, so if people don't like a decision made in core mediawiki, they can do their own thing without totally forking mediawiki. (That said, some extension ideas are worst then others, and some are downright scary. But even then I think we should still allow them, just have warnings on the page)
In regards to SMW: I am not familiar with SMW, or its documentation. However I could certainly understand where they are coming from not wanting multiple sets of documentation, especially if the multiple sets look "official". Having multiple sets of duplicate documentation is a pain to maintain (so usually one of the copies is significantly out of date), and if they both look official, the maintainer of the extension is going to be responsible for both of them. However, with that said, I think it would be perfectly acceptable to have a link from the extension description page, to some subpage that has community made (by which i mean this wiki's community, not the extension's community) documentation, provided it clearly states that it is not official documentation of the extension.
I'll tell you what's wrong: I didn't know about it. There isn't any leadership, and thus organization (yet!). Every extension page should link back to the extensions project, with a directory of possible things that can be done to help, so everyone will find out what they can do when they discover a problem.
About SMW: That's where they'll SAY they're coming from, but really, it's something else. They'll throw a tantrum if I put a link to my user page documentation. They've even deleted things like that with no warning. I had to go find another admin to restore it for me.
In fact, I think you have it completely backwards. BACKWARDS BACKWARDS BACKWARDS. WMF-maintained documentation shouldn't be shuffled away with links to obscure user pages and subpages. Instead, that link should be for the offsite official documentation, and no more interference than that should be imposed on WMF-maintained documentation.
With that said, I don't give a poop what happens to it, until there is a policy in place that is in accordance with WMF's public mission, and the WMF is willing to use it to forcefully challenge anyone abusing it. I'm not convinced the WMF is even hearing me, and I'm not interested in being shat on as the sole challenger.
Honestly, I'm pretty spooked that you would suggest a higher priority be given to external interests, as a matter of principle. I understand who the developers are, and I understand that they do what they can to humiliate and isolate anyone that disagrees with them, or wishes to contribute in a manner they disapprove of.
Every time I have tried to contribute to their goals, they have reacted with provocative hostility. Why? I don't know. My best guess is they have commercial interests that I accidentally threatened with my interests in documentation writing. I don't have any problem with their commercial interests - I'm a capitalist pig, after all. But, I do have a problem with a business model that relies on alienation.
I'm not even sure that's what's going on - The best I can do is speculate, but the one thing that is certain, anyone who has tried to contribute in the spirit of public service has been greeted with teeth and claws, and I'm not the only one who has had that experience. So, the question is, what is WMF's mission? Is it to aid the suppression of documentation in favor of external private consultants, or WhateverTF it is that motivates all the arrogance and insolence?
If nothing changes, the answer is yes, and you can find me over at my user page, far away from these kinds of problems. I do not come here to be insulted, stress, or frustrated. I am not in a position to successfully challenge these kinds of problems, without the backing of the WMF.
That's it. That's all I've got to say. What do you think of that, Bawolff? Is this something you can change or have some influence in changing?
I definitely support having subpages of extensions where community members can offer advice and their own support and experience with installing extensions. One extension that I would really like support with installing is Extension:Farmer. The directions are very poor and rely heavily on a detailed knowledge. I plan to setup a private wiki farm to use as a way of creating new wikis quickly and with all the extensions and configurations setup.
Subpages with sysadmin and devoloper advice from folks not directly involved with the extension is an interesting idea. Is there a feeling this would be unique enough from the talk page uses?
You know, after giving this more thought, I've changed my mind just a little bit. User page documentation is not a bad thing, and would not risk cluttering the extension docs if we decided to make subpages a free-for-all. The question boils down to: who decides what will be documented, and what won't?
For example, plenty of how-to documents are technically wrong, and may be objectionable to a technically-minded extension developer, but they would still be helpful as very speedy introductions to productively using something.
As we're already aware, sometimes it's not going to work to always let the extension developers assert "ownership" of their extension's docs. We have the Cite extension on mediawiki.org, right? Perhaps we can formulate a policy that says deletion of at lesat vaguely relevant further information on user pages, linked-to using wiki links or cites (whichever the developer prefers), is not normally acceptable, even if it isn't 100% pedantically accurate, or even mostly wrong.
Nobody starts out getting everything right - we need to give people a chance to start, without scolding them for making mistakes, and without sidelining them to obscurity. That allows anyone to unobtrusively add their notes and links to their user page documentation, without implying that it is "official" or representative of the extension developer's advice.
Does that sound workable? The extension developer (or anyone else) would be free to edit the note to say why they disagree with it, but the information would still be there in case anyone found it useful. From there, the usual editing policies dealing with good faith, vandalism, etc would apply to filter out abuses of a liberal documentation policy like that, but I don't foresee much potential for problems, so I suppose we don't really need to spend much effort thinking it over. The only people even interested in this are people with good intentions, and something valuable to add.
What do you think?
I'll see if I can try and summarize some folks thoughts here and then get some feedback on what WMF could actually do before we weed through them more. It does appear to me that there's value in having this discussion.
I would want to create Extension:LiveRC, that means completely rewrite LiveRC as a PHP extension (I listed some advantages to do so in the extension page).
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?
Yeah, I'm just worried that it is yet another thing to keep track of. I'll start re-compiling my skeletons, maybe in a week or so I'll have them together, ready for upload. (Things are hectic around here!)
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)
Dear Daniel Renfro, My skeleltal extensions fall out quickly because the mafia kills women faster than you can tweet a 'Nobel'!. Could you or Rutgers staff members on this particular line (and/or others?), ... please get off my cloud (OR Head!). I have reason to believe from this current prose, and other similar entriese, that my head is being accessed illegally and I currently have a Court Order against it! No.283, is not the number on a house , ya know, its a conical convenience for an inhumane heathen! So, if yoou could inform your 'upper curst... I mean crust Staff', or my current entry and issue, maybe I could have some peace and quiet and some personal independence to excel as a individual, like everyone else. Thank you for your inspirational entry! Yuck, Yuck, Yuck.... Sincerely Disgruntled, Dawn T. Kish.2/22/15. Sun. 4:40pm.
i was pain stakingly trawling through the extensions when I came upon this category Category:Interwiki_extensions. I think it's pure awesomeness. we should have one of these one liner review tables at the top of each category
Hello! I tried to print out the PDF entry on the topic of the week (in German). But unfortunately no graphics or tables were printed.
What would be good is if the integrated links would also be included in the PDF.
Is there a possibility that these features are included?
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.