As many OAuth tools are semi-automated, they're prime candidates for being interesting ways to help our most active users make contributions on mobile devices while they're on the go. The OAuth workflow is pretty poorly designed for this at the moment, but it has a lot of potential.
Generally, mobile experiences are easier to create if the data backing them is structured data that can be interpreted onto a mobile screen in a way that's mobile friendly. Putting the information into wikipages, practically speaking, makes that much harder. Given the other advantages to this also detailed in this thread, I'd prefer to see us take the more structured approach. A wikipage could be used if necessary as a fallback for more information. Dan On 10 August 2015 at 18:23, Gergo Tisza <gti...@wikimedia.org> wrote: > tl;dr should OAuth [1] (the system by which external tools can register to > be "Wikimedia applications" and users can grant them the right to act in > their name) rely on community-maintained description pages or profile forms > filled by application authors? > > --------------- > > Hi all, > > I would like to request wider input to decide which way Extension:OAuth > should go. An OAuth application needs to provide various pieces of > information (a description; a privacy policy; a link to the author; a link > to the application; links to the source code, developer documentation and > bug tracker; and icons and screenshots). There are two fundamentally > different approaches to do this: either maintain the information as > editable wiki pages and have the software extract it from there; or make > the developer of the application provide the information via some web form > on a Special:* page and store it in the database. Extension description > pages are an example of the first approach; profile pages in pretty much > any non-MediaWiki software are an example of the second one. > > Some of the benefits and drawbacks of using wiki pages: > * they require very little development; > * it's a workflow we have a lot of experience with, and have high-quality > tools to support it (templates, editing tools, automated updates etc.); > * the information schema can be extended without the need to update > software / change DB schemas; > * easier to open up editing to anyone since there are mature change > tracking / anti-abuse tools in MediaWiki (but even so, open editing would > be somewhat scary - some fields might have legal strings attached or become > attack vectors); > * limited access control (MediaWiki namespace pages could be used, as they > are e.g. for gadgets, to limit editing of certain information to admins, > but something like "owner can edit own application + OAuth admins can edit > all aplications" is not possible); > * hard to access from the software in a structured way - one could rely on > naming conventions (e.g. the icon is always at File:OAuth-<application > name>-icon.png) or use Wikidata somehow, but both of those sound awkward; > * design/usability/interface options are limited. > > Some previous discussion on the issue can be found in T58946 [2] and T60193 > [3]. > > Right now OAuth application descriptions are stored in the database, but in > a very rough form (there is just a name and a plaintext description), so > switching to wiki pages would not be that hard. Once we have a well-refined > system, though, transitiong from one option to the other would be more > painful, so I'd rather have a discussion about it now than a year from now. > Which approach would you prefer? > > > [1] https://www.mediawiki.org/wiki/Extension:OAuth > [2] https://phabricator.wikimedia.org/T58946 > [3] https://phabricator.wikimedia.org/T60193 > _______________________________________________ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Dan Garry Lead Product Manager, Discovery Wikimedia Foundation _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
