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(a)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
<http://sample.lagotto.io/sources/wikipedia>. 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