Project:WikiProject Extensions/Ideas

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

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.

It would be great to be able to setup petitions through an extension that allows accepting signatures and tracking basic demographics from within MediaWiki.

This would allow mediawiki based sites to also start some advocacy work.

The title of this might be a little weird, but I can't think of a good title. The idea, is for a way to say effectively "Show me the articles that are both in Category A and Category B". Currently, this is possible with DPL, but it's not possible if you want to just link somebody this on the fly.

This is doable if you use CirrusSearch - search for:

 deepcat:"Used on Wikimedia" deepcat:"All skins"

You can then link to the search page.

Would it be possible to have an extension that compares, sorts, ranks, etc. pages by their "Post-expand include size". Maintenance scripts also work.

One of the wikis I host have many large pages, out of 8k overall, but don't want to go to each page in the wiki to see which ones are large.

The "Category:Pages where template include size is exceeded" and related stuff isn't returning anything.

Hello,

I was looking around a bit for extensions that help embedding 3D-models on a mediawiki-page and I didn´t really find a lot.

so I looked a bit further and I found an interesting thing: http://3dhop.net/.

I read a bit how to use it and I think, it might be just great to transform 3dhop into an mediawiki-extension.

Unfortunately I don´t have the skills to do that on my own and was wondering if somebody from the community might help.

I could really use that for my mediawiki-page and probably many users would be happy about it.

Any advise how to make that happen?

Thanks in advance

König Sausebraus

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.

I attempted a fix on an extension, but my fix did not seem to work. Any suggestions?

Details:

https://phabricator.wikimedia.org/T190343

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)

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

All correct. The easiest way to figure out which extensions are worth the trouble is by allowing people to donate for their maintenance. The problem appears huge until you give control back to the WMF's stakeholders, and let them decide what is worth maintaining. Obviously, the WMF can pick a few too.

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

That is a valid concern, but I don't think it inevitably leads to that conclusion. Firstly, MediaWiki is a WMF effort, including MediaWiki extensions. Secondly, for-profit users of MediaWiki are among the most generous supporters of WMF, MediaWiki, and extensions. Many of them recognize the long term benefits of supporting the WMF, even when there's no immediate benefit for them in the short term by doing that.

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.

"..but this sort of thing is out of the scope of the wmf (imho)"

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

• Allowing links to some approved or generally accepted list of "known" payment processors (PayPal, Google Checkout, etc.) that could remove WMF from liability and provide some sense of quality control that we're not sending you to Anonymous's gate..
• Increased effort on MW.org to WMF fundraise and then 1-2 developer specific grants (or just the grants and no fundraising..)
• Supported effort to solicit corporate sponsors for developer funds (chapter? another c3 sounds like a lot of work..)
• Just play dumb to the whole thing and consider a buyer be warned essay should they start popping up?
• Wikipage that coordinates donor/developer connections
• Really quality (and regularly scheduled) "contests" with prizes like gift cards, MacBooks, etc. (sponsored?)
  • Turn into a popularity/vanity contest?
• Do something crazy like write up a developers' bill of rights and just attempt to, as a devo community, decree they get links if they so need them  :)
  • As if we could get the devo community to agree on what to name a wikipage to house a bill of rights..let alone the content.. ;)

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.

This post was posted by Lieutenant S. Reznov, but signed as Inquisitor Ehrenstein.

It looks like we've reasoned our way down to 2 different options:

1. 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:
     1. Popularity (whatever helps people use MediaWiki).
     2. Present or future potential public benefit.
     3. 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).
2. 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:

1. It makes WMF a defacto free hosting provider for private interests.
2. It makes WMF a defacto free advertising platform for private interests.
3. It causes confusion amongst WMF stakeholders about how their contributions will be accounted for (public accounting vs. no accounting).
4. It causes confusion amongst WMF stakeholders about who their contributions will be applied to benefit (public interests vs. private interests).
5. 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:

1. Some way to differentiate maintained extensions from unmaintained extensions.
2. Notifying extension authors that their extension is not compatible with an upcoming version of MediaWiki.
3. 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)

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:

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

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.

I agree. I once tried to post important information to make it far easier to install an extension without guesswork, and all my attempts were reverted.

This post was posted by Lieutenant S. Reznov, but signed as Inquisitor Ehrenstein.

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.

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.

This post was posted by Lieutenant S. Reznov, but signed as Inquisitor Ehrenstein.

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.

This post was posted by Lieutenant S. Reznov, but signed as Inquisitor Ehrenstein.

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.

This post was posted by Lieutenant S. Reznov, but signed as Inquisitor Ehrenstein.

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.

Antje

Hello,

I am the main developer of LiveRC, a javascript gadget used for countervandalism providing real time recent changes as well as several related features.

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

I'm OK with JavaScript and CSS, and I know quite well PHP and Mediawiki, but probably not enough to make the whole extension on my own. So I'm looking for help from experienced developpers, at least to do a beta version.

Thank you.

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.