Scratch Wiki talk:Community Portal/Archive 119

This page is an archive of Scratch Wiki talk:Community Portal. Please do not start new conversations on this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Community Portal Archives

Relax S:NOSP even more

Okay, so the English wiki is obviously by far the most restrictive wiki out of the nine. Especially strict is our rule against user-generated content, S:NOSP. That rule was recently relaxed, to the point where as long as there is at least one Scratch Team member involved, it is allowed.

I feel like we could write so many more articles and have so much more activity, however, if the rule was relaxed further. I propose a relaxation of the rules to the following points:

• All of the following are still prohibited:
  • All Scratch-prohibited things, including userscripts, iO, and the like
  • Particular projects
  • Certain forum topics or posts
  • Specific studios
  • Individual users
• Advertising gets kind but firm warnings, three warnings is vandalism, twice vandalism is a block.
• All user-generated content articles must have a template denoting them as such.

That means no Paper Minecraft, no Sigton's Shop, no Scratch OS Studio, no Griffpatch; articles about anything else should be allowed by default.

For a quick rule of thumb about what crosses the line under this system, basically specific things are prohibited but collections of them are okay. (Things like studios as collections of projects and forum topics being collections of posts notwithstanding.)

---

If you think these rules are too relaxed for mainspace articles, I have an alternate proposal. A separate namespace for articles about user-generated content, subject to the following rules:

• All Scratch-prohibited things remain prohibited (follow CGs, people!).
• Everything else is a go.
• Advertising will be treated almost as severely as vandalism, thrice advertising is a block.
• The entire namespace is treated as non-content pages (i.e. it's not indexed by default and isn't counted in the {{NUMBEROFARTICLES}} (1,495)) [this rule is open for debate].

The namespace name would be something relevant, e.g. "User Content:" or "UG:" or something.

---

Which idea would you prefer? What are your thoughts?
kenny2scratch  Talk  Contribs  Directory  22:09, 5 August 2018 (UTC)

How will this actually help the Wiki? I feel that you're trying to relax these rules for the sake of having them. What kind of user will go onto the Scratch Wiki and read about a user? How many Scratchers will actually be interested about reading about the development stages of Paper Minecraft? None. I also don't understand what you mean about your warning system. What is the difference between advertising and user-generated content? The line is very, very fuzzy between them. If you're going to give out warnings, at least be specific about what will get you a warning, and what is allowed.
Daring Sailor [ Talk | Contribs | More... ] 08:53, 6 August 2018 (UTC)

As one wiki's admin, here's some examples that are not allowed here but allowed on jawiki.

List of Featured Projects by Japanese

Scratch Day Article in Each Year

Japanese Forum's Topics

0%control, 0%if

CoderDojo

Snipetch - would be allowed before the new mod rule

Apple502j Talk/Activities 2,243edit 13:25, 6 August 2018 (UTC)

Drunken_Sailor - I think it was that things like Paper Minecraft wouldn't be allowed.
bigpuppy talk ▪︎ contribs 20:37, 6 August 2018 (UTC)

@Bigpuppy But in the second proposal, it states: "Everything else is a go". Meaning projects such as Paper Minecraft will be allowed. There is no line at all between what is advertising and what is allowed.
Daring Sailor [ Talk | Contribs | More... ] 20:58, 6 August 2018 (UTC)

Apple502j CoderDojo would be allowed as far as i know.
asqwde talk | contribs 05:54, 7 August 2018 (UTC)

@D_S I said how it would help the wiki at the start of the second paragraph: it would increase activity and allow us to write many more articles.

"Relax[ing] these rules for the sake of having them"? That doesn't even make sense - relaxing rules means not having them as strict.

Users and things like Paper Minecraft would only be allowed in a dedicated non-content namespace anyway, so you're exactly right there; it's just that pages like those are meant to be linked to, rather than searched for (e.g. someone could document Paper Minecraft and then griffpatch might link to the page from his project).

It's not a warning system, it's just an expansion to the current one. Our current policy is that we warn users once for vandalism, and the second time we block. In my first system, advertising in a usergen article three times would count as vandalism. In my second system, advertisement in an article in the usergen namespace would immediately count as vandalism (or almost vandalism, since you get three chances not two).

I know that there is a fine line between advertisement and user-generated content; that's why I ask that policing of advertisement in usergen articles be more strict than normal, tending more towards false positives than missed cases (in layman's terms, catching advertising when it isn't actually advertising more than missing things that actually are advertising).

@jvvg Here are some things that would be allowed under the first system:

• Shop Federation as its own article
• "The Shop Federation", also as its own article (it is a collection of shop forum topics, and not any specific shop, therefore it is allowed)

And some things that would not be allowed:

• Paper Minecraft
• Griffpatch

Here are some things that would be allowed under the second system ("usergen" is the name of the namespace, feel free to debate on this namespace name):

• Usergen:Paper Minecraft
• Usergen:Griffpatch

Here are some things that would not be allowed:

• Usergen:Discord
• Usergen:isOnline

I hope I've cleared up that my "warning system" is merely an expansion to our current system, and explained what exactly would be allowed or not.
kenny2scratch  Talk  Contribs  Directory  06:50, 7 August 2018 (UTC)

Okay, I misworded my first bit. I meant that I feel that we're trying to relax these rules for the sake of relaxing them. What good does having articles about user generated content do? If griffpatch wanted to tell his followers about Paper Minecraft, he'd do so in the project notes, not in some Wiki article that he can't even edit anyway. The whole thing still seems a bit pointless.

Just saying "I know that there is a fine line between advertisement and user-generated content" doesn't actually specify where that line is. It's like saying that my house is next to my neighbour's house: It doesn't specify anything. For example, if Usergen:Paper Minecraft and Usergen:Griffpatch are allowed, then could I create Usergen:Drunken Sailor? Or maybe, if it suits you better, Usergen:Late in Space or Usergen:Soulless 0? What classes as advertising, and what does not?

Aside from this, I still fail to see the point and use of doing this. It would "increase activity and allow us to write many more articles", would it? If we wanted activity, we could just enforce a mandatory mainspace edit every day. All in all, this just seems like an attempt to boost... certain users' editcount.
Daring Sailor [ Talk | Contribs | More... ] 08:21, 8 August 2018 (UTC)

Have you considered that griffpatch would want to get an account for the sake of documenting his projects?

I know it doesn't specify where the line is, but you need to understand the fact that nobody knows where the line is. Can you truly say where the line is between advertising your project in another project's comments, and simply describing its purpose without encouraging them to check it out? In the first system, projects, users and so on are still disallowed, and what is allowed is likely impossible to link to. In the second system, it doesn't make sense to not link to the particular thing it's documenting, so you can't draw the line there, but where you can draw the line is between documentation and promotion.

Documentation means description. Explaining how the project works, listing different features; documenting the user's past actions, clarifying misconceptions about their personality.

Promotion means prescription. Recommending that the reader visit the project page, even give it a love or favorite; stating opinions about the user's quality of work, suggesting that the reader drop them a follow.

The line between documentation and promotion is one we already draw in mainspace articles: if there is an opinion, it is advertisement and must be removed. If there is merely an explanation, it can stay.

Under the second system, you could totally create Usergen:Drunken Sailor - you just could only document yourself, not advertise. I could just as easily create Usergen:Late in Space or Usergen:Soulless 0 (though why would I, ew), but again they would only be for documenting how the projects work, not stating opinions about their quality.

And yes, it would allow us to write many more articles! And no, we could not enforce a mandatory mainspace edit every day; what would the punishment be? how would we make up for the users scared away by the requirement of activity every day? And who are you accusing of having their edit count boosted? I certainly wouldn't be editing usergen pages, I have too many months of prejudice behind me. This would simply present more opportunity for articles to be created and edited, therefore increasing the general amount of activity.
kenny2scratch  Talk  Contribs  Directory  08:53, 9 August 2018 (UTC)

I have been a proponent of relaxing S:NOSP for a while but not in the way proposed here. My ideas concerned the documentation of articles supported by the Scratch Team. Our first S:NOSP revision accomplished this already. Therefore I'm going to have to vote against this measure. I felt that it was appropriate to write articles about certain stickies such as The Shop Directory, while including others in the actual forum page descriptions specifically. These are all reviewed by Scratch Team members and through their sticky status recomended to the community. The "shop federation" (an idea cooked up by CrazyGoldFish3 and myself incidentally) can be mentioned in the one line description of "types of shops" (nothing against documententing the existence of that type of organization). While I would love to celebrate CrazyGoldFish3's work on the first Shop Federation (*cough cough* Chief Justice in the house), I'm not sure that it was really sponsored by the "Scratch Team". When it comes to making these determinations, people will also want to document the current establishments (maybe SPA in terms of Shop Federations; I haven't really checked in a while) which they are a part of instead of the historical predecessors. I'm not going to claim full credit for the "shop federation" idea, but I will say that it had its roots in a program at "MakeTheBrainHappy's Shop" (still like the 2nd largest shop ever & was the largest ever) called "Sub-Shops" where people would partner up and we would provide collective support to one another. Since this program (& many others) existed, does that validate my shop getting its own article. One could argue that it had as great or even greater an impact that the Shop Federation idea.

I honestly believe that the line between allowed and "not-allowed" is blurred in this case and would be in many others that we would consider. But if you were to grant an article to my shop, you would also have to grant one to Sigton's Shop (even though I was voted in as the 3rd Co-Owner I still have no idea what ever happenend there...) since it ended up being larger.

Now to your UG section. First read this: Conflict of interest. People usually assume the size of someone's page corresponds with their importance (i.e. a president has a larger wikipedia page than a local town official). If people are writing their own pages and don't need to provide any disclaimer about it, then they can really make their pages large & thereby inflate their own importance. I believe that the Userspace is the best place to put your own content about whatever. People should realize that you can use the userspace to write articles about whatever you wish and write your entire biography.

I vote against the idea and will not reconsider until major revisions are made on the scope and definition of these concepts.
Makethebrainhappy (talk | contribs) 13:24, 10 August 2018 (UTC)

For reasons stated by MTBH, as well as my reasons stated above, I'm also going to have to vote against the idea.
Daring Sailor [ Talk | Contribs | More... ] 17:56, 10 August 2018 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ @D_S: that is a complete non-reply, try to only post messages when you have something new to say

The idea's core in the first place is allowing matters that are not "sponsored" by the Scratch Team. Requiring Scratch Team involvement severely limits the number of subjects we can document (as most of the ST aren't known for being active in multiple places).

If blurring the line is a problem, I would think you would go with the first idea, since the line between allowed and disallowed is the line between a single item and a collection of items (studios and forum topics are treated as single items).

Your example of refusing an article about the first shop federation is besides the point - you say it's not sponsored by the Scratch Team, but the whole point is to relax that guideline.

If you think userspace is a good place, what's wrong with the second idea? Userspace is just a namespace; a "usergen" namespace would also just be a namespace. The only difference I can see is that userspace makes it obvious who the page is affiliated with; usergen would not. But that's easily solved by writing a small extension that displays who created the article at the top of the page, or in some other way make it clear who the page is affiliated with (the extension could also add the namespace in the first place).

About whether "Makethebrainhappy's Shop" would get an article: if it's more than just one forum topic, then it would get an article under both systems; if it's just one forum topic then the first would forbid it, while the second would allow it (as long as it's documentation, not advertisement). Same goes for Sigton's shop.

About conflict of interest (assuming second system): we don't have paid editors (as far as we are aware, at least I do this unpaid full-time), so the financial relationship part is irrelevant. I see that there could be a problem if a user on the Wiki attempted to write an autobiography in the UG namespace; perhaps we could follow Wikipedia's example and disallow people directly related with the subject to contribute to it, as well as requiring people to disclose any indirect relationship with the subject when editing.

On a different note, please don't post inflammatory comments. "will not reconsider until major revisions are made" is far too blunt to be acceptable here - I had to prevent myself from swearing at my screen when I saw that, and I'm sure you've worsened the mood of any others who support the idea. You're here to constructively contribute ideas and bring up issues, not to subtly insult the topic without pointing out the problems. You can say things like "Unless you show how this would work, I don't think I like this idea at the moment"; things like "I will not reconsider until major revisions are made" are unnecessarily defacing to the topic at hand. Try to remember this in future replies.
kenny2scratch  Talk  Contribs  Directory  04:24, 22 August 2018 (UTC)

"@D_S: that is a complete non-reply, try to only post messages when you have something new to say" - I'd like to clarify something for all the other wiki editors reading this. Ken is obviously very attached to his idea and want's to discourage people from disagreeing with it. The main point is: You do not need to have a novel contribution in order to state your agreement or disagreement. Knowing that someone feels one way or another is useful information and I hope that people feel that they can express their opinion. There will be no disciplinary action as a result any such comment and I encourage Ken to keep his opinion on the comments merit to himself.

"The idea's core in the first place is allowing matters that are not "sponsored" by the Scratch Team" - Let it be known that Ken wishes to document User-Generated content on the wiki mainspace. If this change were made, then all User-Generated content would be permissable. because everything is a collection of items. My profile is a collection of projects, my website a collection of posts, and my forums are a collection of responses. And yes we may disallow those items but we aren't really either.

CrazyGoldFish3 actually told me once why the ST refused to endorse the idea and the story went something like this: In 2013, they stickied a more "activist" directory with programs similar to Shop Federations, but then an issue arose and it was unstickied. Since then they haven't supported user-generated "collaborations" as it relates to the requests forum.

The reason why I think the "usergen" namespace is a bad idea is because it encourages competition among wiki editors as if it was a "popularity" contest. The usergen namespace is supposed to document accomplishments while the userspace is just like a personal bio (which is pretty obvious when one looks at all of pages). Knowing who wrote the page doesn't help a lot because I can just send my written article to you and have you post it.

Many, many things would deserve their own articles if MakeTheBrainHappy's Shop gets one. I mean we can't even document every SDS Studio individually. How are we supposed to document every Scratch Collaboration that is notable? Then go consider the Services Planning Department and try to pass judgement on it. I know you want to, but these judgements will just become more and more arbitrary over time.

There is no good way to get people to disclose conflicts of interest and enforce those policies.

It also seems like I didn't state my views clearly. This is a terrible idea. I hope I've convinced others of that. We've already relaxed S:NOSP once; we don't need to do it again. If you think that what I wrote before is "inflammatory", just imagine the kind of debate that we would have after this policy is implemented as we argue with people who want their User-Generated content in the mainspace. Debunking this change is the whole point Ken, but I won't attack you personally even though you attacked both Drunken and myself for our dissent.
Makethebrainhappy (talk | contribs) 16:18, 22 August 2018 (UTC)

Just a note on something you mentioned, Kenny2scratch - "Userspace" isn't simply a "namespace" (words in quotes you used); as is mentioned in Scratch Wiki:Userspace, images are also part of userspace (when they are in categories that declare it, such as Users' Images and Users' Logos), and parts of personal talk pages. So, I guess what I'm saying is that userspace is multiple namespaces. Or, rather, a namespace plus a certain section of another namespace, plus parts of another namespace ("User talk:").

Makethebrainhappy, I don't think we should be that, well, you know what I mean (near the end of your post). Constructive criticism is good though.
bigpuppy talk ▪︎ contribs 17:05, 22 August 2018 (UTC)

Ken did not think I was honest enough.
Makethebrainhappy (talk | contribs) 20:17, 22 August 2018 (UTC)

Accusations of hypocrisy won't help anything, either, but I digress. And yes, that's exactly the point. Having all user-generated content being permissible (within the limits I set above) is the entire point of this discussion. I know you have a bias against documenting user-generated content - so do I, and you have no idea how much I'm having to force myself to write this because I believe it would increase activity.

Let me once again restate that documenting user-generated content is not a bad idea. The major advantage of it is that activity would increase further as more content could be written without fear of breaking guidelines. How many ideas of yours to increase activity have been too complicated (or, on the flip side, too simple) to be accepted? The only solution to increase activity is to increase the amount of activity that can be had.

To put it in different terms: Scratch's design goals are "low floor, high ceiling, wide walls". "low floor" means anyone can get started, and it's not too hard to pick things up. "high ceiling" means there can be incredibly complex creations, as well as simple ones. "wide walls", the point I want to focus on here, means a wide variety of creations can be made.
Our account request process notwithstanding, I'd like to believe we have a low floor. You don't have to use Wiki markup to write articles, though others will certainly come along and improve it to do so. And once you've learned some markup, it's pretty easy to pick up the rest. We certainly have a high ceiling - look at complex pages like Scratch@MIT 2018 (oh yes, it's complex!) or anyone's sidebar. However, our walls are incredibly narrow. We are constrained by the limit of having Scratch Team involvement in anything we document.

Our mission is to document the Scratch programming language and its surrounding phenomena. The community, as well as community projects, are part of the surrounding phenomena. We would be shaming ourselves if we didn't document them.

"Knowing who wrote the page doesn't help a lot because I can just send my written article to you and have you post it." That's not true - I already said we would follow Wikipedia's example, and require disclosure when there is a relationship between you and the subject of the article. Even if you only told them to post the article, that's still a relationship of sorts.

There's no way to force someone to disclose affiliation, that's true, but it's perfectly possible to strictly warn people who are found to have not disclosed affiliation. It's also usually evident from the posted content whether they're affiliated; and if they are affiliated but their content seems otherwise, then that's just as good as being not affiliated anyway, since the major danger of affiliation is that it could be advertisement.

I know we can't document SDSes individually. (By the way, "SDS" stands for "Scratch Design Studio", so "SDS Studio" as you said would mean "Scratch Design Studio Studio" lol.) If you're worried about a flood of tiny articles, a minimum size requirement wouldn't be amiss. Or, if you think pagesize doesn't accurately represent content size (a point I agree with), we could have a minimum readable prose size instead.

I didn't mean to say "only post when you have something new to say", that was blurted out due to the anger at your last statement before then. I think what I actually meant was "if you have an opinion, justify it in your post instead of simply restating it". My mistake there.

@bigpuppy: I do realize that userspace rules encompass more than just the "User" namespace, but that's irrelevant - you wouldn't document yourself in a users' image anyway.
kenny2scratch  Talk  Contribs  Directory  07:21, 23 August 2018 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ I'll visualize it for you. I'm going to hold out two colored cards (choose whatever color you like). One says "people" on it and another says "idea." Here is what my statement concerning the people: "You do not need to have a novel contribution in order to state your agreement or disagreement. Knowing that someone feels one way or another is useful information and I hope that people feel that they can express their opinion." I will not think anything less of anyone (including you Ken) for expressing your opinion. The other is the topic at hand which is the idea being discussed. I do hope that I have persuaded others that it has little merit, but if I haven't, then I should know that. I wouldn't think any less of their character if they still agreed with this idea at this point. You on the other hand have gone after "character" by asking Drunken to stop giving his opinion & for me to be nicer to the idea. There is no hypocrisy in us taking different sides and arguing the case. You have just decided to use your gravitas to influence how people respond (i.e. don't respond unless you are ready to argue with me or don't respond unless you are willing to provide constructive suggestions to improve the idea). I'm not going to make those arguments. Anyone may respond with their opinion and if they add logic to it, then we can discuss it's merits. If there is no logic, then it becomes another consideration. If people are against the idea, then they can either provide suggestions for improvements or not. I'm not forcing comments to undergo the standards which I myself am creating as I read them. All I can do is respond to those which make arguments. In summary: I'm not trying to force people to express their opinion in a certain way; rather, I'm trying to convince them of an argument. I'm sure that Drunken will accept your apology. I think the limit's are arbitrary and will just cause more problems then they solve. The rest of your impassioned speech is very nice and dandy, but I'm going to skip making a similar contra-idea because I want to reevaluate what was said. you have no idea how much I'm having to force myself to write this because I believe it would increase activity. - This is what resonated with me not because I feel that it vindicates me, but because it is actually the underlying cause of this discussion. This is where I can provide constructive suggestions. But first let's do this exercise. Whoever is reading this ask yourselves these questions: "How do you visualize the scratch community?" & "Do you believe that the way you visualize the scratch community is similar to how another person visualizes the community?" The reason why the earlier system worked was because we had a common narrative: 40-someodd Administrators; the studios they were associated with; the announcements forum; etc. This would be lost if we began documenting UG- content. Now onto the suggestions: If we are looking to increase activity, then we should be finding more active editors (*shoutout to the New Member Recommendations). We aren't going to get the kind of editors we want if people are joining to document User-Generated content. On the hand: Maybe we should focus on increasing our exposure. Increasing the traffic to the wiki increases our prestige and importance for the overall scratch community. That could in turn drive more high-quality editors to the wiki. How would we accomplish this? Well maybe we could have a namespace for creating articles about programming in general and not just scratch-specific material. This would be in the general line of our mission of promoting Computer Science and provide information to Scratcher's seeking to move to text-based languages. Now there are articles like "Python" which document the language briefly, but the namespace would expand on this by providing specific tutorials in Python which would appeal to a more general audience. If we were able to focus on gaining exposure through search engines online, it would help scratch by driving traffic towards the main website. Here's the way I think about it: Would we get more traffic from 40 user bio pages or 40 high-quality python tutorials? Which one better represents our mission? Our main purpose is still to document the Scratch website which is why I propose creating a new namespace for Python (or maybe even general programming). I think it's a better solution to deal with the activity issue.
Makethebrainhappy (talk | contribs) 15:27, 23 August 2018 (UTC)

Tip: use two line breaks when you're the outdented reply

I'll only be responding to the actual suggestions, since those are the most to the point.

New Member Recommendations are a good idea, but they don't seem to have been gaining any traction. That obviously suggests that something's missing, but that's a different story.

The Scratch Wiki is a collaboratively-written wiki documenting the Scratch programming language and its surrounding phenomena. Our mission is not to promote CS; our mission is to document Scratch. Documenting other languages is worse than user-generated content (which is at least related to Scratch), unless the purpose of documenting the language is specifically in relation to the language's integration with Scratch. We are not Wikipedia - our mission is not to document everything. If people want to get documentation of other languages, they should search on Wikipedia.

"Would we get more traffic from 40 user bio pages or 40 high-quality python tutorials?" The Python tutorials, but "Which one better represents our mission?" The user bio pages.

That being said, your points imply a series of tutorials on moving from Scratch to other languages. Tutorials like those would probably be a) much welcomed and b) quite useful, and would stick to our purpose. But that should be in a different section; propose it in a different topic.

Our mainspace purpose is to document Scratch and its phenomena. I stick by my belief that user-generated content is part of Scratch's surrounding phenomena, and that we would be worse off for not documenting it.

As to your point about not wanting users to join only for UG pages: we could have a "one mainspace edit per ugspace edit" requirement, as in for every edit a user makes in the UG namespace, they have to have a mainspace edit as well.

"I think it's a better solution to deal with the activity issue" - I disagree, unfortunately, since writing such tutorials requires rather expert knowledge (or at least not just vague concepts), and it would only increase the activity of those who are already active.

Looking at all your points, though, it seems pretty clear to me that UG pages should not be treated as content pages :P
kenny2scratch  Talk  Contribs  Directory  05:11, 24 August 2018 (UTC)

Okay <removed - you know my views>, calm down.

First, I have never seen anyone use, ever, or be told to use, ever, two line breaks after an outdent. If anything, that tip seems to be done out of spite

Second, please stop being so toxic. If you want people to listen to you and appreciate what you’re saying, not accusing or swearing at them might help. If somebody states that they do not agree with the idea, accept it and move on. Everyone has a right to freedom of speech.

Third, "Would we get more traffic from 40 user bio pages or 40 high-quality python tutorials?" The Python tutorials, but "Which one better represents our mission?" The user bio pages." makes absolutely no sense. If we want to widen our range of articles, which you want to do, then we should follow MTBH's suggestion of Python tutorials because it branches out of Scratch and opens a whole new world up for Wiki Editors, which, as you want to do, would increase activity. Python tutorials, which you could actually help with, would also increase the Wiki's exposure (which, may I remind you, is one of the Wiki's goals, as said by MTBH) massively because people who don't even know what Scratch is can use our Wiki as a reference for Python tutorials. This would grow the Wiki from catering for a small community to supporting a large community as they grow and learn. It would, as you’d say, "widen our walls". By limiting the people we cater for, we lose exposure for the Wiki, and subsequently can help less people. Now what do you think better represents our mission?

Fourth, "you have no idea how much I'm having to force myself to write this because I believe it would increase activity". If you’re forcing yourself, then why are you arguing so fiercely for it, and accusing others when they disagree? If you want to increase activity, why don’t we just encourage new & existing users to make constructive edits on useful mainspace pages. Edits on Usergen pages would rarely be useful as they would mostly be either biased or unnecessary, causing a drop in quality on the Wiki. As MTBH said, "We aren't going to get the kind of editors we want if people are joining to document User-Generated content". Editors would join for the sake of editing User-generated content pages, which would have no real use to anyone not directly connected with them.

Fifth, you said that with Usergen activity would "increase further as more content could be written without fear of breaking guidelines". However, you’ve still not explained what the guidelines are. As I said way back in my first post: "The line is very, very fuzzy". What classes as a good usergen edit, and what would you revert as vandalism/advertising?

Sixth, just stating who created the page at the top doesn’t change anything. If anything, it makes the system worse because users would compete to see who could create the most articles. Basically, it would become another way of users to see who is the best, which is the opposite of what we want. Wouldn’t writing an extension also just cause more complications and confusion?

Seventh, how would we force disclosure of affiliation? Even if we managed a way to do that, where would it be disclosed? In addition to this, most edits would need disclosure anyway, since you can’t create or improve an article which you have no knowledge about.

Finally, even if we solved all these other problems, you’re stating way too many requirements for this to actually be functional. For example, how are you going to enforce one mainspace edit per one usergen edit? As you said to a separate proposition: "what would the punishment be? how would we make up for the users scared away by [it]?", which is exactly my point here.

What about the "minimum size requirement"? How would that be enforced? Wouldn’t it also prevent new(er) users who want to create an article but only have limited knowledge from furthering the wiki’s information?

That pretty much wraps up my long post. TL;DR: This is a terrible idea and has so many flaws that, even if you had the whole community backing you, it wouldn’t be worth the time and energy fixing them.
Daring Sailor [ Talk | Contribs | More... ] 11:37, 24 August 2018 (UTC)

...the tip was supposed to be genuine, when you outdent a single line break doesn't actually break. It takes two line breaks to actually break without indents.

I don't see how I'm being toxic, but that's a different matter that I think would belong on my own talk page.

Branching out of Scratch doesn't excuse being not Scratch. Tutorials only about Python aren't even related to Scratch, and this is the Scratch Wiki, not the Python Wiki (which incidentally already exists). Our mission is to document Scratch - how do Python tutorials represent that mission? The only kind of Python tutorial that has a place on this wiki is one about transitioning from Scratch to Python, or integrating Scratch with Python (the latter of which I think exists). Sure, tutorials relating to both Scratch and another language would help widen our walls, and I hope whoever else is reading this topic makes one (I can't make a tutorial about transitioning from Scratch to Python, seeing as I learned the latter first and the former second and never really transitioned between the two). Increasing traffic is a secondary goal - the primary goal is to document Scratch. We don't want people to come here for Python tutorials that have nothing to do with Scratch - that defeats our entire purpose as a wiki! What we do want is one of the following:

• People who have already encountered/learned Scratch coming to see how they can transition to other languages
• People who have never heard of Scratch learning about it and joining its community because they read articles on this Wiki about Scratch

"encourage new & existing users to make constructive edits on useful mainspace pages" yeah, we've been trying to to this for 10 years now (the Wiki was created in 2008 iirc). Doing what we've always been doing hasn't yielded any results - so I'm proposing getting rid of our old biases and opening up to an opportunity to have a more healthy buzz. Yes, biases. That's why it's hard for me to say all this - I'm biased against user-created content being documented here, so I certainly wouldn't participate in it, but I want to give others who have no such bias an opportunity to document much more than before.

I already stated the line between documentation and advertisement: opinions are advertisement, explanations are documentation. If someone made an edit saying "This project can be viewed here: link" that would be acceptable (assuming 2nd system); if someone made an edit saying "This project is of high quality and should be viewed here: link" (notice the formality but opinion nonetheless!) then it would be advertisement and reverted.

Writing an extension isn't that difficult (at least for me, anyway :P), especially for a simple purpose such as this (add a parser hook, quick db query, done). Users competing to get the most articles - you would have to have a page that lists all the/the number of usergen articles they had created, which obviously would be unnecessary. I do now realize that there isn't any point showing the name, though, so consider that point dropped.

Forcing disclosure of affiliation is difficult, and I have no immediate ideas as to how, but I think I already mentioned it would be (I hate to use the word "punishing") reprimanding for lack of disclosure, rather than preventing said lack. Disclosure can simply be in the edit summary, something like "(note: I am a member of the board of directors of this federation)" (I obviously don't know much about shop federations, it's just an example). If you have little knowledge, research for more! If the subject is worth documenting, there'll be plenty to document. How a shop federation works is certainly enough for reams of material, and that's not the only aspect of a federation to document; under the 2nd system, if a project is sufficiently complex then there will be much to describe.

You often ask, "How would this be enforced?" In the case of a one-mainspace-one-ugspace edit requirement and/or a minimum readable prose size, it could be technically enforced - you would be physically logically unable to submit a new usergen article without a certain minimum size, or edit a usergen article if you have less mainspace edits than ugspace.

"What would the punishment be? How would we make up for users being scared away by [it]?" Assuming you're talking about lack of disclosure, since minimums can be technically enforced, I think a warning system similar or slightly greater in severity to WM warnings would be sufficient. For first infraction, remind them of the guidelines; for second infraction, bring up the possiblity of a block (worded as "the Wiki may not be the best place for you"); for third infraction, make that possiblity obvious; for fourth infraction, block for a certain amount of time that grows exponentially with each subsequent infraction.

As to why there are so many rules/requirements, that's the nature of partially relaxing rules here - a single large rule, bent only a small amount, becomes many small rules. Our rules go mostly along the lines of "if it's not forbidden it's allowed", and while a blanket ban is simple, relaxing it a tiny bit turns it into minor prohibitions of everything except what we want to allow.

kenny2scratch  Talk  Contribs  Directory  12:14, 24 August 2018 (UTC)

Do you still want to try this?
Makethebrainhappy (talk | contribs) 23:27, 22 January 2019 (UTC)

I still believe that this is a good idea; if you have further arguments to make go ahead and post them.
kenny2scratch  Talk  Contribs  Directory  05:48, 23 January 2019 (UTC)

Ken, what do you mean when user-generated content WOULD be allowed, but then you go on to say about how Paper Minecraft, OS Studios, and Griffpatch (which are all UG content) WOULDN'T be allowed?
NYCDOT [ Talk Page | Contributions | Directory ] 20:15, 15 May 2019 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ I mean that certain kinds of UG content (rule of thumb: anything that is an individual thing and not a collection) would still not be allowed, including users, projects, studios, forum threads, and posts. Anything else that would still be prohibited currently would no longer be.

There's also the second option, which is to allow everything, but anything prohibited by NOSP now would go under a new namespace. Which would you prefer, or do you think neither of them works for some reason?
kenny2scratch  Talk  Contribs  Directory  05:18, 18 May 2019 (UTC)

RE: Option 1-Well then what would be allowed? A separate article on Shop Federations, and in it describing what it is, the different federations, and links to them, but it doesn't go on to say about how awesome the USS is or how awful the SPA is or something like that.

E: Option 2-No way! There would be too many people requesting for articles about their latest project, their "coolest" studio, their largest shop; and it would just get overwhelming!
NYCDOT [ Talk Page | Contributions | Directory ] 22:14, 18 May 2019 (UTC)

Ok, can we mark this as done since it appears everyone except you doesn't seem to like this idea? (no offense)
NYCDOT [ Talk Page | Contributions | Directory ] 22:20, 12 June 2019 (UTC)

No. I still remain unconvinced that this is a bad idea, and popular vote is not the final say against a proposal.

Responding to you:

Option 1 doesn't relax the rules much, actually, but yes, there could be a separate Shop Federation article which could even describe/somewhat document more notable federations; only articles about individual federations would be prohibited.

Option 2: Many people requesting for articles is exactly the kind of activity the relaxation is meant to promote. And remember, nobody's under any obligation to obey the requests, but if they choose to do so then there's really nothing against them creating something like "UG:Cool Studio 24" because that would lead to more activity which is healthy for any wiki. (Keep in mind that UG articles would still be somewhat subject to our notability and documentability rules! That means no articles about anything if there isn't much to say about that thing.) And if you're worried about people only editing UG articles, we could easily have rules requiring that each UG edit be "paid for" by a non-UG or even mainspace edit.
kenny2scratch  Talk  Contribs  Directory  11:09, 26 June 2019 (UTC)

About your second proposal: don't articles about user generated content already belong in userspace? And what is the good in promoting activity if it isn't furthering the Scratch Wiki's goal of documenting Scratch?
Jonathan50 (talk | contribs) 08:10, 27 June 2019 (UTC)

What is the point of having more activity to the wiki if this won't help it? "Many people requesting for articles is exactly the kind of activity the relaxation is meant to promote." Why? Scratchers probably wouldn't actually want to read about someone else's studios, or anything like that. UG content should belong in userspace, which has far less activity than mainspace, which is healthy, because mainspace actually helps document Scratch.

And what do you mean by for each UG edit, there should be a mainspace edit? Scratchers that get accepted, if that rule was implemented, would pay less attention to their edits on mainspace, simply because they would want to edit UG content more, if that makes sense. Users should focus on mainspace editing, not just UG content.

For now, I disagree on this idea.
TenType (talk | contribs) 20:25, 29 June 2019 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ First, Will somebody want to read these posts? Umm, I think probably not. :)

To my opinion, people should create their user-generated context but it can be harmful for the wiki, so we should create a limit to create an user-generated article to prevent vandalism.
Ahmetlii (talk | contribs) 20:45, 10 May 2020 (UTC)

I don't think this rule-change is a good idea at all. It's far too complicated, and I don't see any point in increasing activity on the wiki just for the sake of increasing activity. As you've said, kenny2scratch, we are not Wikipedia, and opening the wiki up to articles on the thousands upon thousands of projects, studios, users, etc. on Scratch would just be too much to document. And for what? What's the point of documenting random users, studios, and projects? People can go check it out for themselves on the Scratch website if they want to see it, no need for an article. I don't believe that the activity that this would bring in is the right kind of activity for this wiki. Aside from all this, Drunken Sailor's last post sums up all of my thoughts on the matter very well.
Groko13 (talk | contribs) 19:43, 8 June 2020 (UTC)

Well, user-generated content would probably clog up the wiki. We'd need another wiki to provide information about the content, like the one I recently created here.
ssvbxx (talk | 416 contributions | Scratch profile) 02:22, 26 February 2022 (UTC)

@Ahmetli, yeah, I only was able to read half of it. I had to take a break and read the rest. Just a general tip- add frequent line breaks in long posts.

Also, @kenny2scratch, why exactly do you want to relax the rules? According to me, they're fine now, and no offense, but you've warned me when I broke one of these rules so it seems like your support them?
Vdiu (talk | contribs) 13:51, 10 August 2022 (UTC)

Block Problems

Resolved (since 03:50, 31 January 2025 (UTC))

Today I started to finish up the script for How to Evaluate an Expression, and things got out of hand. When I first completed it, I realized I did some of the block loops wrong, and it like wrapped around some things that I didn't want to wrap around, while I also couldn't get this one if then else block to wrap around something else — it was all a mess. I cleaned some of it up, but I am afraid I'll make it worse and I already spent more than an hour on it. Also, I have to save it each time I want to check if it is correct, since for some reason the blocks won't load up in Show preview mode (it appears in code) but loads when the changes are saved. Can somebody please fix up the script to match the one in post #19 in this forum topic?
TenType (talk | contribs) 04:22, 22 May 2019 (UTC)

The blocks still don't match the one in the post, I tried again on my sandbox and it still does not cut out. Anyone who is an expert at doing this?
TenType (talk | contribs) 05:09, 24 May 2019 (UTC)

You can use this page.
Ahmetlii (talk | contribs) 07:34, 24 May 2019 (UTC)

Curse Garamol56 for not using forum scratchblocks!
kenny2scratch  Talk  Contribs  Directory  13:47, 25 May 2019 (UTC)

@Ahmetlii That website may come in handy...

@kenny2scratch Yes, it is so exhausting to convert it into proper scratchblocks!
TenType (talk | contribs) 19:07, 25 May 2019 (UTC)

Wait, is it possible to convert forum scratchblocks to wiki scratchblocks????
 Luvexina  Talk  Contribs  On Scratch  03:20, 11 April 2020 (UTC)

<scratchblocks>define scratch</scratchblocks>

It will give:

define scratch

See also: Block Plugin
Ahmetlii (talk | contribs) 20:30, 11 April 2020 (UTC) ┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Hmmm. I'll see if I can help although I'm not sure if I'll be able to.
Filmlover12 (talk | contribs) 18:18, 15 July 2020 (UTC)

After looking at the article, there doesn't seem to be any more broken code, so I'm marking this as  Resolved.
Gdxfor (talk | contribs) 03:50, 31 January 2025 (UTC)

Would this be an ok article?

Would list of stickys in the forums be a good enough article?
Bobcat0701 (talk | contribs) 15:51, 15 April 2021 (UTC)

I'm not sure. Although the forum stickies would be a nice article, I have a few problems with what you're asking here. I'm going to list them here.

1. What forum(s) would be in this article? Announcements? Suggestions? Maybe even Help With Scripts?

2. Would all the stickies be featured here or just the top ones?

Finally, 3. Would this potential sticky topic feature the stickies of hidden forums (i.e. the Welcoming Committee Forum)?

And that's all I have to say about this. Please, answer the questions, because otherwise this might not be an okay article. Thanks for reading.

8bitjake ( Talk Page | Contributions | Directory | Scratch )

16:35, 20 April 2021 (UTC)

1 All but read number three 2 What does that mean 3 I can't add that info since i'm not in any of those groups
Bobcat0701 (talk | contribs) MEOW yes my cat told me to write that. 00:16, 21 April 2021 (UTC)

My two cents (not speaking in my official capacity as an admin here, just my personal opinion) is that this isn't significant enough to warrant its own article. Most stickies are by users (including one by me), and we do not create articles about user-generated content.
jvvg (talk | contribs) 01:07, 21 April 2021 (UTC)

I think that would be unimportant. First of all, here is the lacking points:

1. Is it really possible to maintain an updated list regarding sticky topics? They generally tend to be replaced/unstickied when there's no longer a need for them.
2. It would be a kind of user-generated content. (as jvvg pointed out; though there might be dissident voices questioning this rule, like the opinions expressed in this stale discussion. Under the current policy, it's banned.)
3. I'm not really sure about notability, even though we have had a list like this before the introduction of user-generated content ban.
    ahmetlii  Talk  Contributions  Directory  19:12, 22 April 2021 (UTC)

Can we make all dicussions be on separate pages?

This scratch wiki forum is so cluttered up
PenguinLover1123 (talk | contribs) 19:59, 19 August 2021 (UTC)

 No support. Discussions which only relate to a certain page can be kept on that page, but other discussions that relate to the whole wiki need a central place for discussion. The main page? No, as talk pages for main pages should deal only with issues relating to the main page.
Dhuls (Talk|927 Contributions|Scratch) 20:18, 19 August 2021 (UTC)

Well, separating them and transforming the Portal into a decentralized one will make it worse, and that's actually why we have a portal: to discuss everything about the wiki on a determined space, to enable that everyone is able to participate discussions and noticing it on a faster speed, as well as acting as a noticeboard for important updates on software, wiki rules, etc. The Community Portal is also frequently archived for finished discussions to not to do it too way cluttered. Not to mention that there is a table of contents for finding the topic you're looking for.
 ahmetlii  Talk  Contributions  Directory  20:24, 19 August 2021 (UTC)

Well, the table's really really long...
PenguinLover1123 (talk | contribs) 22:20, 25 August 2021 (UTC)

No support either. Probably, it would be quite annoying when people press 'Random Page' as it will mostly just give them discussions.
Mr-Argon (talk | contribs) 12:22, 10 April 2022 (UTC)Mr-Argon

 No support doing this would make discussions harder to use and would reduce the amount of activity on discussions. (The random page feature only goes to mainspace pages, and discussions wouldn't be on the mainspace.)
CrazyBoy826 | Talk | 8,247 edits | Scratch 16:58, 10 April 2022 (UTC)

Semi-bump: I do not consider the Community Portal's size to be too large or cluttered; the page reaches 125 kilobytes around once every several months when it is archived. Additionally, topics not strictly related to the wiki as whole, such as about individual articles, can go on other talk namespaces, which in practice might reduce the size of the CP.

The Community Portal is manageable enough for all important Wiki discussions to go there; I do not think it needs to be separated out. Putting every discussion on separate pages might not be worth it; doing such might litter the Scratch Wiki talk: namespace, with many topics might only viewed or edited a few times, even basic editing questions.

Although the last replies to this topic were months ago, several other users here are against splitting the Community Portal (which would probably include me as well), although I am unsure whether to consider this discussion done or not.
Jammum (💬 Talk - ✍️ Contribs) 11:00, 1 January 2023 (UTC)

Update on the MediaWiki version upgrade

Hi everyone,

I have mentioned before that we intend to upgrade the Wiki to MediaWiki 1.39. The main thing standing in our way was upgrading all of our custom logic and checking for anything that would be affected by the breaking changes. I am happy to report that I was able to set up a Wiki with all of our custom extensions, and all previously identified issues have been resolved. Some more testing will still be needed to make sure that there aren't any other breaking changes (version 1.39 seems to have a lot of them), but with any luck I'll have another update in a week or two. Thank you to our engineering team for their work in bringing everything up to date, especially kenny2scratch and apple502j.

Thank you everyone for your patience.
jvvg (talk | contribs) 02:34, 28 January 2023 (UTC)

Awesome!
Adzboy • Talk • Contributions • Scratch Profile 08:01, 28 January 2023 (UTC)

Everything looks to be on track, so we are tentatively looking at Tuesday, February 7, for the upgrade. This will result in some downtime (hopefully not more than 30 minutes) and we will give a more specific time once we have confirmed everything is ready.
jvvg (talk | contribs) 20:54, 31 January 2023 (UTC)

Nice, Thanks for the information!
SpaghettiAG852097- talk • contribs • profile 03:00, 1 February 2023 (UTC)

The update will be on Tuesday, February 7, at 9pm Scratch Time. This will result in some downtime, hopefully not more than about 30 minutes. Sorry for the short notice, but hopefully this should be pretty painless.
jvvg (talk | contribs) 17:10, 6 February 2023 (UTC)

Good to know. Luckily, that's not an annoying time for me (It's 2am on February 8th in the UK).
Adzboy • Talk • Contributions • Scratch Profile 06:25, 7 February 2023 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ It looks like the upgrade completed successfully. Please let me know either here or on the Wiki forum topic if you notice anything not looking right. So far the only issue I can see is that a few boxes aren't styled properly.
jvvg (talk | contribs) 02:29, 8 February 2023 (UTC)

I am seeing a lot of changes... first of all the community portal has disappered from the sidebar. Also, a lot of other stuff have dissperared from the sidebar too. It looks very different from before. Also it says "edit source" even though I am not using visual editor. And at the top of each page it says "From scratch wiki" and also in the sidebar it says "Help about MediaWiki" its also EXTREMLY slow. Probably because i am typing this 5 mins after the update...

Thanks
SpaghettiAG852097- talk • contribs • profile 02:36, 8 February 2023 (UTC)

(Edit conflict) For some reason, the text "From Scratch Wiki" is showing up at the top of every page. The site's being extremely slow and buggy for me too.
Jackson49 (talk | contribs) 02:40, 8 February 2023 (UTC)

Pretty much all of this can be explained by caching. The interface cache somehow stored all of the stock interface text and none of our overrides, so I cleared that cache (thank you to kenny2scratch for suggesting that) and it's good now. Similarly the slow performance seems to be getting better, I think also mainly due to stuff being cached.
jvvg (talk | contribs) 02:45, 8 February 2023 (UTC)

Yeah, everything just fixed itself for me, with the exception of the "Edit Source" bug.
Jackson49 (talk | contribs) 02:47, 8 February 2023 (UTC)

I'm not sure what the deal is with "edit source." It doesn't say that on Wikipedia, so it's not just the default for a VisualEditor-enabled Wiki, I'll have to look into it. On the plus side, VisualEditor now works on subpages. The spacing will be kinda awkward since we had to use a janky CSS hack to get it to work in 1.35, but 1.39 may have made that unnecessary.
jvvg (talk | contribs) 02:53, 8 February 2023 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘When you are logged out of the wiki the sidebar looks completely different from when you are logged in. Let me know if you want an image of it Edit:The wiki is more faster now by the way
SpaghettiAG852097- talk • contribs • profile 03:08, 8 February 2023 (UTC)

SYNTAX HIGHLIGHTING IN THE EDITING BOX. ITS GONE. I’m going insane because I can’t see what the elements are easily.
han614698 talk • contribs (2,588) • profile 03:10, 8 February 2023 (UTC)

There’s also a really annoying “Edit Saved!” box that covers up the navbar until you reload.
han614698 talk • contribs (2,588) • profile 03:12, 8 February 2023 (UTC)

Try clicking the highliter at the top of the screen
SpaghettiAG852097- talk • contribs • profile 03:12, 8 February 2023 (UTC)

I kinda like the edit saved box. It looks nice lol
SpaghettiAG852097- talk • contribs • profile 03:13, 8 February 2023 (UTC)

I figured out how to get rid of the "edit source" you just gotta go to prefrences then to editing, then check the "Temporaily disable the visual editor while it is in beta"
SpaghettiAG852097- talk • contribs • profile 03:17, 8 February 2023 (UTC)

The Syntax Highlighter is still there for me.
Jackson49 (talk | contribs) 04:43, 8 February 2023 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Small changes - in the pencil menu, it says edit SOURCE, ADD topic, VIEW history.
han614698 talk • contribs (2,588) • profile 12:38, 8 February 2023 (UTC)

You gotta go to "prefrences" then to "editing" then check the box that says "Temporarily disable visual editor while it is in beta" then it should go away. I do not exactly know why it automatically enabled visual editor for everyone though..

Note:

This does not get rid of the "View history", or the add topic, it only gets rid of "edit source"

sorry for all the spelling mistakes. I don't have autocorrect
SpaghettiAG852097- talk • contribs • profile 14:16, 8 February 2023 (UTC)

I noticed that it shows a not secure warning as if there was no HTTPS, but then it loads with HTTPS fine
-unsigned comment by Ideapad-320 (talk | contribs)

Another thing: VisualEditor works a lot better in this version. It works without any problems on subpages and I remove a CSS hack we needed to make it properly fit on the page before.
jvvg (talk | contribs) 20:15, 8 February 2023 (UTC)

My JS welcomed does not work anymore. Can someone tell me why? (I will leave a link soon)
han614698 talk • contribs (2,588) • profile 21:49, 8 February 2023 (UTC)

Here’s the link to the welcomer. It’s made by Kenny2scratch, but I use it.User:Kenny2scratch/welcome.js.
han614698 talk • contribs (2,588) • profile 21:52, 8 February 2023 (UTC)

It could have already been like this, but both of the buttons at the top of the CP to search the archives (not sure what the difference is) search the entire Wiki instead.
Jonathan50 (talk | contribs) 22:02, 8 February 2023 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘Yes I noticed that too, but if you press the search button it only shows the ones on the CP.
SpaghettiAG852097- talk • contribs • profile 22:21, 8 February 2023 (UTC)

Huh, neither button works for me.
Jonathan50 (talk | contribs) 22:25, 8 February 2023 (UTC)

@Jonathan50 I believe this has been an issue for a long time and isn't new to this version of MW.
jvvg (talk | contribs) 03:08, 9 February 2023 (UTC)

Removal of Scratch Modification Pages

Currently, the creation of pages about Scratch Modifications is disallowed (see S:NP#Modifications), but old pages which were created before this rule were allowed to remain on the Wiki. Times have changed since then, and most of the pages under Category:Scratch Modifications are no longer relevant. Aside from BYOB, basically all of the Scratch Modifications with their own dedicated pages are no longer relevant to Scratch 3.0 or its community, with most people on the website probably having never heard of most of them (not really a "notable example").

As such, I propose to delete all pages which have "(Scratch Modification)" in their title (this doesn't include BYOB, as it turned into Snap!, which is not a Scratch Modification). While this may seem extreme, as I've said, none of the Scratch Mod articles are relevant today, and they're no longer in-line with the page creation rules found at S:NP. What does everyone else think about this?
Gdxfor (talk | contribs) 06:25, 8 July 2024 (UTC)

Alright, let me list all the mods to see if they matter. How-to pages can stay, someone will find them important.

• Snap:  Actively Updated This is our baseline.
• Bingo:  Somewhat Dead Copyright is updated, but the mod is stuck in eternal V2.0 and the website is partially broken. You can still download it.
• Chirp:  Dead but somewhat notable This is one of the first known Scratch mods to exist. Maybe we could work that into some sort of article.
• CoCo:  Actively Updated It's a live collaboration project that essentially mixes Zoom with Scratch 3.0. This is the Snap of 3.0 to me.
• Dream:  Dead This one is just dead. Not really much to write about either.
• Enchanting:  It's not even a Scratch mod It's a Snap mod, why did we write this article?
• Mod Share:  Sadly very dead Servers are up but nothing happens there and jvvg told me it's gone for good.

You get the point by now, most of them are dead but CoCo we keep. If anyone finds any updated 3.0 mods that are already on the wiki yet still updated let me know but otherwise they can be trashed.
Co0lcr34t10ns (talk | contribs) 10:30, 8 July 2024 (UTC)

@Co0lcr34t10ns I think it's safe to get everything with "(Scratch Modification)" in its title as well as Mod Share and Scratch for Second Life due to their lack of updates and relevancy. CoCo (platform) can stay as it's not a Scratch Modification as far I can tell (I guess it's just it just integrates with Scratch without tampering it?). It's not like we're removing all mention of them from the Scratch Wiki, as they can still be listed in List of Scratch Modifications.
Gdxfor (talk | contribs) 12:36, 8 July 2024 (UTC)

Is lack of updates of the thing the page is about a reason to delete a page though? The Scratch Wiki does document the history of Scratch, which these mods could be considered a part of (S:NP says they kept only "notable examples" of mods, so, at least at one point in Scratch history, they were considered notable). Also, is there any harm in keeping the pages?
Mrcomputer1 (talk | contribs) 12:54, 8 July 2024 (UTC)

As mentioned by others, the inactiveness of a page is not why whether we should delete it or not. Otherwise, we should delete most of our Scratch 1.4 pages. Basically, it's either delete them all (to be consistent with the new rules), keep them all (grandfathering), or keep the absolutely notable ones (for "notable example"). Anything else would likely destroy the purposes of all sides. In my opinion, keep them all seems like a good idea since there isn't much of a reason to delete them besides for the sake of rules.

PS: Notable examples would probably mean that the TurboWarp argument would start again, because a lot of people would call it "absolutely notable". Maybe not a good idea.
Purin2022 | 💬Talk | 📝Contribs | 🐱Scratch 20:27, 8 July 2024 (UTC)

@Purin2022, Mrcomputer1 Yes, their inactiveness is not the main factor for wanting to delete the Scratch Mod articles, although it really isn't helping them. CoCo (which is technically not a Scratch mod but whatever) is currently in active development, so when completed, it will probably gain some popularity, especially if it keeps getting updated. Dream (which as far as I can tell has stopped development) does not, at least not in its current state, and will only continue to dwindle in popularity. Every page on the Wiki should strive to have a purpose, and it's pretty hard to argue this with the Scratch Mod pages in my eyes (although feel free to give any arguments against this if you have some). Reasons being:

• Unpopularity: I really wouldn't be surprised if I'm the only person that visited the Dream page in 2023, as it's a 12-year old mod of an outdated Scratch version that's arguably inferior to the likes of Penguin Mod and TurboWarp (these are updated constantly, are based off the current version of Scratch, and are most importantly way more popular than any 1.4-mod in today's community).
• Historical Irrelevancy: All of the 1.4 pages could technically also be classified as "unpopular", but they're relevant because they shaped how Scratch 3.0 is currently. I don't think that Dream has nearly the same level of historical relevancy. The idea of TurboWarp (a mod that speeds up Scratch) isn't something that existed before late 2.0 as far as I can tell, or at least isn't covered by any article on the Wiki. Even if it mods like Dream were historically relevant to mods today, that really should be covered in a "History of Scratch Modifications" article, not in a standalone one.
• Rules: The S:NP#Modifications rule was put in place for a reason (at least I hope it was). I don't know why specifically, but I can think of a couple of good reasons for putting this rule in:
  1. It's basically advertising (user-generated content)
  2. It's not safe for kids (a bad actor could theoretically inject malware into their mod and make an article about it)
  3. It avoids cluttering the Wiki with hundreds of similar/irrelevant mods

What I'm trying to show is that the rule is there for a good reason. The Scratch Modification article shouldn't be evaluated solely on whether it was created before the rule, but rather if it breaks the rule in a way which doesn't break the spirit of what the rule is trying to achieve. I don't believe this is the case here.

It's confusing to see why TurboWarp can't get an article while an arguably outdated mod like Dream does, especially for new wiki editors. Sorry for the long reply, but hopefully I've shown why I think getting rid of the old Scratch Mod pages is a good idea.
Gdxfor (talk | contribs) 01:34, 9 July 2024 (UTC)

@Gdxfor — Nothing should be classified as "irrelevant" just because it didn't shape today. For example, if Dream were very popular in the Scratch 1.4 days, then Dream shouldn't be deleted, as it is "significant". Simliar to Project Trends and other pages, it might be better to put a big, new "Scratch Mod" page that has each section as a mod, instead of the historical ones having an entire page and new ones have... absolutely nothing.
Purin2022 | 💬Talk | 📝Contribs | 🐱Scratch 16:43, 9 July 2024 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘You may have misunderstood my original point. My point was that a Scratch mod that brings enough to the table to keep on the wiki must have a large userbase, backed by either a large amount of fans (Turbowarp) or the ST themselves (CoCo, Snap), and is updated at a consistent rate. Essentially something that is an alternative/separate from Scratch. In my opinion, Turbowarp is notable and important enough to be mentioned, while PenguinMod isn't, if we go by these rules. Hmmm, to Turbowarp or not to Turbowarp? This is a simple argument that only affects a few pages, but it is important to have anyway. Hold on, this reminds me of- *zones out*
Co0lcr34t10ns (talk | contribs) 19:54, 9 July 2024 (UTC)

@Co0lcr34t10ns Ahh, Twitter/X. Great fun. "Notable" is subjective (so its definition varies by person-to-person) so it shouldn't even be on the "why we don't create more Scratch Mods pages" page, and thus the line between keep/create, or delete.
Purin2022 | 💬Talk | 📝Contribs | 🐱Scratch 20:08, 9 July 2024 (UTC)

@Purin2022 I agree. I think S:NOSP is different when it comes to relevancy. Making an article about a tool that Scratchers use regularly without directly recommending anything is allowed, as long as we be careful.
Co0lcr34t10ns (talk | contribs) 20:43, 9 July 2024 (UTC)

@Co0lcr34t10ns, Purin2022 — I disagree - this is the same thing as us allowing kaj. I think that Turbowarp is arguably something more notable, and that's not subjective - it can be decided by community consensus. I'm sure there's a user out there who thinks they're more notable than kaj, which means that's subjective. This doesn't mean we can't create an article on kaj. So, my opinion - all Scratch Modification pages should be either deleted OR merged into one big article, similar to the List of Scratch Domains Article which a short blurb on each one. The exception to this (although I think it should only be Turbowarp) is that the mods the we come to a consensus on in the CP should have their own unique articles.
han614698 talk • contribs (2,588) • profile 01:42, 10 July 2024 (UTC)

@han614698, Co0lcr34t10ns, Purin2022  Support for han614698's proposal To Purin2022's first reply to my message: while yes, Scratch Mod pages like Dream (Scratch modification) shouldn't be classified "irrelevant" just because they're not used as much today, I should have articulated how the page in its current state is not providing anything that's historically relevant. Such a page would only provide use to people who want to look at what the mod has to offer (which is pretty much no one these days); you can't really figure out its historical relevancy by just looking at the page. Employing han614698's merging proposal would show why a mod was popular back in the day while also allowing for new and important mods to be added in.
Gdxfor (talk | contribs) 06:28, 10 July 2024 (UTC)

@han614698 Actually that's what I meant, so I perfectly agree with you.
Co0lcr34t10ns (talk | contribs) 10:02, 10 July 2024 (UTC)

@han614698 Perfectly fine with that, although I would prefer to have the minimum number of exceptions possible. (and also it's what I meant)
Purin2022 | 💬Talk | 📝Contribs | 🐱Scratch 17:16, 10 July 2024 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘I think @han614698's idea is good, merging them all into one article. However, I still have one question. Do we either: 1. Add all pages to the Scratch Modification page and add one or more sections showing the mods, 2: Make a new Scratch Mods page and put all the mods in there instead, or 3: Make a disambiguation page for Scratch Mods and put all of them in there. Which idea would we do? Anyone can also suggest more ideas too.
BrilliantGamer6 (talk | contribs) 20:31, 10 July 2024 (UTC)

I vote 1. No clutter, just mini sections. Wait, how many lines is this now? 37? That's quite a bit... HUH! ...w w what was that? Oh no, I have a bad feeling about this. it's coming, we have to keep it short or else it will become a thing.
Co0lcr34t10ns (talk | contribs) 22:24, 10 July 2024 (UTC)

@BrilliantGamer6, Purin2022, Co0lcr34t10ns, Gdxfor I think that we should just modify the "List of Scratch Modifications" page to include a multiline blurb about the mods we have information on. I don;t think a disambiguation page is relevant for this.
han614698 talk • contribs (2,588) • profile 01:07, 11 July 2024 (UTC)

@han614698 I think that'd make the most sense for this.
Gdxfor (talk | contribs) 01:12, 11 July 2024 (UTC)

@han614698 Yes that's a good idea. There's no need for more than one page on Scratch mods.
Purin2022 | 💬Talk | 📝Contribs | 🐱Scratch 17:35, 11 July 2024 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘@BrilliantGamer6, Purin2022, Co0lcr34t10ns, han614698 There's just one more thing that needs to be address, and it's which pages need to be merged into the "List of Scratch Modifications" page. I counted 10 Scratch Mods which need to be merged:

• Bingo (Scratch modification)
• Chirp (Scratch modification)
• Dream (Scratch modification)
• Enchanting (Scratch modification)
• Explore (Scratch modification)
• Insanity (Scratch modification)
• Mblock (Scratch modification)
• Panther (Scratch modification)
• Scratch for Second Life
• Web Blox (Scratch modification)

Feel free to discuss any that I've not mentioned or any you think shouldn't be merged.
Gdxfor (talk | contribs) 22:15, 11 July 2024 (UTC)

Looks good to me. Wait. That's it? No excruciatingly difficult, long, energy sapping, glorified argument? I could get used to this
Co0lcr34t10ns (talk | contribs)

@Gdxfor Isn't it all mods but Snap!?
Purin2022 | 💬Talk | 📝Contribs | 🐱Scratch 17:08, 12 July 2024 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘@Gdxfor, Co0lcr34t10ns, Purin2022 — I wrote a response to this last night, but apparently it didn't save.
I don't agree. I think that most mods need to be condensed to the list page, which would include the following:

Note:

I think that we initially need to include every single mod (including Snap!) in our proposed merge (we don't actually need to merge it), to be fair to everyone. Even before we merge, we can decide not to merge it, but as of now, that decision hasn't been made yet so it should be included.

Here's the list of all mods I could find that we would be focusing on:

• Bingo (Scratch modification)
• Chirp (Scratch modification)
• CoCo (platform)
• Dream (Scratch modification)
• Enchanting (Scratch modification)
• Explore (Scratch modification)
• GP (programming language)
• Insanity (Scratch modification)
• Mblock (Scratch modification)
• Net Scratch
• Panther (Scratch modification)
• Scratch for Second Life
• Snap! (programming language)
• Tickle
• Tosh (Scratch modification)
• TurtleStitch
• Web Blox (Scratch modification)

Once we have the list established, then we can go about creating exceptions.
han614698 talk • contribs (2,588) • profile 19:04, 12 July 2024 (UTC)

@han614698 The reason I didn't include Snap! is because it's not a Scratch Modification. While I would love to get rid of the Phosphorus Player page if TurboWarp can't get one, it wouldn't really be correct to merge in the List of Scratch Modifications page since it's not a mod, but rather a program written from scratch (this would include Tosh (Scratch modification) since that's a Phosphorus mod). If we were to merge these pages, it would have to be merged with a brand new "List of Programs Inspired by Scratch" article or something like that.
Gdxfor (talk | contribs) 00:16, 13 July 2024 (UTC)

@Gdxfor To be fair Snap! is on the list of Scratch Mods AND in the Scratch Mods category.
han614698 talk • contribs (2,588) • profile 00:43, 13 July 2024 (UTC)

@han614698 Well then it's just wrong, GP for example isn't even related to Scratch apart from the fact that it kind of looks like it.
Gdxfor (talk | contribs) 01:52, 13 July 2024 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘@BrilliantGamer6, Purin2022, Co0lcr34t10ns, han614698 There's been no discussion for a few days now. Since everyone seems to agree that all pages about things that are definitely Scratch Mods can be merged, I'll go ahead and add the This page's contents needs to be merged into (...) template to articles from my list.
Gdxfor (talk | contribs) 11:11, 17 July 2024 (UTC)

Okay maybe not that template specifically since it doesn't support linking to other Scratch pages
Gdxfor (talk | contribs) 11:20, 17 July 2024 (UTC)

All of the Scratch Modificatoin pages I've listed have been changed to a redirect, so this is now  Resolved.
Gdxfor (talk | contribs) 13:09, 31 January 2025 (UTC)