On Thu, Jul 31, 2014 at 3:23 PM, Nathan Larson <nathanlarson3141(a)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
--
Best regards,
Max Semenik ([[User:MaxSem]])