Topic on Talk:Third-party MediaWiki users discussion

If you have developed something in-house or found a workaround to a common problem, please share it with the community. This would include advice, fixes, extensions, maintained bundles, scripts, etc.

Why share?

• Others won't have to reinvent the wheel.
• Your suggestion might be integrated in core or as an extension, helping with maintenance and compatibility issues.
• You can get help from the community to improve your improvement.

How to share? You can find resources on sharing your work at the pages below. Also, you can post about your recommendations or improvement here and be directed to the right place to go to.

• How to contribute
• Manual:Developing extensions
• Submit your changes

This post was posted by 78.90.26.139, but signed as Mitevam.

I don't think that this will work this way. You say "Guys, please share your experience and your software" and guys start to share all they have. Our company understand the importance of sharing as much code as we can but we don't do that yet.

Let's think why we should do that:

1. the extension that is available on mw.org will have some documentation. It's useful to have some documentation even for yourself.
2. it's good advertisement and part of the portfolio of the company. "Hey, I know WikiVote! They've developed this cool extension! I think I will recommend them to my friend who want to do a wiki project".
3. if someone use your extension you have free testers that will report you about the bugs
4. if I patch Yaron's extension and Yaron integrate my code into repository then from now he will support and bugfix this code. So we now have free-of-charge part-time developer.
5. During the process of acceptance of my patch Yaron will beat my kidneys out to improve my code (will point on errors and coding style). The quality of code will be better.

Let's think now why we don't do that:

1. There are too many extensions here and there is no rating of them. Very useful and mature extensions are hard to differ from experimental and poor-written. Better categorization, an expertise and competitions of the extensions (like "Extension of the month") can make the situation better.
2. We're not sure that this is a good advertisement for us. The list of companies that Maria have compiled is the only list of companies I'm aware of. What about company profiles here on mw.org and creating the infrastructure/frames/motivation for us to write self-descriptions, success stories, etc?
3. We're too lazy to find time to invest into open-sourcing our extensions because of (1) and (5) of the previous list. This is just wrong and we have to change here.

I agree with Yury above. Open sourcing is often a huge effort for a small structure (true open sourcing, not just putting code somewhere and claiming it open) and there is little to no support coming from the community:

• WM Workers have far too much work on the core to worry about third-party extensions (outside WM scope)
• MW Volunteers have their own job and a full plate when it comes to code their own extensions and maintaining them.
• Third Party developers do their best to help and open, but resources are scarce enough for their own dev.

It is not a blame, but it is clear than third-party development support is not a priority at WM (like it is at FB, or WordPress, or SoundCloud...). Plus WM's philosophy is not very commercial/non-free friendly.

I don't think this could be fixed (if it should be fixed) without creating jobs and positions to sustain a viable opening strategy towards third-parties.

ClementD it does take a lot of time to open source, but is it not an investment? Does it now pay back because of the reasons User:Katkov_Yury listed as well as by saving time when upgrading? Is it the initial development of an extension the hard part or the maintenance?

Also, are there other things third-party users can share with each other ( best practices, scripts, etc.) to help each other or is it just extensions?

The topic of merging contributions is quite recurrent. The WMF focus is indeed in Wikimedia projects and not 3rd parties. However, is there anything stopping 3rd parties getting organized and pushing "their" developers through the code meritocracy until having enough with merge rights?

Many patches are waiting not because of its origin, quality or disagreement in the implementation, but just because there is nobody with enough time to look at them. It is hard for an individual developer of an extension to fill that gap but maybe MediaWiki 3rd parties united could pool efforts? Imagine that such proposal would receive wide support and commitment from a bunch of MediaWiki 3rd party developers. Maybe such group could even get Wikimedia funds to help getting that work done. It is possible to argument that a healthy MediaWiki ecosystem helps a healthy Wikimedia software platform...

Time to consider a MediaWiki Group for 3rd party developers? (or Vendors, or...)

This post was posted by Qgil-WMF, but signed as Qgil.

I'm not sure the current +2 policy really allows it: there might be a sort of catch 22, for instance, in that a dev with a focus on third party wikis may not get +2 on core because of lack of code review experience on core, and committers may not submit commits at all for such devs to look at because they know they'll be ignored; after all, even commits specifically focused on Wikipedia are just left rotting for many months.

And yes, improvements for third parties do get blocked by contrasting WMF needs, although of course in those cases the ideas on what is an improvement are often controversial (see the recent skins saga).

+2 says: "+2 rights on MediaWiki core and extensions are granted to (...) Community members who have contributed high quality patches, exercised +1 rights well, and demonstrated competence." Are there 3rd party sensitive developers in this track, aiming to get +2 rights? 3rd parties could coordinate with them in order to build more +1/-1's, more feedback around those patches and more Gerrit karma.

Again, coordination between 3rd parties would be a key factor of success, if they can agree on the developer to focus, coordinate with, promote, perhaps fund.

This post was posted by Qgil-WMF, but signed as Qgil.

Thank you Yury for listing the pros and cons of sharing.

This is the second time rating of extensions has come out as a suggestion today. Is that something that will be really useful? How hard would it be to implement? Who would judge? What would be the criteria?

Regarding your point about advertisement, I don't know if people have seen this but there was some idea in the past to make a list of people to hire for MediaWiki projects here, but the community decided it was not appropriate to endorse any companies/developers ( see discussion here). However, you can see several external lists of MediaWiki contractors. Add yourself if you haven't done so.

By the way here is the longer version of all the pros on my weblog about MediaWiki: http://www.ykatkov.name/2012/10/06/the-importance-of-participating-the-community/