Patch acceptance criteria

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Patch acceptance criteria

Nathan Larson
I'm working on a bot 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, "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.

--
Nathan

_______________________________________________
Mediawiki-api mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api
Reply | Threaded
Open this post in threaded view
|

Re: Patch acceptance criteria

Max Semenik
On Thu, Jul 31, 2014 at 3:23 PM, Nathan Larson <[hidden email]> wrote:
I'm working on a bot 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, "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]])

_______________________________________________
Mediawiki-api mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-api