Communication with other sites about what is on topic

Question

We've started to receive traffic from other sites (Super User in particular).

No, on superuser they said I had to ask it here. So I did that. And that is excactly what I want to know if I shoud buy it or not with my current setup. I don't understand why this is off-topic
- https://hardwarerecs.stackexchange.com/questions/504/can-i-run-another-msi-gtx-760-4gb-oc-in-sli-mode-with-my-current-set-up#comment1097_504

How do we communicate with other sites on the network what is and is not on topic here? I know there was similar scope issues surrounding Stack Overflow and Programmers/Code Review. There are also many comment recommendations on SO to use Software Recommendations.

What have the smaller communities, who's scope isn't properly understood completely, done to educate users of the larger site so that they don't receive off topic questions? Can we adapt any of those strategies for our use?

Answer 1

Once we get our own mods, I would encourage them to be proactive, even annoying about telling other mods our scope and quality requirements. In the early days of SR, I would ping a moderator from another site and tell them not just that what they migrated was off topic (unclear, not enough requirements, whatever), but also why. Pretty soon, we had people across the network that knew what we accepted and didn't. That's helped a lot.

Also, on SR, I go through a list of comments on Stack Overflow that link people to SR without a link to our quality guidelines. I then ping them with this comment:

@[type here] Software Recommendations moderator here. We have fairly strict quality guidelines, so I'd appreciated it if you would link to our question quality guidelines whenever you recommend someone re-ask a question on the site. Thanks!

To which I've only received positive responses. I'm trying to fight back the ocean here on Stack Overflow, but this site is lucky: Stack Overflow doesn't get that many hardware recommendation questions. We don't have as big a battle to fight.

I'd encourage our moderators, when we get them, to adapt that comment to this site and fight the same battle. I'd also ask our users to do the same if they'd like - we have a chance to seriously reduce the number of bad "but they told me to come here" questions we get.

Answer 2

I'm using Open Source as an example because, well, I know it pretty well.

On OS, we had some issues forming up our scope early-beta, resulting in an extended private beta. Going public, we still didn't really know what was and wasn't on-topic. However, by that time we'd formed enough of an idea to create a help/on-topic page, which is point number 1. When we have moderators, one of their first jobs should be to solicit input from the community on a new help/on-topic page (which the recent "Updates to /tour" questions may help with), and then to write the page.

This page is more well-read than you'd think: on OS, we've had a number of people come in having actually read the page, and formed their question around it.

Point number 2 is migrations. Quite a lot of "this isn't on-topic here, but it might be over there" is done by moderators moving questions between sites. This is often co-ordinated between mods in a top-secret location 500 feet underground in chat. On receiving a migrated question, we can provide feedback to the sending site: if we don't like it, closing the question rejects the migration. If we do, we upvote, and the mods tell the sending mods "we want more of those".

There are two major points that I want to come out of this:

1. Mods are important
   Mods, being able to do more things than a regular user can, are important formers and enforcers of our scope. While we shouldn't rely on them, they'll be important to help in the early beta.
2. Business as usual
   For the most part, the way we should communicate our scope is to use the tools we're given - downvotes, comments, close votes. If we notice a serious problem with a site in particular sending lots of stuff our way that we don't want (cough cough, Stack Overflow to Code Review), then we should work on the education.