Aaron and I were talking about this today. It seems like there are 2 ways forward:

1. We extend the schema and allow the user to put in a link to any page. We would limit it to internal links, but interwiki links would be ok. This makes the option very customizable for the developer, but prevents standardization.

2. We generate a URL for each consumer, and allow the app developer to fill in their documentation. We have several options for the actual page name. "Help:OAuthApplications/<app name>" would work if we make sure app names are unique (not difficult). Negatives for the Help namespace is that talk pages have the support warning. OAuth namespace pages might be an option. In general, this would promote standardization, but for example, if an app is only meant to run on zhwiki, we don't really want to send end-users back to the central wiki to see the app's help page. This could be addressed by checking the local wiki first, and then falling back to the central wiki.

Thoughts from anyone else?

In any case we need to be careful perhaps about localization of the help page name (and different versions for each language).

I think I like option 1 better. Is standardization needed?

For option 2, we might want to allow for local wiki customization (well, local to the central wiki) so sites that want to use something other than "Help:OAuthApplications/$1" could do so.

For option 1 people could use Special:MyLanguage as part of their link (as long as their page was on a wiki where that is available, of course). The same could be done for option 2, either if we can detect that it's available or by the local wiki customizing the prefix as mentioned in the paragraph above.

I'm fine with option 1 as well.

Reprioritising as I'd like to see these ones fixed in our next release.

See also bug 58193. I'm not sure I agree that a change tag should link directly to a consumer-specified URL. What I like about a MediaWiki-generated page like:

https://commons.wikimedia.org/wiki/Special:OAuthListConsumers/view/90b858d7d1179a1b4eee89956e735e80

1. We can localize it and display it in the context/language of the wiki where the application ran.

2. We can ensure that some standard fields (e.g. bug reporting mechanism, source code) are present and easily discoverable.

3. We can ensure that basic application metadata is available even if the application's own website is not.

If we have such standard information in a structured form, we can then also build new user interfaces if we desire it (for example, you could imagine clicking on a ChangeTag for "Cool Wikipedia Editor" and it offers you a "report a bug" link, but that would require knowing what the bug report URL for "Cool Wikipedia Editor" is).

What I don't like about the current page is that it's not user-friendly and doesn't include obviously useful information.

I'd suggest, as a minimally problematic first step, cleaning up that page a bit, and adding at least a tool URL and a description/help URL, and possibly some of the other fields mentioned in bug 58193. If I'm wrong and linking directly to either of those URLs is more useful than a localized landing page, we can always do so later.

I see little point in option 1. If we linkify URLs or allow limited wikitext in the description (and there is no reason why we shouldn't), developers can use that to link any relevant URLs (often there will be more than one).

As for option 2, wiki pages following some common conventions have a lot of benefit but that's a social norm and the link can again easily be added to the description. I'm not convinced the interface should try to enforce that norm. $wgExtensionCredits, for example, does not require you to link to a mw.org page but in practice nearly all extensions do. (OTOH, an ability for app owners and OAuth admins to update descriptions would be helpful.)

Creating standard wiki documentation pages for applications is probably blocked by T59336 (I imagine we would want them to exist on the central wiki).

We need to store the URL of the app's privacy policy at least (assuming it's not on-wiki at a standard location) since that needs to be shown on the authorization dialog. That's T98843.

In T58946#1390304, @Tgr wrote:

OTOH, an ability for app owners and OAuth admins to update descriptions would be helpful.

(part of) that's T59631.