Reflections on the Scratch Wiki

I have been a major figure on the Scratch Wiki for a long time, though since coming to college I have been much less active due to other commitments. I first joined the Wiki on March 9, 2012, and have gained a lot of experiences in my time there.

My Beginnings on the Wiki

I first joined the Wiki in 2012 as a regular editor back in the days of Scratch 1.4, with my main intention just being to improve the article on Mod Share (a project on which I was a developer at the time). I made my necessary edits, and then also started editing other articles where I saw potential for improvement. I remained in that capacity for a while, until the release of Scratch 2.0.

Scratch 2.0 and user registration

When Scratch 2.0 was released, the existing account registration system (which depended on a user verification API in Scratch 1.4) no longer functioned. The Scratch Team announced that at some future date they would implement OAuth to allow other websites to link their account systems to Scratch’s, but did not give any specific date to expect it. Meanwhile, over at Mod Share, we had the same problem, also depending on that API. After discussing the situation with LS97 (the other Mod Share developer), we figured the best solution would be to verify users by having them comment a verification code on a project and then checking if they posted the comment. Once the system was successfully implemented on Mod Share (my code quality has improved since then, I promise), I contacted the Scratch Team asking if they would like me to implement a similar system on the Wiki. They ended up agreeing, so I got my hands dirty with developing a MediaWiki extension. I ended up modifying an existing extension, ConfirmAccount by Aaron Schulz, adding the comment verification to it (GitHub link). This allowed the Wiki to maintain the existing system of requiring users to request accounts while verifying (automatically) that users requested accounts corresponding to their Scratch accounts. As part of the implementation, I was given a new title, Experienced Wikian (developed specifically as a result of this new extension). In a nutshell, I had elevated privileges over normal users (most importantly being able to process account requests), but was below an administrator.

Becoming more active

With my role in implementing the account request system, I became much more active on the Wiki. I processed the majority of account requests to the Wiki for a while, and also was fairly active in maintaining the quality of the articles as well as the community. As time went on, the other active staff members mostly moved on to other things, and I became a de facto leader.

Moving On

As I started college, I knew I wouldn’t have as much time for the Wiki as I did before. I continued to help in the capacity I could, but knew time was coming to pass on the reins to someone else. I am proud to report that the Wiki still continues on and is going strong.

Transferring Ownership

In the winter 2018, the Wiki was officially transferred from Scratch Team ownership to being an independent project. This gave us a lot more freedom, especially the ability to install extensions and otherwise modify configuration ourselves as well as more moderation powers (specifically blocking users). While before all of these requests had to go through the Scratch Team which often took a while, now we could act unilaterally as necessary. In this time, many software improvements were made and all of the Wikis in different languages became part of a single ecosystem.

Thoughts

To this day, the Wiki continues to be an active community maintaining high-quality articles describing Scratch. To have continued this through over a decade and through several rounds of leaders is a testament to the spirit of the project.

I have certainly learned a lot over my time on the Wiki. It is a very unique kind of project, maintaining fairly high quality standards while largely being maintained by people in the 10-15 year old range. The most important lesson I learned was the importance of remaining calm and civil. One core policy of the Wiki is assuming good faith. In essence, that means that unless there’s obvious evidence to the contrary, assume that a user’s actions were made with an intent to help, or at at the very least, without the intention to harm the Wiki. Thus, while it is easy to endlessly criticize users for violations of Wiki guidelines, such as making articles about users, editing others’ userpages, creating duplicate pages, among a million other things, it was more important to help them. Almost every user (including myself) received a talk page message in their first few edits explaining that one of their edits had been undone or a page deleted because of some violation of Wiki guidelines. Rather than treating that as a warning, it was important to treat those as opportunities for improvement. In fact, I wanted to encourage users to be bold with their edits, since the best way to learn is by doing.

We also managed to maintain a semi-democratic system on the Wiki that has worked surprisingly well. The guidelines explicitly state that the Wiki is a collaborative effort, and we did our best to maintain that. I viewed my job (most of the time) as facilitating a discussion rather than making a decision myself. While I did have the final say, I rarely invoked that and instead went off of community consensus and established guidelines (which were also largely community-developed). Whenever possible, I tried to act as a normal editor rather than an administrator or authority figure (the one significant exception being in handling account requests, where that wasn’t really possible).

We did have a number of incidents on the Wiki, but compared to most other online communities they were fairly uncommon. I attribute this to a few things:

  • High barrier to entry: users had to submit an account request to join, and in that request they had to put forth a significant amount of effort (see the next paragraph)
  • High level of commitment: the community was based on maintaining high-quality articles, so most users who were not committed to that left on their own
  • Collaborative effort: we all were working towards a common goal and helped each other out wherever possible

Evolution of the Account Request System

The account request system changed dramatically throughout my time on the Wiki. When I first joined, the system essentially just required users to somehow describe how they would help on the Wiki. We then changed the system somewhat to require that users name specific articles they would improve and how they would improve those articles. Still, many requests did not meet the requirements, and we had little success in changing the requirements to join in such a way that more people would read them fully.

Eventually, Turkey3 had the idea of radically changing the account request system in a way that would be clearer. Instead of requiring users to search through the Wiki, we required them to look through an example article with a number of mistakes and then provide suggestions on both what mistakes to fix and also what they would add to the article. The quality of requests generally increased after that point, and we have maintained that system ever since.

Conclusion

As I continue on my journey in life, I am very proud of the work I did for the Scratch Wiki. I am also extremely proud of all the contributors who have helped maintain the project and continue to do so. It is an extremely valuable resource for helping kids learn Scratch and also helping more advanced users expand their capabilities. It also serves as a place for the Scratch community to collectively store its knowledge, even as individual members come and go, allowing anyone to learn about ideas that no active user may be able to help with.

Leave a Reply