GitHub and younger ScriptCrafters

[Captain Starbuck]

We are starting to view this ScriptCraftJS project through an assortment of lenses.

There is the core code, a Minecraft plugin, created and maintained by Walter. This is a FOSS project like any other, hosted at GitHub, with contributions from whomever is interested. In that repo we see issues, technical notes amongst developers, documentation updates, and other details about the internals of this. The repo isn't so much about the game, but simply about maintaining a piece of software.

So far the GitHub repo has also served as one of the primary locations for people to download the software for whatever purpose.

We have people in the field using the plugin to enhance their game play. They have no desire or need to contribute to the core, and they're not interested in the development process or some "ecosystem". All they want is a functional plugin for continued entertainment - like all of the other plugins they use. They aren't going to submit issues or PRs (pull requests = contributions) to the repo, but they will (hopefully) read the documentation and maybe let us know where it's faulty or when things don't work from their perspective.

We have teachers and other leaders who use this software as a tool. Their primary objective in monitoring what we do here is simply to track what's happening so that they are on top of changes which affect their classes.

We have other people interested in the development of the software, maybe not at the low/nerdy level of someone at GitHub. These are a combination of students, gamers, teachers, and "casual observers" who are at that next level of using the software, and willing to post the occasional note about what's not working or what can be done to make this all better.

So, the audience is diverse, and everyone comes to this software through a different vector - it's not all GitHub, not all the Bukkit/Spigot plugin repo, etc. As a part of the development of the new website, I've tried to create separate but related homes for various groups, to help them to get what they want easily, to lead to other options for consideration, and to foster communication everywhere.

Related to Non-Core assets, for us, the nerdy types, GitHub is a perfectly reasonable place to host everything. But moving forward I suggest that while we can host some or all of it there for community maintenance, I do not believe that's the right place to refer younger visitors. I refer you to the GitHub Terms of Service and the following clauses:

A.4: A User must be at least 13 years of age.

B.2: You must be age 13 or older. While we are thrilled to see brilliant young coders get excited by learning to program, we must comply with United States law. GitHub does not target our Service to children under 13, and we do not permit any Users under 13 on our Service. If we learn of any User under the age of 13, we will terminate that User’s account immediately. If you are a resident of a country outside the United States, your country’s minimum age may be older; in such a case, you are responsible for complying with your country’s laws.

With this, I think it's important that all discussion about referring people to GitHub should include this understanding. We want people age 13 and over to visit GitHub if that's within their comfort zone. We also want to invite everyone of all ages to the (new) ScriptCraftJS.org site for all purposes, including download, information, Q&A, and collaboration. But we don't want to send kids to GitHub or other sites.

We can dance with the concept that we're just referring people to an open resource and it's not our responsibility for how they use it. They may or may not get an account there. The problem comes when we suggest that GitHub is the place to post code, a kid posts code, and their account gets shutdown. Then we/they need to deal with the frustration of a child who has been led to disappointment. Perhaps it's paranoia but I could also see GitHub itself getting upset with this project (and Walter's repo) that "we" collectively are sending kids to their site like this. Let's not start that ball rolling.

The new site accommodates bug reports for the core, and for plugins created with ScriptCraft. We must allow visitors to post and advertise their own contributions, and to download creations by others. But uploads and downloads must be vetted to ensure suitability for the audience. Code and other content needs to be filtered for social and technical purposes. These are the reasons why there are Terms of Service prohibiting minors from registering.

I've been dancing with some code related to supporting a repo at the new site. I'm on the fence about exactly how that will be done internally. I'm inclined to attempt hosting content at GitHub where it is available for review and update by the public (subject to normal PR vetting). The site and GitHub will be wired into one another in the background via web services to make that sourcing and review process transparent. It will introduce some delays as contributions are committed, but hopefully we can get a few committed reviewers to minimize delays - and yes, these reviewers themselves need to be vetted. I can host all content on-site, no GitHub interaction, but people will then need to vet content on-site, and I'll need to implement a local repo for that purpose.

I'm aware of obvious pitfalls and will handle them. But I'd like to ensure we get the less obvious concerns on the table, for handling, or to allow us all to reject this aspect of the site as a huge bad idea. So I'm posting this here with all of these considerations for your comments.

If we move forward with this, I'll need some non-technical help on matters which I don't have time or resources to address....

I need to understand and adhere to international laws regarding the usage of a site for these purposes by minors. What are those laws referenced by GitHub in section B.2 above? What can we do to ensure we operate within the law?

The alternative to handling this is that we simply don't allow kids <13 to use the site at all, for fear of abuse and/or the law. That would be a loss. We could take an approach where a parent must register a child and approve their use - but in the real world that's a useless hassle for many reasons.

There may also be issues, where despite built-in handling, someone who is not an adult, in some jurisdiction, is exposed to something which is considered inappropriate by any jurisdiction. In this case, protections for all must be in place beyond simple Terms of Service and disclaimers.

Are there educators or lawyers here who can research these topics and help us to move forward appropriately? I don't want to walk down a dark street and fall into an easy-to-see hole or get run over, when simple illumination would help to avoid such an incident. :)

Thanks all for your time.

[Landru 27]

From a stint at AOL, I am familiar with the US law about users under the age of 13.

In simple terms, any site that permits user interaction must, under this law, take measures to ensure the safety of users under the age of 13.  In other words, the site takes on some of the onus of the safety of such users.  So, most sites simply state in their ToS that no users under the age of 13 are permitted.  (The idea being that if an 11 year old does open an account, then -he/she- violated the ToS, freeing the site from responsibility under this law.)

GitHub's pull request discussions (and some other features) of course count as user interaction, even though the main purpose is not social.  Turns out, wrongdoers will use things for other than what they are intended for in order to do their wrongdoing.

So, ...   any site we build would have to make the same three-way choice:  (a) don't permit user interaction at all, (b) state clearly in the ToS that those under 13 years old are not permitted to have an account, or (c) safeguard users from other users, ensuring such things as no exposure to inappropriate content, no danger of on-line interactions that lead to unsafe off-line interactions, and so forth.

Option (c) is prohibitively expensive (among other shortcomings), and option (a) is antithetical to sharing code and exchanging ideas.  That puts us right where GitHub landed.

- Andrew