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