# SITE::Scope.resolution->choice(Student.access->block(net))

A new question has again raised the issue of the scope on our site.

In this case it's about some possible form of internet blocking affecting the student access to resources. Other questions which we have dealt with include classroom layouts, monitoring student screens, note taking, blackboards vs. high-tech tools, Smart Boards, letters of recommendation, an in-house server, hardware choices, and version control setups.

In many cases we have seen questions which would be "in scope" for other sites and have kept them here. The SE rules do not require that a question be on-topic on exactly one site, not that our scope be exclusive to this site, refusing questions which might be better asked elsewhere.

The question addressed here might have gotten answers, or good diagnostic hints, on Super User or Server Fault. It also may have been rejected by either site as off-topic. The issue of a question's topicality here should not be a function of its topicality elsewhere. Rather, the decision should be based on our site's determination of our scope.

It does not seem like an expansion of scope to accept that question, or the others mentioned. Classroom management, student engagement, technical issue, and many other subjects are involved in teaching CS. Some of the issues faced may be common to teaching in general, yet have a twist when applied to the CS field. Others may seem more like a question better suited for programmers or computer scientists, yet have a twist when applied to the classroom. In both cases, while an answer might be forthcoming on a sister site, the answer could be less useful than if the environment of a CS classroom is considered in the problem. Taking that extra element into consideration is something which we can specialize in.

I do not believe, however, that the mere coincidence of an issue involving a CS classroom, or educator, at some level makes any question automatically on topic. "How to replace the hard drive", or "How to configure the network in the classroom", as examples, are not going to have any significantly different answers because there is a CS classroom involved. How to replace the computer's disk drive is pretty much the same at work, at home, in the classroom, or in a cave. Ditto for running cables and connecting computers to a network, or a virtual LAN. "How to configure the classroom server", however, might be different for the CS classroom than for other classrooms, or the office.

## Conclusion

The question, "Do some websites block school building/classroom IP networks because they mistake us for possible DDOS?" is one I consider on topic for Computer Science Educators.

The question, "Do some websites block school building/classroom IP networks because they mistake us for possible DDOS?" is one I consider on topic for Computer Science Educators.

Here are my thoughts:

If a goal of the site is to provide answers to CS Educators, from CS Educators, about CS Educators' problems, then we need to be aware of two possible situations. Cases where the problem faced by our users is uncommon outside the discipline, and cases where the solution could be different than it would be outside our discipline. When a question faces a scope challenge, it can be helpful to consider its implications to our target user base in light of these two possibilities.

While I expect it to become increasingly common in non-CS classrooms, student access to internet resources is often an in-class, near simultaneous, event. Repeated multiple times per day, once per class period. Two other users have already mentioned similar experiences, so we can expect that it is a non-rare problem. Outside of CS-related classrooms it is rare for every student seat to be equipped with a computer which the students are expected to use, including web access, during class. Lacking that environment, few teachers will direct their class to access one resource as a body.

As it turns out, one solution to another problem, monitoring student screens, would work in any classroom, and actually come from a completely different venue, security. Again, even though the solution is useful in any classroom, its need is, so far, seemingly only in the CS classroom. Computer scientists, outside the classroom, wouldn't even have a related issue, and it is not a CS issue, it is a classroom issue.

Conversely, being a classroom issue is not, on its own, necessarily enough to raise the question into scope. Dealing with rowdy, or unruly students is a classroom management issue which is not unique to CS, nor are the range of solutions. Absent some other compelling attributes I'd not place such a question in scope for the site.

Issues which seem to be CS specific may still be seen differently than they would outside the classroom. For example, the goto statement (or its near kin break and continue) engender one set of discussions in the programming community. In the education arena the discussion can become different. A reading of the related posts on Stack Overflow reveals a different set of concerns than do our two related questions. There is, of course, a lot of the same material covered. There is also, however, some concerns which instructors have that programmers don't address in their discussions.

Interestingly, the current question also fits in the second category; the 'standard' solution to the problem could well be different for the classroom than it would for another situation. A common solution to access restrictions, whether imposed at the client end or the server end, is to utilize a VPN. School policy could prevent the instructors, or the students, from using VPN connections from the school's network. If there is enough traffic, it's also possible that the cost of a reliable VPN for a classroom full of computers could be well outside the available budget. Lastly, the experience of the block can become a "teaching moment" if the instructor chooses to do so. None of these considerations are likely to be involved in solutions offered from a perspective outside the discipline.

The solution to the problem, or a work-around for it, is not likely to be offered by the users of Server Fault. The good folks there might, however, have good ideas about what can be done to protect a server from malicious actors, and how the situation might have triggered a 'lock-out'. They probably also are aware of some counter-measures that trigger when there are multiple accesses from a single IP, and why. They probably would have not realized that from in-class all the students would be using a single IP, and that the same IP would be doing the same thing every 75 minutes. The use of "DDOS" in the title would likely have helped them "forget" that aspect as well.

Super User users, on the other hand, who have experiences in an office setting, where a common IP address can be an issue, might have a solution for the problem. Those users may not even know "why" it happens, and still have figured out what to do about it. (One does not need to know how the Sun produces light to know how to protect them self from a sunburn.) It is, unfortunately, possible that the solutions offered there would not take into account the possibility of the school's filtering software, or service, having an impact on the problem, or preventing the solution from being implemented.

In short, how well this question might have been answered elsewhere, if accepted, does not affect my willingness to accept it as in scope. How well it fits within what I consider one of the goals of the site does. The possible results from posting elsewhere do, however, emphasize why I think we need to keep such question in scope.

We are still a young, and growing, site. As such scope refinement is going to be a large part of our growth. Even long-running and well established sites still have discussions on scope, though much less frequently than we do, or I think will.

In addition to @GypsySpellweaver's quite articulate (and persuasive!) answer, I would also add that within our own site scope, answers could relevantly include classroom management solutions to dealing with such problems. I consider the question to be within our scope as well.

I guess the ultimate solution is to have all questions to all SE sites pour through a common gateway system that would weed out the common faults and determine which site they are appropriate for, if any. Perhaps a bucket of related candidate questions could spontaneously create a new SE site to send them to.

Then, all searches should simply go to the SE question gateway and automatically locate any appropriate matches on any site.

In other words: a library. This is what I thought the internet should have been all along. I was initially mystified by the need for search engines when I heard of the idea in the late 90s. I exclaimed, "What, there is no card catalog?" Who would try to do something so stupid? Millions of people, apparently. A thousand horses designed by a thousand committees and rogue developers.

We could try again.