To summarize Dan's comments: damned if you do, damned if you don't.

I lean more toward helping the less sophisticated user by default, and trusting the more sophisticated user to do the right thing. I'd say bot creators are more sophisticated than most human users, who are more sophisticated than most bots.

So, if the community of bot creators is generally responsive to changes to the API and default behavior, and this change is well communicated beforehand, they should be able to adapt as needed. On the other hand, if there are lots of orphaned bots out there doing good work, we might break some of them. On the other other hand, someone should find those bots new homes.

I also feel like humans users expect and deserve the best results we can give them, so I lean more towards making the change the default.

A more complex and more general approach might be to version the API... though that's a whole 'nother can of worms. But it would allow API users to expect a consistent set of features for the life of the version, and would allow them to upgrade to and adapt to the new version over some time period rather than having to scramble (or just suffer breakage) the day it goes live. This would require serious thinking about what it means to be a version (is it just default flags, or do old versions get or not get feature upgrades), how to indicate versions (including "always the most recent API" and "I'm from the time before API versions"), how long versions live, how many we support concurrently, how to fallback from unsupported versions, etc., etc. But Dan seems like he needs more hobbies, so I'm throwing it out there.

—Trey

Trey Jones

Software Engineer, Discovery
Wikimedia Foundation

On Thu, Jul 30, 2015 at 6:38 PM, Dan Garry <dgarry@wikimedia.org> wrote:

There are a multitude of API consumers out there that would expect this kind of behaviour by default. For example, reader apps like our native apps, and other third party apps, would likely prefer the forwarding to happen automatically without having to write additional code.

That said, there are also a multitude of API consumers that would not prefer this kind of behaviour. Examples of this include people that are looking for things and expecting to find zero results, which includes a lot of scripts run by advanced users and external services like Lagotto. If the default were changed, they would have to write additional code to handle it.

I'm prepared to make a decision as product owner, but input would definitely be appreciated.

Thanks,
Dan