Topic on Talk:Best practices for extensions/Flow

From the name and (extremely minimal) lede, it sounds like this page is making recommendations for all extensions. However, from the very first recommendation, it's clear that the intended scope is only extensions that are meant to be used generally, and especially those aiming for WMF deployment. This disconnect could lead readers to believe that an extension being developed exclusively for use on e.g. a single third-party wiki is either explicitly discouraged, or has to jump through unexpected hoops that implicitly discourage development of such extensions. I'm sure that such extensions shouldn't be encouraged, but I think it's a mistake to actually discourage their creation/use, explicitly or otherwise.

tl;dr This page's lede should be expanded to clarify what sorts of extensions it's intended for: all extensions, or only those intended for use outside of their originating communities/wikis. (Possibly individual recommendations should receive similar clarifications.)

The document is intended for all extensions, but I think it is worth recognizing that while something is universally a best practice, it may not be applicable for specific extensions. For example, disabling the parser cache is not a good thing, but some extensions do it, and that's okay for how they're used.

The first recommendation is "Use the standard issue tracker". I don't understand why you think that's specific to WMF deployment. In general, having MediaWiki extensions track bugs in Phabricator and use Gerrit (eventually GitLab) for code review should be considered a best practice, given all the benefits from doing so.

Not all MediaWiki wikis are owned/operated by/as public, FLOSS, and/or not-for-profit. Accordingly, all MUSTs are at best OPTIONALs for basically obvious reasons n.b. it's not reasonable to expect a private company with likely different expectations of licensing (the polar opposite of those three values, so the other end of the spectrum) to comply with "publish on WMF Gerrit" and "use WMF Phabricator" and "use PSR-4" and "localize" and etc. For example, even two other organizations that are reasonably 'open' and in a topical sphere to WMF (Miraheze, Fandom) don't do every one of those MUST things.

So, I agree that the scope should be clear, as should be the expectations associated with not developing with the requirements, objectives, and best practice as documented here in mind.

This document isn't targeted towards private companies who want to make their own extensions. I think it is reasonable to have a baseline for *best practices* to use localization (one of MediaWiki's Principles), PSR-4 (a PHP best practice), and use Gerrit/Phabricator to be along with the rest of the MediaWiki ecosystem.

I don't think it's targeted at them, but it can trivially be read as if it were. Separately, because it leans on the RFC text as it does (I am increasingly not a fan in the way it changes the meaning of those words from the RFC), someone who does look at any given line with or without context will surely not see the forest from the trees when "MUST" is the word used.

This document should cater to professional engineers because the advice it gives is valuable for anyone developing an extension, not just the open source or trivially-reached MediaWiki ecosystems. That's besides the already-provided organizations which are trivially-reached MediaWiki ecosystems and which themselves have an interest in observing these practices, yet clearly will not and do not have an interest in e.g. using WMF Gerrit.

GOLD/SILVER/BRONZE, or BEST/BETTER/CONSIDER/RECOMMENDED, or similar other words would be better on that point. Remember, these are best practices.

+1 to MUST/SHOULD/OPTIONAL vocabulary not really being useful for general guidelines. You MUST use Phabricator and Gerrit and MUST put your classes in an src directory... or else what? Plenty of MediaWiki extension do not follow these rules; plenty of Wikimedia extensions do not follow many of the MUST rules, even. And I struggle to see what moral or legal authority anyone would have to make such declarations for plugins for a FLOSS software.

There are a few security-related points that we'd probably enforce by dissociating problematic extensions from the project or warning users against them, but everything else is a recommendation. Maybe rename it as good / great / best or something like that? (The API best practices guideline uses gold/platinum, it doesn't have a third level though.) Or preserve MUST for the few things where, if we had an extension store, we would kick an extension out of it if it violated that.

+1 to MUST/SHOULD/OPTIONAL vocabulary not really being useful for general guidelines. You MUST use Phabricator and Gerrit and MUST put your classes in an src directory... or else what?

… or else you are not compliant with this document, and we would not call your extension "best practice", as judged by the standards of the MediaWiki ecosystem.

Plenty of MediaWiki extension do not follow these rules; plenty of Wikimedia extensions do not follow many of the MUST rules, even. And I struggle to see what moral or legal authority anyone would have to make such declarations for plugins for a FLOSS software.

Indeed. Why do you think this page is claiming it has such authority?

I specifically didn't speak to the RFC language since Topic:Ugpw2635x8nzzp3z (second discussion from the bottom) is pertinent on that point.