Extension management 2018 feedback/Other

Configuring an extension should be possible from a special page

Almost all extensions have various configurations that require us to edit LocalSettings.php file. I think this could be better done using a Special Page where we would have a form for all the configuration options available and the values can be set from there. Nischayn22 (talk) 06:16, 17 May 2018 (UTC)

Endorsements

• Nischayn22 (talk) 06:16, 17 May 2018 (UTC)
• ...

Comments

• Is there a specific requirement that this be a special page, or would any web frontend (e.g. as a part of the web installer) meet your needs? Legoktm (talk) 17:35, 18 May 2018 (UTC)
  • Any web frontend should be fine. But it should be accessible after installing as well. Nischayn22 (talk) 16:51, 11 June 2018 (UTC)
• I do not like this idea at all since if done right it would mean that is shoudld either be done either via "LocalSettings.php" or via a special page. --[[kgh]] (talk) 14:31, 20 June 2018 (UTC)

Revisit extension compatibility policies

The current compatibility policies are "master" and "rel".

Policy	Pros	Cons
rel	Makes it clear which version of an extension to use for a given MediaWiki version.	Release branches are automatically cut when the first MediaWiki release candidate for a new MediaWiki version is created. This is usually before an extension owner has had a chance to verify that the extension works with that MediaWiki version. Any bug fixes need to be backported to the release branch. If new features are added to an extension that are desirable for the current LTS, they need to be backported. This is not necessarily a straightforward process if not all patches are backported. Especially for volunteers maintaining extensions, keeping multiple release branches up to date can be burdensome.
master	Easier for extension maintainers, since no backporting is necessary.	Requires backward compatibility shims, which make the code ugly. It becomes less clear which versions of MediaWiki are supported by an extension. ExtensionDistributor provides the release branches of extensions that use master compatibility policy. This frequently results in conversations like: User: Why isn't feature X working? Maintainer: Are you using the latest code? User: Yes! . . . lots of discussion back and forth . . . User: . . . when I downloaded the extension from ExtensionDistributor for the version of MediaWiki I'm using . . . Maintainer: Oh! You should not use the release branch for an extension that has master compatibility policy.

It would be good to revisit the compatibility policies or the supporting environment to try to address some of the issues. Cindy.cicalese (talk) 21:21, 3 June 2018 (UTC)

Endorsements

• Cindy.cicalese (talk) 21:21, 3 June 2018 (UTC)
• Sam Wilson 03:09, 6 June 2018 (UTC)
• [[kgh]] (talk) 14:38, 20 June 2018 (UTC)
• ...

Comments

• As far as I am concerned I only want to know if I get backports to LTS or not and if the backports include new features, just fixes or only security fixes. Somewhere on this wiki I tried to figure out what these two policies acutally mean. Moreover I suggsted a tagged policy. I cannot find it right now and it was inconlcusive since knowbody was really able to tell what to add. --[[kgh]] (talk) 14:38, 20 June 2018 (UTC)

Include help documentation within extensions

At the moment we link to pages on MediaWiki.org (prefixed with Help:Extension:) to provide end-user help/documentation for extensions. The problems with this are a) that the version in use may not be the latest, and so the docs may not apply; and b) the user is sent away from their wiki and so gets confused. It'd be cool to be able to include help pages within extensions' code, so that the user always sees docs that are applicable to the version they're actually using, and in their own wiki. —Sam Wilson 02:37, 6 June 2018 (UTC)

Edit: I meant to add that the docs could also be available on MediaWiki.org (via some magic), perhaps even for multiple versions. Sam Wilson 00:19, 7 June 2018 (UTC)

Endorsements

• Sam Wilson 02:37, 6 June 2018 (UTC)
• ...

Comments

• If the docs have a meaning-changing typo or something, user will be stuck with incorrect docs. Edward Chernenko (talk) 23:30, 6 June 2018 (UTC)

  @Edward Chernenko: That's true, but also that situation would be viewed as a bug and fixed accordingly. It would make it harder to make informal corrections and updates to the docs, but also mean that everything would be reviewed prior to publishing (which could make make sure things are correct). Sam Wilson 00:19, 7 June 2018 (UTC)

• I'd rather see extensions properly documented here on their docu pages. --[[kgh]] (talk) 14:39, 20 June 2018 (UTC)