How does the /tags/{tags}/info method differ from the /tags with inname? Also why not just /tags/{tags} (not that I mind just should this method be used differently to others?)

Can't you just make another query to the /tags route?

Given that answers are only for bug reports, would it be possible to change the answer button to bug report on only the app, library and script tags? This would make it very clear

I was going to something I thought I heard, that the filters were more integrated, and only the fields checked are pulled (I think it was something about the total field being expensive on their side and thats why it is disabled in default filter, and been replaced with has_more), but I don't know if thats true, so my comments are made on the assumption that it's true, if it's not then I completely understand the point of shallow_user and my comments are invalid

With filters you could choose which field you want and don't want from the full user object. So if the /search query return user objects. Eg, You can choose that you want the accept_rate and last_access_date fields but not the reputation field. So rather than asking for fields to copied from the user object to shallow_user you can just untick the fields you don't want. The same also goes for network_user.

This is the problem with shallow_user there will always be a field wanted from user. This is exactly the problem filters solve. Please Kevin can we get rid of the shallow_user?

So they will be put in later when they've been revisited. It's quite unwieldy to present the user with such a long list of sites.

Even better is to have a context field, and have it not only on this route, but things like badge awards as well.

Surely it would be better just to make related_site have jut two fields, relation and site. Where site is just a normal site type. Then use filters to choose what you want.

So what is the list sorted on? can't you just make that visible?

I know but if you query multiple sites, you can compare average (or something like average) relevance.

I was thinking it would be possible to use this value to determine if another site could be more suited to a question?

The register application page gets you your API key which allows your app to make many more requests to the API, it also allows you to use API methods that require authentification and the description/app-title/app-icon you enter there is used for the window that users see when they permit your app to access their data. If you make a script which doesn't use te API then you don't need to Fill out the "register application" page. If your app doesn't use the API then usually stack apps is not the place to list it