On Thu, Jul 31, 2014 at 3:23 PM, Nathan Larson nathanlarson3141@gmail.com wrote:

I'm working on a bot https://github.com/Inclumedia/MirrorBot that will gather all data, including revision IDs, as they are made available via the MediaWiki API, by polling list=recentchanges. To make it easier, I'm developing core patches to make more data available via the API. See, e.g., bug 68950 https://bugzilla.wikimedia.org/show_bug.cgi?id=68950, "log_params should contain the revision IDs of null revisions created by page move events". I don't know why anyone else but me, or someone working on a similar project, would need this feature, but being able to access that data via log_params makes it so I don't have to do a separate prop=revisions query.

I was wondering, how do the +2's decide what API features are useful enough to enough people to be worth reviewing and merging? Are they more likely to ask "why" or "why not" when a new API feature is proposed? Are there any developers in particular who'd be interested in reviewing new API features for obscure use cases? Thanks.

For me the criteria has always been common sense: does the feature look sane? Does it look generic enough to be used by more than one person? Can it be done some other, cleaner way? What bad could happen if we _don't_ implement it?

Also, it's a topic for wikitech-l