Link within [[Template:Extension|Extension]] to allow developers to solicit donations
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.
>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:
- 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.
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?