If a topic on the community portal hasn't received a lot of replies or it's not been solved in a while, topics may be moved to this page, to keep track of incomplete discussions. Remove the original topic and move it to this page to prevent confusion.
We need your help: Apply for getting "International Scratch Wiki Coach"
Not done
TOC
Click this picture to jump to "ScratchWiki:Watch"
To hold this long thread readable I build sub-Threads. I also moved individual conversions and answered it there (hope you don't mind). Please write new appliances to get " "International Scratch Wiki Coach"" there. Please answer each Sub-Thread at it's end:
Introduction
After presenting at de:Scratch2015AMS (see [1]) (and before at de:Scratch2013BCN see[2]) we have some just starting International Scratch Wikis. We found out, that there is much more work, than me de:user:Mtwoll, de:user:LiFaytheGoblin and de:user:akhof can handle.
We just started international Scratch-Wikis where we were sure, that there are Scratchers of that language that would really work hard for their Scratch-Wiki, but it seems that those people all need help, coaching and motivation, to cope with the problems of a just started Wiki: It seems that only id: is completely on the right track until now (Thanks to id:user:Rumanti, who made a great start and motivated some other Indonesian Scartchers to help). ru: is also evolving slowly but there seem to be too less active authors with just ru:user:Dimon4ezzz and ru:user:Timkoiko. With ja: we have great hopes in ja:user:Jp86143 and ja:user:Abee who just started. But hu: and nl: are still in a kind of "starting position".
In opposite to the English and German Scratch-wiki the starting Scratch-Wiki-Authors have no templates and existing articles where they can look up what is needed and mostly less experiance in Wikimedia-Syntax. Also some of them have problems with the English language: Naturally they know it, but everything lasts longer with misunderstandings and so on. (My English isn't perfect either, but where is a will there is a way ;-) Ironically the language-communities that have the biggest problems with English language need a Scratch-Wiki the most. Imagine the English Scratch-Wiki had nearly zero articles and templates and you could only see other wikis in languages that you know only a little bit. Also imagine that your Scratch community was not so big than the english-language one (see Wikipedia: World_language#Living world languages).
How would you start? Therefore I'm asking you for your help: Who of you wants to get „International Scratch Wiki Coach "? You would get an account and perhaps also admin-rights at all existing international wikis (depending on your activity). You should be an experienced Scratch-Wiki author in the English Wiki (>1 year membership and >300 edits?). We already have some de:Scratch-Wiki:Team_Mitglieder#Interwiki Autoren but that's only Interwiki, not coaching. It would really be great, if some of the English Scratch-Wiki-Admins would also apply for this job: They would immediately get Admin rights at all other international Wikis and perhaps also FTP-rights, if they are experienced with that "under the hood"-stuff. To see what goes on, we have made de:Scratch-Wiki:Watch. There are also many other ideas from the International Scratch-Wiki-Community (e.g. automized-account-application everywere, multinational-accounts like in Wikipedia, international templates, Scratch-Projects inside the Scratch-Wiki like we have it in DACH, international Blocks Plugin support, #Mobile Device Skin & Responsive Design for Scratch-Wikis ?, conecting scratch-wikis as a part of the scratch-editor-help…)...
...but let's begin with the beginning :-) Who wants to help and applies for getting "International Scratch Wiki Coach"?
MartinWollenweber (talk | contribs) 12:16, 23 September 2015 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
Individual Threads with scratch-wiki-authors that want to help
back to top
answer of TheHockeyist
Extended content
|
---|
back
I'll try to help the Russian wiki. I've not had time at all in the past many months, so I'll try to help it grow if I have time.
TheHockeyist (talk | contribs) 19:49, 23 September 2015 (UTC)
- @User:TheHockeyist: Thank you very much for helping with ru:. You already have an account there: ru:Special:ListUsers. I hope you don't mind that I interwiki-linked it to your account here? (I just saw that jvvg reverted it, so please feel free to “Re-Revert” it if you like. Excuse me for doing that minor link-change to you userpage, I just wanted to help, but jvvg is right: It’s better to obey strictly to all rules to avoid any conflicts). Do you still have the login to your ru: account or should I tell the wiki to resend you a password?
MartinWollenweber (talk | contribs) 11:15, 24 September 2015 (UTC)
- @user:MartinWollenweber: I don't mind if you linked the Russian interwiki to my userpage, however you do that. I still have the login information written down on my computer, and so that isn't a problem. I'm happy to help out in any way that I can.
TheHockeyist (talk | contribs) 13:20, 24 September 2015 (UTC)
- Great! Thank you very much for helping. I'm looking forward to you - as an experienced scratch-wiki-author - helping the other Russian authors so the Russian Scratch-Wiki could evolve much faster. I can't believe that it hasn't got a Homepage similar to Scratch_Wiki_Home, like de: or id:. BTW: The source code of Scratch_Wiki_Home is really hard to read, we use de:template:Scratchwikiframe at de: to make more readable. Perhaps that's better than a "copy-transfer-translate" of Scratch_Wiki_Home, so we choose an english name for that template and copied it already to all international wikis. ( ru:template:Scratchwikiframe , nl:template:Scratchwikiframe , hu:template:Scratchwikiframe , id:template:Scratchwikiframe )
MartinWollenweber (talk | contribs) 17:25, 24 September 2015 (UTC)
- Well, I'm not too good with templates, sorry. About the best I can do is images and links. I'm looking forward to mostly expanding the wiki, and I'm a fast learner. (Wow, this sounds like a resume...)
TheHockeyist (talk | contribs) 22:27, 24 September 2015 (UTC)
- I'm really looking forward to your work at the ru:-Scratch-Wiki!
MartinWollenweber (talk | contribs) 16:37, 25 September 2015 (UTC)
- Okay, thanks. I'm planning to start tomorrow unless I get distracted.
TheHockeyist (talk | contribs) 19:34, 25 September 2015 (UTC)
- Great! I already saw ru:user:TheHockeyist and ru:Special:RecentChanges there by using de:Scratch-Wiki:Watch
MartinWollenweber (talk | contribs) 14:21, 28 September 2015 (UTC)
(I don't know how to outdent) Well, I was updating my ru userpage (grammar), but I will contribute when I have the time. And thanks.
TheHockeyist (talk | contribs) 18:14, 28 September 2015 (UTC)
- I'm looking forward to your ru:Special:Contributions/TheHockeyist
MartinWollenweber (talk | contribs)
- No prob.
TheHockeyist (talk | contribs) 18:37, 8 October 2015 (UTC)
|
answer of KrIsMa
Extended content
|
---|
back
Nice idea! I was wondering - some people join specialized wikis because that is the only language they know - such as someone only knowing Japanese on the Japanese wiki. How will we coach and communicate with those people?
Or maybe, we could talk to everyone on their community portal?
KrIsMa user | talk | contribs | edits 13:40, 23 September 2015 (UTC)
- With the first generation of international scratch wiki authors communicating in english is not alway "no problem" but alway possible. Most Scratch-Wikis don't have a communityportal until now, but we could use a Scratch-Forum-Thread to make sure that everybody can answer, independent of his membership in certain scratch-wikis.
MartinWollenweber (talk | contribs) 14:32, 23 September 2015 (UTC)
- great! just wondering, so one of your ideas is a forum on the wiki that allows all members of the wiki from all wikis on scratch to talk? good idea! we can also put a link somewhere on the individual wikis to allow them to find the forum. then, if people need help, we can create pages or help them on the wiki with admin powers. interesting!
KrIsMa user | talk | contribs | edits 17:25, 23 September 2015 (UTC)
- @user:KrIsMa: Thank you for your interest and ideas. There is no exact plan how to connect a forum to the wikis until now. Perhaps like this here:de:user:Mtwoll/Sandbox2 ? Will you take part or are you as "International Scratch Wiki Coach" or just as an interested observer?
MartinWollenweber (talk | contribs) 11:15, 24 September 2015 (UTC)
- I brought up the Wiki suggestion because I thought it would be a great addition; it will allow other users from other wikis to communicate with one another :) I can suggest a separate forum for Scratch Wiki members to scmb1.. Sure, I'll participate! I just need to set up the French Wiki as well
KrIsMa user | talk | contribs | edits 14:49, 24 September 2015 (UTC)
- I'm happy that you want to take part as "International Scratch Wiki Coach": Could you send you eMail to mtwoll[at]gmail[dot]com so I can create accounts at all international scratch-wikis for you? If not sure about that ask User:ErnieParke. I had a look at your profile and saw that you are specialized in User:KrIsMa/Templates: That's something really missing at the international scratch-wikis. Problem is, that templates can't be just copied from the English-wiki, because they are connected with the language. At the other side there is mostly no "template-specialist" at the starting wikis, what makes it very hard for them to start. Perhaps we can find a way, e.G. a mixture between English and native-language templates? I'm also thinking about a way to connect forums with wiki better. I didn't understand your sentence: "I just need to set up the French Wiki as well": Until now we (the DACH-Scratch-Wiki people) set up and hosted all intentional wikis, when a language community had enough people to start and asked us for help...
MartinWollenweber (talk | contribs) 17:44, 24 September 2015 (UTC)
- oh hi, I just mean that I need to start the forum to start the french wiki
- i think the most important thing in this is actually a good chat medium, or a good place to talk to each other. we can use the cp for the individual wikis, and the forums or something like that for communicating to all other wikis.
- also, sure ill send you an email.
KrIsMa user | talk | contribs | edits 21:43, 24 September 2015 (UTC)
- Ok, before I do that, a question. I am a bit worried about the language barrier. I know I can help the English people in the other wikis make their templates. But, it might be faster to do it ourselves (because some of the wikis are slow to start). Do you think it might be a bit inefficient?
KrIsMa user | talk | contribs | edits 21:49, 24 September 2015 (UTC)
- see above: (most important to make a start): Could you send you eMail to mtwoll[at]gmail[dot]com so I can create accounts at all international scratch-wikis for you? If not sure about that ask User:ErnieParke.
- language barrier: I thought weeks to find a solution for the "hen egg problem" - "They can't start without templates - they will never build templates without starting". I think I found a solution now: We should copy all English templates, including the pictures used, to the new wikis and inter-wiki-link them. This could best be done by a bot. So you can also copy any article from the English wiki without loosing the layout and start to translate it to the language of the Wiki. As time goes by the text-parts of the templates could also be translated, than the documentation and at last the template-name can be transferred to the language (including renaming all occurrences) . I think if we do it the other way round only people who try it really very hard and with lots of passion (like us in the DACH-Scratch Wiki ;-) will be successful and it will last very long in any case: In DACH we invented most templates new in our German language and our own system, but the advantage to have native "hand made" templates is not as big as the disadvantage to start with nothing: We still haven't many good templates used in the English wiki. What do you think? Should we start with a few test-templates? Who could build the bot that we would need?
MartinWollenweber (talk | contribs) 16:31, 25 September 2015 (UTC)
- Ok I have sent the email :) Also, I am not sure that User:VoxBot will have anything to help on the other wikis.?
KrIsMa user | talk | contribs | edits 16:19, 26 September 2015 (UTC)
- Your accounts to the international scratch-wikis are created. Does everything work? I agree, User:VoxBot will not directly help with the international wikis, but it shows that his developer is really good in bots and wiki-work and that will help a lot :-). Meantime I had an idea that could help a lot: see [#New Idea for the future of international Scratch-Wiki or even more]. What do you think?
MartinWollenweber (talk | contribs) 19:05, 26 September 2015 (UTC)
- Thank you for your mails. I think its better to communicate here, because the others should also stay involved. I saw that you edited your userpages at DE:user:KrIsMa, ID:user:KrIsMa, RU:user:KrIsMa, JA:user:KrIsMa, :HU:user:KrIsMa and :NL:user:KrIsMa, but some seem still missing. We already added you to german interwiki authors. Thanks for test-transferring some of the most important templates to the NL-Wiki. Did you use a bot ore did you do it by hand? Could you also create a TOC there like User:KrIsMa/Templates? I think that would help the NL-use and translate the templates. I will tell nl:user:Xota that you did it, hope he then finally starts editing and involving others. BTW nl:user:Xota is the driving force behind the two European Scratch Conferences (see de:WhoIsWhoInTheScratchCommunity#Joek_van_Montfort) so I'm sure he will also mange it to create the NL-Scratch-Wiki, specially if we help him
. To see whats on at the international scratch-wikis best use de:Scratch-Wiki:Watch. I also made the template template:SameLinkAtAllWikis that could be useful: writng {{SameLinkAtAllWikis|Special:RecentChanges}} shows up as: DE:Special:RecentChanges, ID:Special:RecentChanges, RU:Special:RecentChanges, JA:Special:RecentChanges, :HU:Special:RecentChanges and :NL:Special:RecentChanges. Did you read #New Idea for the future of international Scratch-Wiki or even more. Your comments and ideas?
MartinWollenweber (talk | contribs) 15:27, 28 September 2015 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
Thanks! I will read that later. Did you want me to import important templates and the toc to the other wikis too?
KrIsMa user | talk | contribs | edits 00:21, 29 September 2015 (UTC)
- Replied below. Also, using a bot would be very hard for templates (importing images, categories, etc!) I manually did it.
KrIsMa user | talk | contribs | edits 00:38, 29 September 2015 (UTC)
|
answer of ErnieParke
Extended content
|
---|
back
This sounds interesting. I seem quite a bit of time in my schedule, and I've helped the DACH Wiki find Scratchers to make International Wikis before, so I do have some experience. (Even if it's not enough experience to set up a mobile skin or to do FTP.) I volunteer.
ErnieParke (talk | contribs) 00:22, 24 September 2015 (UTC)
- @User:ErnieParke: Great! As I already got your e-mail-address I will create accounts at all scratch-wikis for you. You will get your passwords in separate mails (we don't have multi-accounts like in Wikipedia until now, so they are all separate). Please go to all your international userpages and link them by Interwiki. Did it Work?
MartinWollenweber (talk | contribs) 11:15, 24 September 2015 (UTC)
- Everything alright Ernie? Did you receive the mails? Could you lock in? We sometimes had a problem with that "wiki-create-new-user-and-send-him-random-password"-function and had to do a reset-password-and-send before it work. Or did it work directly? You can set the wiki-language to english after you loged in by using ru:Special:Preferences, id:Special:Preferences...and so on (see de:Scratch-Wiki:Watch.
MartinWollenweber (talk | contribs) 16:41, 25 September 2015 (UTC)
- @MartinWollenweber: I remember awhile ago I made Java code for a bot that (with some tweaking) could work in other languages. The only problem is the bot can't log in, and it can't commit any changes. I imagine that I can build those functions in, although it would be really nice if I could host a local copy of a Wiki for testing purposes. Maybe you have an idea on how to do that? I'll try looking around.
- Yes, copying over templates sounds like a good solution, assuming it can be done.
- Let me look at the emails.... I just logged into the Hungarian Scratch Wiki, so it looks like everything is working.
ErnieParke (talk | contribs) 00:28, 26 September 2015 (UTC)
- It would be great if you manage it to get this bot to go. Perhaps we should ask people that are experienced with bots like user:jvvg? His WikiMonitor-bot seems really to be sophisticated. I will ask de:user:akhof to set up a test-scratch-wiki, so no wiki get's crashed while testing the bot.
MartinWollenweber (talk | contribs) 08:39, 26 September 2015 (UTC)
- @MartinWollenweber: There's no need to set up another wiki. I'm trying that right now with Bitnami, which should hopefully fulfill my needs.
ErnieParke (talk | contribs) 00:42, 27 September 2015 (UTC)
- OK. I made you a user at all wikis, see DE:user:ErnieParke, ID:user:ErnieParke, RU:user:ErnieParke, JA:user:ErnieParke, :HU:user:ErnieParke and :NL:user:ErnieParke and DE:Special:ListUsers, ID:Special:ListUsers, RU:Special:ListUsers, JA:Special:ListUsers, :HU:Special:ListUsers and :NL:Special:ListUsers. You just need to edit your new userpages and specially set interwiki-links to each other. What do you think of #New Idea for the future of international Scratch-Wiki or even more?
MartinWollenweber (talk | contribs) 15:58, 28 September 2015 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
I missed the part about creating a user page. My bad! On the bright side of things, my user pages are created now, and I'll try inter-wiking them right now.
ErnieParke (talk | contribs) 00:18, 30 September 2015 (UTC)
|
answer of jvvg
Extended content
|
---|
back
If there is ever a Wiki in Spanish, I could help out.
jvvg (talk | contribs) 16:53, 23 September 2015 (UTC)
- @user:jvvg: We would urgently need an experienced admin like you, to help us with all international scratch-wikis. We even would set up a Spanish wiki just to convince you to help with international wikis in general. We have nobody programming wiki-bots or other skripts like you do and that could be very helpful with international wikis (e.g. Interwiki-bot that sets all missing that could be constructed by the existing ones, like it is uses in Wikipedia, or the code for the user-registration-procedure). You've proved your knowledge, experience and reliability for so many years here that I would suggest to give you FTP-rights to the international wikis, if you are interested. What do you think? Would you help us in general even before we set up a Spanish Scratch-Wiki?
MartinWollenweber (talk | contribs) 11:15, 24 September 2015 (UTC)
- Yes, I am definitely interested in this. In terms of getting my code to work on other Wikis, my account requesting extension should be relatively portable and if I could have someone do the necessary translation for me for each Wiki, that would be great (a lot of the stuff was translated into various languages in the original extension I based it on, but I did add a bunch of stuff). For bots, I could make WikiMonitor work on pretty much any Wiki. The messages are actually stored on the Wiki and the page just needs to be edited as necessary.
jvvg (talk | contribs) 19:44, 26 September 2015 (UTC)
- I'm happy to read that you are interested
. Your "account requesting extension" could be a great step forward for the self-maintaining abilities of the international scratch-wikis. Could you help me and id:userRumanti to set it up in the german and the indonesian scratch-wiki as a first test how it works there? With a small modification it could also be the technical base of the strategy described in #New Idea for the future of international Scratch-Wiki or even more . What do you think of that plan? Do you think it will work?Have you additional ideas? We definitely should also test your WikiMonitor-bot at the other wikis, because this is also about easier self maintaining-abilities. If you send me a mail to mtwoll [ät] gmail [dot] com I will give you an account to all international scratch-wikis to make a start. If in doubt about that ask user:ErnieParke.
MartinWollenweber (talk | contribs) 15:48, 28 September 2015 (UTC)
- Ok, that sounds great! I'll shoot you an email and we can discuss this further.
jvvg (talk | contribs) 21:10, 28 September 2015 (UTC)
- see: User talk:Jvvg#FTP-rights to international scratch wikis: your answer to my mail
MartinWollenweber (talk | contribs) 16:35, 30 September 2015 (UTC)
|
answer of Mathfreak231
answer of Rumanti
Extended content
|
---|
back
Woah, I never knew you could read our minds! Though everyone learned the basic markups quickly, none of us specialize in important things like MediaWiki templates, including me. Some support and help from coaches would really speed us towards our goal - I am very optimistic about this program :) (Extra woah for not knowing about this until now — in fact the reason I came here today was to find out, specifically, why ErnieParke and KrIsMa signed up on Scratch-Indo-Wiki!)
Rumanti (talk | contribs) 12:08, 28 September 2015 (UTC)
- Thank you very much for your motivating answer
We are really happy about you work at The Indonesian Scratch Wiki! We worked so long (>2 years until now!) to get more good running International-Scratch-Wikis like this, but its really difficult. So we decided to change strategy, find more help, less restrictive and more self-mantling systems for making a start. Your answer shows me that we're on the right way . You see be the reaction that help for you is on the way, but other language groups nee even more help, that also you could give them, because you already made a breakthrough with your Indonesian Scratch Wiki. I hope the people here also like the #New Idea for the future of international Scratch-Wiki or even more, comment positive and help to build it up: Perhaps this could be the start of a "chain reaction" that builds up more successful scratch-wikis with less work and more motivation for everybody. I hope you and others add more ideas that help Scratchers all over the world, to build up their own Scratch-Wikis.
MartinWollenweber (talk | contribs) 13:12, 28 September 2015 (UTC)
|
answer of Eribetra
Extended content
|
---|
back
I would like to help with the Portuguese (Brazil) wiki! I speak Portuguese natively and want to help fellow Brazillians learn more about Scratch, and I have lots of time for that. I've translated English to Portuguese in some projects, so it'd be nice to do the same here too.
Eribetra Talk Contribs 21:23, 3 January 2019 (UTC)
|
answer of OurPrincess
Extended content
|
---|
back
- I have great hope for the future that is to come with Scratch becoming multilingual. Scratch is out here trying to grow and I appreciate everyone who's trying to help improve it. Scratch respects people of all skin colours, religions, age and experience. The diversity on Scratch is appreciated by many Scratchers.
OurPrincess (talk | contribs) 23:46, 23 January 2020 (UTC)
|
Forum Thread: Scratch Wiki in Your Native Language
back to top
@All: Am I right that all of you know this Forum Thread? Diskussionsforen » Translating Scratch » Scratch Wiki in Your Native Language (New)] . user:ErnieParke created it and sort of curates it (Thank you very much Ernie!). There are some other language communities that could be ready to start with their own native wiki in the future.
MartinWollenweber (talk | contribs)
Link-Table: Authors wih multiple Scratch-Wiki-Accounts
I put a Table here that shows de:Scratch-Wiki:Watch#Authors wih multiple Scratch-Wiki-Accounts. Please feel free to correct it if there are any mistakes.
MartinWollenweber (talk | contribs) 15:49, 30 September 2015 (UTC)
New Idea for the future of international Scratch-Wiki or even more
Extended content
|
---|
back to top
Perhaps there is a solution for the big Challenges we have to cope with International Scratch Wikis. Perhaps this system could even be a solution for Scratch Wikis Authorship in general.
Challenges:
- It's a lot of work for us to set up a new scratch-wiki in a certain language (like e.G. http://jp.scratch-wiki.info for Japanese)
- It's frustrating for us to do this work and see that nearly no one uses that wiki after a few weeks
- But we are (with reason) afraid, that people tell us, they want to make a start, but loose interest after a few edits
- To solve this problem , we made lots of restrictions for starting (prove that you are a group >4 people, know Scratch, prove that you will take it serious....)
- Those restrictions surely sometimes kept of people that could have been successful if we only had given them a chance to prove it
- Its also frustrating for potential authors to wait so long for a start, or to here "no, we don't believe you could be successful because..."
- On the other hand, some people could overcome those restrictions without been successful afterwards
- So this restriction produce to lots of work with negative effect
Solution:
- We set up a test-scratch-wiki ( test.scratch-wiki.info like http://jp.scratch-wiki.info ) were everybody is allowed to start with nearly no restrictions
- Here everybody can start to build articles of his native language and can find out and prove, if he or she is able to build a wiki (including a wiki community of their language that is strong enough to create a future for their own scratch-wiki)
- To separate the languages in the test-wiki, we use "test.scratch-wiki.info/wiki:[language-code]/[article-name] e.G. "test.scratch-wiki.info/wiki:it/Scratch1.4" for the "Scratch1.4"-Article in Italian language.
- Only after we see, that the language group is successful and has about let's say 50 acceptably articles in their language, including a proper homepage, we will set up their own wiki of that language and will give all active authors an account for it, so they can transfer their articles there: And voilà - We have a new pretty running international scratch wiki with nearly no work and no frustration for us and for the authors
- We could combine this qualification-system with the idea of transferring all the English templates there too, to make it more easy to start...it could even be more easy: We could transfer a complete copy of the English Wiki there, because the other languages have their own wiki-spaces
- To show that this is only a test-wiki it can have a warning and a special color in it's skin (like "This is only a test wiki, the original wiki is here"). And it surly should have no Interwiki to the other wikis..
- The idea could be enlarged with different automation for creating accounts and transferring material and even deleting articles of authors that didn't edit for a certain amount of time ("self-cleaning-ability")
- This system could also be used for the qualification of new wiki-authors in general: Let them prove that they are able and willing, before they come, do two or three edits and than leave again. That's makes the qualification-process more easy and harder at the same time.
- There could be a system that tests, if you got a scratch-account, some projects, some time been Scratcher and so on...but no questions like "are you serious?"...better prove it than telling it ;-)
What do you think? Are their additional ideas or suggestions?
To hold this long thread readable I build sub-Threads. I also moved individual conversions and answered it there (hope you don't mind). Please write new appliances to get " "International Scratch Wiki Coach"" there. Please answer each Sub-Thread at it's end:
MartinWollenweber (talk | contribs) 12:42, 28 September 2015 (UTC)
Discussion:
- The challenges are so great, I am amazed that anyone could come up with such a good-looking solution. The best think I think about it, is that it allows dedicated serious Scratchers to help out, but filters teams consisting of New Scratchers that are actually large, but not very dedicated nor serious.
Rumanti (talk | contribs) 12:08, 28 September 2015 (UTC)
- Thanks for your comment. I hope we get enough help to create this system
. Have you got additional ideas?
MartinWollenweber (talk | contribs) 13:23, 28 September 2015 (UTC)
- Right now, nope :)
Rumanti (talk | contribs) 14:19, 28 September 2015 (UTC)
- Good idea. This will prevent wikis that are inactive!
KrIsMa user | talk | contribs | edits 00:27, 29 September 2015 (UTC)
- This sounds like a good idea. It would even be nice if there would be a test Wiki page listing the requirements for a test Wiki to become its own Wiki, as well as a page listing the activity of users in a language (to track which Wikis have enough active users to turn into its own Wiki).
- Is there a way to set up a guide to learning MediaWiki in multiple languages? How about a suggested guideline on what to start with in a new language Wiki? It'd be really nice if we could get knowledge of the International Wikis more widely known too.
- Edit: I realized that a simple guide to learning MediaWiki in English would suffice. If it isn't too long, this would work: link
ErnieParke (talk | contribs) 01:21, 29 September 2015 (UTC)
- @KrIsMa: Yes to all of your suggestions and yes, there is a multi-lingual guide to mediawiki here mediawiki.org/wiki/Project:Help but it is not really "Scratcher-friendly".
- Also yes: International Wikis should been more widely known. There could be more links to them at the different forums (see signature suggestions at DACH) , but also at the scratch-site depending of your language setup. One suggestion, our German translation team just sent to Natalie Rusk, is: "It would be great to be able to place a link at the end of each tutorial that leads to a scratch-wiki-page in that language with further information and materials.".
- Also the FAQ of the Scratch-Website could-language-dependent be linked to the Scratch-Wiki-FAQ (that could be write-protected for security of the Scratch-homepage, whereas a copy of it evolves further and updates the write-protected from time to time).
- Scratch-Wiki and Scratch-Website could be much more connected than by just one link like today, without harming the security and influence of the Scratch-Team by that above described way: I think that would not even help the Scratch-Community, but could strengthen ability of young people even further than just Scratch: Leaning to use Wikis and to share your knowledge there is also a really important ability and could hold people much longer in the community, even when they passed the typical "Scratcher age"
MartinWollenweber (talk | contribs) 12:53, 30 September 2015 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
I really like the test idea. This is like the "Other Languages" forum on the Scratch Website. This will require users to show that they are dedicated to having their own language Wiki, but not deter them from trying to create articles in their language because there's not enough starting momentum.
jvvg (talk | contribs) 17:06, 30 September 2015 (UTC)
|
Discussion
|
---|
First Successes
It's great that so many experienced scratch-wiki-members will help us with international wiki and we had the first success within a few days:
If you want to have a impression of the international scratch community, have a look at this videos of the Scratch2015AMS-Conference. You will also find a (horrible ;-) video of user:LiFaytheGoblin and me there, where we try to introduce our international scratch wiki idea. You will also find many other People at the multiple short videos, that you perhaps could know, like Joren Lauwers user:JSO, Tim, Connor & Michael, Jens Mönig & John Malloney that gave a first look at their logical successor of BYOB & Snap! called GP, Ricarose & Eric from the Scratch-Video-Update, Eric Rosenbaum, Mitch Resnick and so on... best is the whole international scratch community singing the Scratch song :-) de:Scratch2015AMS was real great!
MartinWollenweber (talk | contribs) 22:17, 1 October 2015 (UTC)
- Seriously this is even better than everything is expected! I noticed we have the authentication system now (THANKS A TON, jvvg) but wow so much happening in the other wikis as well! This is great!!! Thanks everyone, I can't wait to see what the next weeks will bring :D -
LiFaytheGoblin (Talk) 10:22, 2 October 2015 (UTC)
Test-Scratch-Wiki is online!
Like explained in "#New Idea for the future of international Scratch-Wiki or even more" we started http://TEST.scratch-wiki.info/ that will have much lower restriction for new wiki-authors and that will be a kind of "really big sandbox", where everybody who wants can start a scratch-wiki of his own language to prove if he is able. We will help and coach to make a start, but only if we see success there (>50 articles + homepage), we will start a real wiki for this language. There is still much work to do, because until now this wiki is completely empty. We should write/copy help-text and templates there. user:jvvg, de:LiFaytheGoblin and de:mtwoll are admins there and I hope that user:jvvg will manage to create an automatic account creation system that fits to the targets of this test-scratch-wiki.
@user:jvvg: Please write here when it works and how to use it, so that everybody who wants to help can join.
We need your ideas an help to make this happen! Find most important international links at de:Scratch-Wiki:Watch. Please comment here, what you will do to help. Thank you in advance!
MartinWollenweber (talk | contribs) 15:28, 7 October 2015 (UTC)
- Good to know! What do you recommend we do with this forum topic ?
ErnieParke (talk | contribs) 00:56, 8 October 2015 (UTC)
- The test-wiki is not ready for start now, but after it is ready, we should inform all participants of this this forum topic how they immediately can get authors in the test-wiki and how they can make a start for the first 50 pages and the community of a scratch-wiki in their own language there. I suggest you prepare the invitation and explanation text in a sandbox (you could take the text above and shorten it as a start), so that we all can take part in creating this text. We should not inform the participants of that thread to early, because we still need some time for preparation. I think it will decrease success if we start inviting new authors without having everything ready.
MartinWollenweber (talk | contribs) 01:39, 8 October 2015 (UTC)
Not Done!
MartinWollenweber (talk | contribs) 11:54, 2 January 2016 (UTC)
- I already joined. :P
AghaCool (talk | contribs) 15:28, 2 January 2016 (UTC)
- Yeah, that's great! Hope many other will join us. I already wrote at your user-DISC, see: http://test.scratch-wiki.info/wiki/User_talk:AghaCool :-)
MartinWollenweber (talk | contribs) 15:55, 2 January 2016 (UTC)
- Yep! I told fmtfmtfmt2 to join and his account was accepted.:)
AghaCool (talk | contribs) 15:39, 4 January 2016 (UTC)
- I would like to apply! I have great interested in helping other language communitites :)
asqwde talk | contribs 12:34, 7 August 2018 (UTC)
- To join see: https://test.scratch-wiki.info/wiki/Test-Scratch-Wiki:Become_a_contributor
MartinWollenweber Talk Contribs Directory 05:38, 12 October 2018 (UTC)
- I am already a contributor, I was just wondering how I could get admin rights?
asqwde talk | contribs 07:09, 12 October 2018 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
To become admin, you have to have considerable technical knowledge and ideally know at least one non-real wiki language. As a contributor, you can already help plenty.
kenny2scratch Talk Contribs Directory 07:12, 12 October 2018 (UTC)
- I am waiting from a reply from Martin
asqwde talk | contribs 09:42, 12 October 2018 (UTC)
- I'm entitled to speak for him, as he has his own company to run and following the upcoming transfer he will be even less active on the non-German wikis. I don't see why you need admin rights when you don't speak any of the languages currently available on the Test wiki nor do you speak any language not available on any wiki. Additionally, you are not multicultural enough to understand how to interact with people whose native languages are far different from your own. Though you definitely have leadership skill, it only applies to leading people who speak a language you speak.
- In fact, I'm not sure why you should be on the Test wiki in the first place, seeing as you made exactly one edit over 2 months ago (which is your complete editcount) and haven't been seen since. Once you have encountered multiple cultures, and been far more active on at least one wiki and/or gained far more considerable technical skill, then we can start talking about potential administrative rights.
kenny2scratch Talk Contribs Directory 11:34, 12 October 2018 (UTC)
- I asked you to teach me some technical skills, but you have not come back to me with an answer
asqwde talk | contribs 12:04, 12 October 2018 (UTC)
- Ken is busy, and you need to learn some by yourself. You have Russian wiki - where you should start.
Apple502j Talk/Activities 2,229edit 12:40, 12 October 2018 (UTC)
- Yes, that too. You are already an administrator on the Russian wiki. You should spend most of your time there. Even though I have admin privileges on all wikis, I only use them with any frequency on the English and Test wikis, the wikis I am most comfortable in. I use them on other wikis only on request. Since you don't have such privileges on other wikis, and therefore can't deal with requests there, I recommend you instead focus completely on the Russian wiki, maybe with some English wiki work on the side.
kenny2scratch Talk Contribs Directory 12:50, 12 October 2018 (UTC)
- The Russian Wiki is inactive
asqwde talk | contribs 14:19, 12 October 2018 (UTC)
- @Asqwde If the Russian wiki is inactive, then do something about it! Don't let it stay inactive, you are an admin there, you can recut people, you can edit there! If you are active in the Russian language community, then you can easily meet people who can help edit the wiki. I see you already made a post in the Russian forums and thats great! You should also make a post in the request forum, to artact more attention to the wiki because that forum is more active than the Russian forums. Another tip is to also practice the language so your lingo seems natural to a native Russian speaker. I know these tricks work because I use these when I was looking for translators for the SDS, I currently am also teaching my self Spanish to help connect with the Spanish speaking community and improving my German to better connect to the German community.
Jakel181 (talk | contribs) 19:13, 12 October 2018 (UTC)
- I just sent an application for the Spanish Test Wiki.
Scratch-Coding (Talk |Scratch |(391 edits)
23:38, 20 August 2019 (UTC)
|
Not done
Why is Interwiki not possible in the english community-portal? In de:Scratch-Wiki:Gemeinschafts-Portal it is no problem (but in and id:Pembicaraan_Scratch-Indo-Wiki:Portal_Komunitas it seems to be, just tried it...).
MartinWollenweber (talk | contribs) 14:00, 23 September 2015 (UTC)
Discussion
|
---|
- Hmm.. Does the CP needs interwiki(s)? Because I didn't see any interwiki in this CP.
Really_A (talk | contribs) 23:34, 23 September 2015 (UTC)
- Interwiki at cp only means that the cp's of all Scratch-Wikis would have a language-link box, so you could switch between them fast and find them without knowing the language (like Interwiki in any article). Surely it only helps you if you have a lttle knowledge of the other language, or if they use english for some threads (what we often do in DACH because we have some non-german-speaking authors that help us). If you put [[:de|Scratch-Wiki:Gemeinschafts-Portal]] in the cp here (that should create the Interwiki-Link to Scratch-Wiki:Gemeinschafts-Portal) it has not that effect like in an article, because cp is somehow special configurated.
MartinWollenweber (talk | contribs) 11:44, 24 September 2015 (UTC)
- Oh I see. Anyway, I have a question; should I add an interwikis to the Indo wiki?
Really_A (talk | contribs) 14:44, 25 September 2015 (UTC)
- id: already has Interwiki, as you can see in multiple articles that have a language-link in the language-Box to other Scratch-Wikis (like the Homepage). See Scratch_Wiki:Interwiki for explanation of Interwiki. But you can look for possibly missing Interwiki-Links.
MartinWollenweber (talk | contribs) 16:46, 25 September 2015 (UTC)
- Well, I see. But the indo's CP still doesn't has any interwiki.
Really_A (talk | contribs) 09:02, 28 September 2015 (UTC)
- Interwiki seems only to be possible at certain group of pages. Surely I could setup it somewhere in the config of the international scratch-wikis (because I'm admin+bureaucrat+sysop ), but I don't know where to do it. At de: there seems to be a configuration difference (possibly an error :-) that allows you to interwiki-connect de:Scratch-Wiki:Gemeinschafts-Portal. Does somebody know how to set up wiki-config, so interwiki-connection works for every cp? As I'm no admin+bureaucrat+sysop of this English wiki, I couldn't do it here, even if I knew how ;-)
MartinWollenweber (talk | contribs) 11:44, 28 September 2015 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
The problem I assume is true is that the community portal is actually a talk page.
KrIsMa user | talk | contribs | edits 23:29, 30 September 2015 (UTC)
Not Done
This Thread is Not done! Because I think we should find a way to Interwiki-connect the community portals of all international Scratch-Wikis here:*
MartinWollenweber (talk | contribs) 12:00, 2 January 2016 (UTC)
- I am currently looking into this problem. It seems to be stemming from the fact that our CP is a talk page, but the DACH/Indo CP are not.
- This problem is even present on the DACH wiki. See my talk page: [:de:Benutzer_Diskussion:ErnieParke]
- Do you mind if I do a quick interwiki test on the Test wiki?
ErnieParke (talk | contribs) 15:26, 2 January 2016 (UTC)
- Yes, do that test, that's a good idea!
MartinWollenweber (talk | contribs) 15:56, 2 January 2016 (UTC)
- The only other way is to change the cp into mainspace, which is not feasible.
KrIsMa user | talk | contribs | edits 17:38, 4 January 2016 (UTC)
- I tried looking up some information but it is proving to be hard to understand. For now, I will try translating a DACH article (if there are any not translated yet).
ErnieParke (talk | contribs)
- Thank you very much for trying, I also try to learn more about mediawiki-namespaces and their different effects, perhaps we find a solution in the future. Until than this thread will stay have the state
Not done
MartinWollenweber (talk | contribs) 07:48, 6 January 2016 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘it's not possible to put interwiki on a talk.--
Apple502j Talk/Activities 2,229edit 12:42, 23 January 2018 (UTC)
- Because the CP is a talk page, direct interwiki is impossible. Interwiki links must go on the mainspace page: Scratch Wiki:Community Portal. We may end up simply redirecting the mainspace page to the talk page, if it becomes that important, but that would also mean that we can't interwiki-link to other wikis.
kenny2scratch Talk Contribs Directory 11:57, 4 May 2018 (UTC)
- I have created a template that mimics the interwiki box! It is currently in my user page, but I would like to move it to the template main space. Here is the link if you want to try it out: User:Jakel181/Templates/InterwikiTalk :)
Jakel181 (talk | contribs) 01:40, 16 October 2018 (UTC)
- You found a very interesting solution to this problem. Thank you! That is realy a way to solve this issue I didn't thought about. But I'm not sure if this will always show the box at the right position: At least at my mobile it displays the box in the midle of the article.
MartinWollenweber Talk Contribs Directory 03:50, 16 October 2018 (UTC)
- Yeah, Jake, unfortunately a template won't cut it because the sidebar is hidden on mobile, whereas your thing is always shown. Ideally we would use an extension to show interwikis on the talk side of mainspace pages, but I don't know if even that is possible.
kenny2scratch Talk Contribs Directory 04:29, 16 October 2018 (UTC)
- What about JSes?
Apple502j Talk/Activities 2,229edit 10:20, 16 October 2018 (UTC)
- I just made a JavaScript file that adds a fake interwiki box on talk pages for pages with interwikis: User:Kenny2scratch/interwiki.js. If you want to test this for yourself, create Special:MyPage/scratchwikiskin2.js with the content
mw.loader.load('https://en.scratch-wiki.info/w/index.php?action=raw&title=User:Kenny2scratch/interwiki.js&ctype=text/javascript'); (or add it to the bottom of your scratchwikiskin2.js page if you have already created it); whether you test it or not, though, please read the code - if you think it looks good I will add it to MediaWiki:Scratchwikiskin2.js.
kenny2scratch Talk Contribs Directory 14:00, 17 October 2018 (UTC)
- I think it looks really good! Though for me it only shows the german wiki in the cp (since I have a DACH account), and it would be helpfull if it shows every cp. But I am in supoort of adding it!
Jakel181 (talk | contribs) 01:17, 2 November 2018 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
It only shows German for me as well, because only the German wiki is interwiki-linked on the main side of the CP! I've now added interwikis to all the other language wikis that have community portals. It should show those when you visit the CP.
kenny2scratch Talk Contribs Directory 03:18, 2 November 2018 (UTC)
- Full support in adding it now, though I have 2 Questions: What about vector skin? Will this show for logged out users?
Jakel181 (talk | contribs) 12:43, 8 November 2018 (UTC)
- 1st: it will break on vector. 2nd: it also works for anonymous/logged-out users.
Apple502j Talk/Activities 2,229edit 12:58, 8 November 2018 (UTC)
- 1: I should have re-phrased the question, Should we make a vector option, or will the vector skin not have an interwiki? 2: Good :)
Jakel181 (talk | contribs) 13:31, 8 November 2018 (UTC)
- I think we don't need to worry about vector, those who really want interwikis on vector talk pages can write their own script.
kenny2scratch Talk Contribs Directory 05:41, 2 January 2019 (UTC)
- I think it looks nice, but should we also add the test scratch wiki CP?
12944qwerty Talk Contribs Scratch 22:58, 18 February 2019 (UTC)
- I would say yes (and I would add it right now too), but the test wiki has multiple CPs in it so, I'm not sure if only the main (English) one should be added or all of them.
Jakel181 (talk | contribs) 23:10, 18 February 2019 (UTC)
- Huh, I didn't know Interwiki doesn't work on talk pages. But in my opinion, I don't see why it should work in any Wiki because the CP is a place where people can discuss ideas for the Wiki and if people need to respond a lot this could be frustrating. If talk pages have Interwiki disabled, then why don't the CP's? I feel like the system here should remain as it is, and the system in the Deutsch Wiki should change. But it seems like Apple502j has already added the feature to the other CP's, so my opinion is of no use now.
- Either way, Interwiki still does a good job so I think it would be nice if this were changed and even nicer if this was not changed. I'm going to be lopsided on this one.
Nambaseking01 (talk | contribs) 13:20, 13 November 2019 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
This might already have been said before, but maybe the links to the Community Portals in other languages could go in the Community portal header? However, the Community Portal header is quite large, so maybe another section (like the how to edit the Scratch Wiki section) could be collapsed into a box?
Jammum (💬 Talk - ✍️ Contribs - 🐱 Scratch) 06:52, 27 July 2020 (UTC)
|
Embedding of Scratch Projects
Not done
Hey! :) I was thinking it'd be cool if we could embed Scratch projects into the wiki. They could be used in place of the existing example projects in the Pen Projects article, used on certain tutorial pages to demonstrate an expected result or even show a process more easily using an animation.
At the moment, you can't use the <iframe> tag required for embedding a Scratch project on the wiki. I've done a little research, and it looks like the easiest way to allow iframes would be to install this Media Wiki plugin. The good thing about this extension is that it doesn't allow the embedding of any iframe, it can be configured to only allow the embedding of Scratch projects, for example.
EH7meow (talk | contribs) 22:02, 27 June 2017 (UTC)
Discussion
|
---|
- My concern is that having projects load on a WIki page could be slow and take up a lot of RAM and make things slower overall.
     22:09, 27 June 2017 (UTC)
- I definitely take your point. As long as we only embed one low-asset project per page though, it's impact on loading times would be more limited.
- One article I thought could benefit is Pen Art Examples. For example, this project could be used to let readers see how it is rendered, in addition to the existing pictures. Readers could also then click the link and see inside to learn more.
EH7meow (talk | contribs) 17:18, 28 June 2017 (UTC)
- We could just make a gif of the pen being rendered.
     17:21, 28 June 2017 (UTC)
- I have a(n) (possibly better) idea. If we could enable video files to be uploaded, then we could make screen recordings of example projects and have those recordings directly in articles. Thoughts?
kenny2scratch Talk Contribs Directory 07:07, 5 July 2017 (UTC)
- If I'm correct, mp4's were suggested before and accepted, but support was not added to the wiki.
- This time around, when I re-suggest mp4's, how about we compile a list of what pages would benefit from it? Having examples is good motivation.
ErnieParke (talk | contribs) 14:18, 5 July 2017 (UTC)
- Sure! I think over 3/4 of all How To pages and tutorials would benefit from this :P
kenny2scratch Talk Contribs Directory 09:30, 6 July 2017 (UTC)
- Support! It would be like the YouTube videos on the Minecraft Gamepedia Wiki!
Forested (talk | contribs) 19:38, 3 August 2017 (UTC)
- This wouldn't take up almost any ram at all if we just use iframes to the main scratch website. :/
TheUltimatum (talk | contribs) 19:12, 16 September 2017 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘I made an extension which allows <scratch project=""> tag. (github) Code is reviewed by user:kenny2scratch. This can only embed Scratch projects, and you don't have to upload big files - like mp4. Big files are laggy.
Apple502j Talk/Activities 2,229edit 03:31, 8 February 2018 (UTC)
- Yeahhh, but I don't think certain articles would benefit. Take platformer. A video won't show the controls, and how you make it. I think embedded video tutorials would be the best in this case.
Knitt (talk | contribs) 02:07, 21 May 2018 (UTC)
I was thinking maybe a button that when clicked, creates an iframe linking to the scratch project. If there is not a way to do it directly, we could possibly use a third-party website such as Sulfurous.
Logabe (talk | contribs) 15:53, 16 August 2018 (UTC)
- This is a good idea, +1 support! The main problems are that a. it would slow the wiki and b. we can't monitor the changes made to every project very well. What if the creator of the project decided to change it to something else, or remove a feature we've pointed out? And then, would we show the notes and credits or instructions? If so, people could notice their project displays on the wiki and advertise there. We couldn't put the notes and credits and/or instructions in that case. Finally, we can't fully trust anybody over the internet (or anywhere, for that matter), so if we put a project on here and, once again, they notice, they could advertise within the project. We'd need to find a way around this. Maybe we could do something where we save the project in its current form, use that, and recreate notes and credits/instructions?
EIephant_Lover Talk Contributions Subpages 18:02, 20 February 2019 (UTC)
- Also, if we didn't do the saving in its current form thing, we would have to put a report button by the project, right?
EIephant_Lover Talk Contributions Subpages 18:04, 20 February 2019 (UTC)
- I think we'd just have to only embed projects that are guaranteed not to change - ideally, either by or remixed by a Wikian. Displaying projects uploaded to the Wiki is very difficult to accomplish.
kenny2scratch Talk Contribs Directory 05:41, 23 February 2019 (UTC)
Note: I do not help in the Community Portal a lot. I help more on the Scratch discussion forums, so sorry if I don't use the correct terms.
- Meanwhile this could be extremely useful for tutorial pages, I see a lot of posts on here that say this will slow down the Wiki. I can't really think of a way to fix this. There could be a system that detects if the project has way too many loops or data sources (variables or lists) and prevents the user trying to embed it from not doing it. I don't understand how an external source like the Wiki will be able to connect with Scratch programs though. As Kenny2scratch said, displaying projects on the Wiki will be an extremely difficult task. There are many complications listed in this thread.
- At the same time, I can't seem to think of anything else then loops or data sources that cause major lag. If someone knows, please inform me. But either way, I don't know whether to agree that this needs to be implemented or not. I'm not going to take a decision now, I'll return to this once I have a clearer view of what can cause lag and how you can prevent it. Being a web development coder, I understand the difficulties (I don't know if MediaWiki uses HTML, but as I said I'm new to the Community Portal)
Nambaseking01 (talk | contribs) 20:34, 12 November 2019 (UTC)
- We can use thumbnails of the projects rather than run them. For example, take a look to a code:
<span class="plainlinks">[https://scratch.mit.edu/projects/392399555 https://scratch.mit.edu/get_image/project/392399555_144x108.png]</span>
Note: | Also, why hasn't done?!! | (edited in 23.06.2020 (UTC))
ahmetlii Talk Contributions Directory 18:59, 8 June 2020 (UTC)
- This is a interesting idea but I want to know why this would be helpful
AirMargaret33 (talk | contribs) 21:59, 3 September 2020 (UTC)
|
A Thorough Discussion on Thinking of the Past, Present, Future, and Organizing them All
Not done
One of the complexities of documenting Scratch is it changes so much. When Scratch transitioned from 1.4 to 2.0 there was an unbelievable amount of work on the Wiki that required tons of articles to be updated. This reached the solution of keeping articles relating to Scratch 1.4 but denoting them by putting "(1.4)" in the title of the article. For example, the older version of Paint Editor is Paint Editor (1.4). Another example is Project Compression (1.4) which is the old version of Project Compression.
I think we need to set in place some standards. In the future, we are going to have to do this for Scratch 3.0, so it's better if it can be done consistently. Firs thing to discuss is:
Past or Present Tense - I have noticed it is not always consistent. For example, Scratch Forums (1.4) discusses the forums in past tense. Paint Editor (1.4) uses the present tense, though that may make more sense since you can still use Scratch 1.4 while the Scratch forums are nonexistent. However, an article like Project Downloading (1.4) talks in the present tense even though project downloading on the Scratch 1.4 site is not possible since that old version of the site does not exist.
So I wonder, for an article that documents a feature in an old version of Scratch that is still accessible like the 1.4 Paint Editor, should it be: past or present tense?
For an article that documents a feature in an old version of Scratch that is impossible to access and there solely for history, should it be: past or present tense?
In the latter case of an article that documents an unavailable feature just for history, if present tense is used it sort of gives off the feel that that is how the article would be read if you were to be reading it in 2010 or whenever. This may make sense if we want our articles to sort of be like a frozen time capsule of the past. But if past tense is used, that could also make more sense because it's not 2010 but 2017.
Block Pages - This brings up another issue, and it has to do with block pages. An example of this is Distance to () (block). Please note that there is no Distance to () (block) (1.4) page on the Wiki, and that is so because this block is available in both Scratch 1.4 and 2.0, so we believed it was not necessary to document the same block in a prior version of Scratch. I'm starting to think, though, it might be a good idea.
Take a look at the script on that page. It uses the if <> then
block as well as the stop [all v]
block. Both these blocks are sort of in Scratch 1.4, but "if ()" then was just "if ()" and "stop [all v]" was just "stop all". So if somebody is using Scratch 1.4 and looks up the documentation of this block on the Wiki, the scripts in the article may use blocks not available in 1.4. There are probably more examples of block pages on the Wiki that use blocks not in Scratch 1.4, probably more dire examples than mine above.
It's just something to think about. How do we want to make our Wiki consistent throughout history to avoid any possible confusion? Do block articles deserve a (1.4) version or not? Eventually we are going to have (2.0) articles. It's best to decide stuff like this at the present moment.
If Block - I just noticed there happens to be no article on it. Technically "if () then" is only in 2.0, so shouldn't "if () (block) (1.4)" be an article?
Titles of Articles on items not in 2.0 - Examples of what I am talking about are the articles Stop All (block) as well as Java Player. The titles of these articles do not have (1.4) in the title because, well, they are not available in Scratch 2.0! So, I'm going to ask you guys, do you think by not having (1.4) in the title, it can be misleading, making people think it's a feature still available?
It does say at the top, "This article or section documents a feature not included in the current version of Scratch (2.0). It is only useful from a historical perspective" so I do not believe anybody reading the article is going to be confused and think the Java Player still exists. But do you think it should or should not have "(1.4)" in the title, or should "(1.4)" only be in the title of articles on features that have been replaced in Scratch 2.0?





22:41, 13 June 2017 (UTC)
Discussion
|
---|
- Turkey3 at it again with the great writing! I intend to move some things (leaving redirects, ofc) once I have time.
kenny2scratch Talk Contribs Directory 23:38, 13 June 2017 (UTC)
- Firstly, I think that this is a very important topic. It's important to get this right, or, like you say, things could get more messy and complicated.
- So, here are my views:
- I agree that past tense should be used when something is no longer accessible, it's odd to say 'you can' if you can't anymore. Similarly, I support using present tense on still accessible but outdated features because you still 'can'.
- I don't think we should make 1.4 versions of articles for blocks that are unchanged on both versions. Examples are only examples, so I don't believe it's worth duplicating a page for them. That being said, it should be good practice to make examples as 1.4/2.0-friendly as possible.
- I also agree with making a 'if () (block) (1.4)' article as the change between versions could be a cause for confusion, and this article could help clear up that confusion.
- I believe that the version number used on an article on an outdated feature should be the last version it was available in, making it clear that it is no longer used.
- Furthermore, a feature on the current version should have no version number in my opinion, as this causes lots of moving when Scratch updates and also makes it appear to be historic, as the version number looks like it's denoting a secondary, or outdated version of something.
EH7meow (talk | contribs) 18:52, 19 June 2017 (UTC)
- So with that said do you believe the title should be "Java Player" or "Java Player (1.4)"?
     19:04, 19 June 2017 (UTC)
- I support Java Player (1.4) and Stop All (block) (1.4) and at this moment I also support Flash Player and Stop () (block). However, when Scratch 3.0 comes, I believe that Flash Player should become Flash Player (2.0) and there should be a new article titled HTML5 Player.
EH7meow (talk | contribs) 19:20, 19 June 2017 (UTC)
- I changed the article about Project Downloading (1.4) to past tense as you can no longer do it.
Blessing06 (talk | contribs) 15:40, 10 September 2017 (UTC)
- If this is still going on, I started to move it to 1.4, 2.0, etc.
NYCDOT [ Talk Page | Contributions | Directory ] 15:14, 20 June 2018 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
- Ok-here are my thoughts.
- Any article that is about a feature available in all three versions (like the forums) should be one large article with different sections for 1.x, 2.0, and 3.0. An example name for an article like that would be "Scratch Discussion Forums."
- Any article that is about a feature not available in the current version (like a Friend), it should have it's own page. An example name for an article like that would be "Friend." It would not be "Friend (1.4)" because there really is not a point; people don't need to know what an obsolete feature is right away.
- Any article that is about a feature that is available in all three versions but went by different names (like Gallery -> Studios), it should be named what it is currently called (studios) and have a section documenting all versions. A redirect would be set up called "Gallery" for (if I'm being blunt) oldie users, and to document past versions for others.
- Any article about a feature that isn't currently available but has the "main idea" still being used (like Scratch 3.0 Beta (forum)), there would be a separate article going by its feature's name, with a (xx) documenting what version it was used in. There would also be a link on the "main idea" wiki page going to that page.
NYCDOT [ Talk Page | Contributions | Directory ] 20:18, 1 May 2019 (UTC)
- So, current admins, what do you think?
NYCDOT [ Talk Page | Contributions | Directory ] 13:10, 5 May 2019 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
Let's get all our ideas out before we start judging them; here's my proposed rules:
- Titles
- If the page is about a feature that has remained unchanged throughout all versions of Scratch, there should be a single article about it under its normal title.
- If the page is about a feature that has changed between versions of Scratch:
- If the changes were rather major/need a lot of documentation, have separate "title (version)" articles for each version it was changed in. The latest version should omit the "(version)" but the title including the version should redirect to it.
- If the changes were rather minor/only need mentioning, include information about each past version in its own section and have separate "title (version)" redirects to their respective sections for each version it was changed in.
- Previous rules apply to features added in later versions of Scratch than 1.4.
- If the name of the feature changed between versions:
- If the feature itself did not change, the old names (with and without a parenthesized version) should all redirect to the single article about the feature, which should mention the old names somewhere.
- If the feature itself also changed:
- If the changes were major (e.g. Friend -> Follower), the old and the new version of the feature should really be treated as completely separate features. The old name should be used for the old article, and the new name for the new article, neither of which should have parenthesized version numbers, but both of which should have corresponding redirects with said version numbers.
- If the changes were minor, include a section in the new article about the old version, and the old name (with and without a parenthesized version number) should redirect to that section.
- The same rules apply to future versions as do to past.
- If the page is about a feature that was removed in a past or current version, all previous rules apply but as if the most recent version in which it was still present was the current version. (Id est, if following was removed entirely in 3.0, the page "Follower" would document the 2.0 version, and "Friend" would document 1.4.) The {{obsolete feature}} template should be added to the most recent version.
- Tenses
- If the page is about the current version of a feature, it should be in present tense.
- If the page is about an old version, it should be in 'past tense. (Even if there is no subsequent version, this holds. Snapshots of the past do no good.)
- If the page is about an upcoming version, it should be in future tense, but should be updated to present when the upcoming version becomes current.
- If the page is about the current version which is to be removed in the future, it should remain in present tense but be updated to past when the upcoming version becomes current.
Those are my thoughts; anyone else have ideas?
kenny2scratch Talk Contribs Directory 06:31, 9 May 2019 (UTC)
- Agreed!
NYCDOT [ Talk Page | Contributions | Directory ] 19:42, 15 May 2019 (UTC)
- +1
TenType (talk | contribs) 22:15, 29 June 2019 (UTC)
- I definitely think all this mess needs to get organized, so agreed. This could be really helpful for the future of the Scratch Wiki. I do really think we need to also consider Kenny2scratch's rules, because they could also play a major role in this. The only question is, how do we randomly start a big bulk change of articles because of this one thread? Do we announce this new idea to all of the Wikians? I feel like there should be some big announcement for changing incorrect tenses and titles right away after this thread gets clarified. Scratch 3.0 is already out now, and I'm pretty sure some "(2.0)" articles are on the way to complicate things.
Nambaseking01 (talk | contribs) 20:54, 12 November 2019 (UTC)
|
custom signatures
Not done
Recently I've noticed many custom signatures break one specific rule:
The signature may not contain any background colors, images, or borders
Specifically, background colors and borders cannot be added to custom signatures. It is important to read that page fully before creating a custom signature. Please change it to satisfy that rule. Thank you!
KrIsMa user | talk | contribs | edits 16:56, 28 August 2017 (UTC)
- another suggestion: we could also propose to scrap that rule so if you're up for it you may start a discussion.
KrIsMa user | talk | contribs | edits 16:59, 28 August 2017 (UTC)
3.0 updating
Not done
Note: | before writing please read this |
As a result of Scratch 3.0 releasing, we have to update a lot of articles.
- Is there anything more to update?
- Is it OK to use bots?
- When to update?
Updates are:
- {{Pen Blocks}} to {{Pen Extension}}
- Category:Pen Blocks to Category:Pen Extension
- Change {{block}} for 3.0 blocks (it's larger than 2.0!)
- Music Extension, LEGO WeDo Extension categorize and put a new template
- remove {{unreleased}}
- if there's XX (1.4) and XX, XX moves to XX (2.0), and XX (3.0) moves XX
- TOC remake
- Tutorials remake
- Upload blocks' images
- Remake scratchblocks
- put {{Obsolete feature}}
(everybody can edit this list, with Siggy!)
--
Apple502j Talk/Activities 2,229edit 04:58, 14 January 2018 (UTC)
Discussion
|
---|
- The ScratchBlocks plugin might need a style update.
kenny2scratch Talk Contribs Directory 14:21, 14 January 2018 (UTC)
- I'm making for it.
Apple502j Talk/Activities 2,229edit 10:21, 8 March 2018 (UTC)
- ...that repo is (effectively) empty? Also the current ScratchBlocks version is 3 - if we rewrite it the new version will be 4.
kenny2scratch Talk Contribs Directory 13:34, 8 March 2018 (UTC)
- i don't know how to use source from other repo..
Apple502j Talk/Activities 2,229edit 22:06, 8 March 2018 (UTC)
- The ScratchBlocks extension is fairly complicated. I think we would have to rely on Blob8108 to update it, if he feels like it. If you want, you can ping him on his Scratch profile to let him know he needs to get cracking on updating ScratchBlocks.
kenny2scratch Talk Contribs Directory 10:51, 9 March 2018 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ +1 Kenny2Scratch, I second.
S-zhangcha (talk | contribs) 02:50, 1 April 2018 (UTC)
- I am currently working with blob8108 on updating scratchblocks to fit the new format. The sourcecode is up at github.com/s3blocks. I need to get some work done to allow you to use it with the wiki.
NitroCipher (talk | contribs | edits | account) 15:02, 11 April 2018 (UTC)
- For articles that are needing updates: Can I put {{update}}?
Apple502j Talk/Activities 2,229edit 13:13, 4 May 2018 (UTC)
- For 2.0 articles that use scratch blocks would they all change to 3.0 blocks? If so that would be confusing. Also are the current 2.0 articles that are being replaced by 3.0 articles, being deleted or are they going to be saved and just add "(2.0)" or something similar to the title?
Jakel181 (talk | contribs) 22:45, 24 November 2018 (UTC)
- You said "6. if there's XX (1.4) and XX, XX moves to XX (2.0), and XX (3.0) moves XX". What does that even mean?
EIephant_Lover Talk Contributions Subpages 21:49, 6 March 2019 (UTC)
|
We have to delete Fair Use
The server is in Germany now. German copyright law doesn't allow Fair Use, so we have to delete all the fair use images. For example, screenshots of games are prohibited.
Apple502j Talk/Activities 2,229edit 08:13, 21 February 2018 (UTC)
Discussion
|
---|
- I don‘t like that idea, even if I am the one that would have to bare the struggle, if we would really get legal problems. Until now in the DACH wiki we acted according to the saying „without complaint, there is no redress“... but you are right, that we must take the matter more serios. I‘m even considering moving our sever somewhere, where we have less legal problems...
MartinWollenweber Talk Contribs Directory 09:20, 21 February 2018 (CET)
- I think that legally, the images are not illegal until the owner of the game or whatever claims the images as their own - that is, until someone says "you cannot use this image, it contains my project in it" then that image is not illegal.
kenny2scratch Talk Contribs Directory 11:00, 21 February 2018 (CET)
- Are they copyrighted?
Dilek10 (talk | contribs) 00:08, 22 February 2018 (CET)
- Just move the server to a different place!
♥PrincessPandaLover Talk | Contributions | Scratch Account 02:29, 22 February 2018 (CET)
- @PrincessPandaLover: That's not "as" easy: It needs trust (in the new place, e.G. the new host should not sometimes "pull our plug"), knowledege of and trust in the law of that country + trust that we could cope better with that countries law than with German law, + econonomic work (which hosters offer's best), + technical work to analyse new server and not the last doing the transfer itself...IMHO - because we never got problems since 2012 wether with the DACH Scratch wiki, nor with the others - and because I don't got the time, we should postpone decissions about that.
MartinWollenweber Talk Contribs Directory 13:07, 22 February 2018 (CET)
- Hi everyone! I consultet with someone who is studying law in Germany and has some knowledge. Pictures like eg. a Mario sprite can not legally be on the Wiki. We could be fined for it. It is more likely that we get a "Aufforderung zur Abgabe einer Unterlassungsverpflichtung" which means we need to sign something that states we'll remove the picture and won't upload that content again, else we need to pay something (probably 5000€+). However, we can most probably put screenshots of Scratch games or so on here that have these sprites, since this would be categorized as "Kunstfreiheit" (freedom of art) because a new piece of art is created with it. Which images are these pictures that fall under fair use? Are they all in a certain category? Also, how do people upload profile pictures? They should not have copyrighted content. We should add a notification or so for that. -
LiFaytheGoblin (talk | contribs) 18:43, 23 February 2018 (CET)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ I made a template {{fair use}} and a category Category:Images under Fair use.
Apple502j Talk/Activities 2,229edit 07:50, 24 February 2018 (UTC)
- @Apple502j: Thanks! It‘s good to have an overview and to have the users of that pictures warned, even if we wait with the decission what to do with that pictures. How did the pictures that are already in that category get there?
MartinWollenweber Talk Contribs Directory 08:07, 27 February 2018 (CET)
- I checked a lot of images one by one.
Apple502j Talk/Activities 2,229edit 07:53, 27 February 2018 (UTC)
- I'm sorry, but why are you treating Fair Use images like they have to be burned immediately?
♥PrincessPandaLover Talk | Contributions | Scratch Account 00:37, 7 March 2018 (UTC)
- Because they basically do. Now that the servers are in Germany, we have no right to keep such images without being sued. So unfortunately all your game screenshots are now effectively illegal, and will likely need to be taken down.
kenny2scratch Talk Contribs Directory 04:39, 7 March 2018 (UTC)
- Screw lack of fair use.
♥PrincessPandaLover Talk | Contributions | Scratch Account 23:26, 7 March 2018 (UTC)
- I'm clearly not some big-shot lawyer, but the images should really be deleted. We don't want to be caught by the image owner and have Mtwoll fined $1000, and in some cases a year in prison (according to legalzoom.com)!
NYCDOT [ Talk Page | Contributions | Directory ] 21:55, 26 April 2019 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Wait, isn't all of Scratch under Creative Commons or the MIT license, meaning we're allowed to use screenshots from Scratch...? Or is this about screenshots from Scratch of copyrighted work e.g. a Pacman sprite? In the latter case, from what I've found on Google, educational organizations are generally excempt from copyright restrictions, and I would argue the Scratch Wiki is educational.
VFDan Talk Contribs On Scratch 00:26, 30 August 2020 (UTC)
- Scratch's license is irrelevant, as this largely refers to copyrighted works referring to Scratch (i.e. File:Step by Step SCRATCH Programming.jpg and File:Scratch 2.0 Idea Book.jpg) or just things not related to Scratch at all (i.e. File:Spam_meat.jpeg and File:My windows 2000 desktop.png). The Scratch Wiki is not an educational organization by any sense of the legal term, as well as the educational exemption generally not referring to publicly available material.
Naleksuh (talk | contribs) 01:10, 30 August 2020 (UTC)
|
What should we call the Scratch 3.0 player?
There are some player articles like Flash Player, Java Player, HTML5 Player. So what should we call the 3.0 player? HTML5 Player is different from Scratch 3.0.
My opinion:
- Move HTML5 Player to HTML5 Player (2.0) and make it as HTML5 Player (3.0)
- WebGL Player
- Scratch 3.0 Player
- JavaScript Player (added 01:56, 18 March 2018 (UTC))
Apple502j Talk/Activities 2,229edit 23:50, 17 March 2018 (UTC)
Discussion
|
---|
- I thought the 3.0 Player used JavaScript?
Makethebrainhappy (talk | contribs) 01:47, 18 March 2018 (UTC)
- HTML5 Player does too
Apple502j Talk/Activities 2,229edit 01:56, 18 March 2018 (UTC)
- "React Player" might work too - the 3.0 editor uses ReactJs
kenny2scratch Talk Contribs Directory 04:10, 18 March 2018 (UTC)
Not done
Apple502j Talk/Activities 2,229edit 11:56, 14 April 2018 (UTC)
- I would just call it The 3.0 player.
Jakel181 (talk | contribs) 15:23, 22 June 2018 (UTC)
- I'd call it the HTML5 PLayer, seeing as we've had the Java and Flash Players in the past.
Redglitter ~ (Talk Page ~ Contributions) ~ 07:31, 24 June 2018 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
"HTML5 Player" is a different thing, there was a previous attempt at making an HTML5 player that lost traction, so that wouldn't work.
kenny2scratch Talk Contribs Directory 03:49, 22 August 2018 (UTC)
- Universal Player or Vector Player.
SpyGuy9 (talk | contribs) 00:16, 29 March 2019 (UTC)
- I say name this HTML5 Player (3.0) and the previous one with (2.0). There would be either a disambiguation page or a see alsoon the top of the page.
NYCDOT [ Talk Page | Contributions | Directory ] 19:46, 15 May 2019 (UTC)
|
Help:Contents Is missing some help pages
Not done
There are a few help pages which aren't in Help:Contents, for some reason.
We need to fix that.
Yzyzyz (talk | contribs) 14:07, 7 October 2017 (UTC)
Discussion
|
---|
- +1 It's a contents page, it should have contents to all help pages. If you see a contents page in a book, it tells you where every chapter is.
290Scratcher (talk | contribs) 15:29, 7 October 2017 (UTC)
- bump
Yzyzyz (talk | contribs) 14:34, 29 October 2017 (UTC)
- I think some of the articles in the Help namespace actually don't belong in Help:Contents. They should be linked to from other help pages instead.
kenny2scratch Talk Contribs Directory 10:51, 15 November 2017 (UTC)
- I think we should have all the Help pages in Help:Contents because they're helpful tutorials for editing, and I refer to them a lot, especially when I was starting out. It would give them much more visibility (I didn't even know that all these help pages existed) and organization. Maybe we could put related pages in drop-down menus underneath other pages somehow, sort of like how Recent Changes groups multiple changes to the same page (if you have that option on)?
Groko13 (talk | contribs) 03:48, 29 June 2020 (UTC)
- I think that it should have all of the help pages for the reason 290Scratcher mentioned. Ken, could you give some examples of pages that don't belong there? As for Groko13's idea, we could also use sub-headings (which some of the pages at Help:Contents are under already).
bigpuppy talk ▪︎ contribs 21:08, 29 June 2020 (UTC)
- I think put all of the help pages to Help:Contents isn't necessary, there has been a Category:Help page already. Also, Help:Contents page is using for most important pages(that's standard for all wikis), or using for search engine(for example, Wikipedia). We can put a search engine, I think.
ahmetlii Talk Contributions Directory 07:27, 30 June 2020 (UTC)
|
Account Request Notes
Not done
I, when, recently doing account requests (yes, I do still use this thing) I have noticed that I am not learning much about what this user wants to edit and why they want to join the wiki. I like this system which identifies things to fix, but I feel that we should also add back some of the old application. I suggest adding the wiki experience, why they should be accepted, and an article to edit, and then have the current Find 3 Add 2 system. Opinions?
Cυƨтσмнαcκεя ( тαʟκ | cσптяıв ) 02:34, 25 January 2018 (UTC)
- Take Example:
There is a capital S in the word "Screen" in the middle of a sentence that should not be capitalized.
There is a dead link to the page "Oranges."
There is the first person used under the paragraph called "Pineapples."
It would be possible to add a section about Kiwis under the header of "Awesome Fruits."
It would be possible to add a picture of an orange to the section titled "Oranges".
The secret word is "Bananas"
With this example (which is totally about fruits) as long as they use complete sentences and basically fit this point:
- In the request notes, does the user properly identify at least 3 flaws in the flawed article and 2 things to add?
- Saying "I found a grammar error" is not clear
- Users must actually make sense of what they are talking about.
- If the specific examples of what they would add to the flawed article are not allowed on the Wiki (e.g. writing about their projects), fully reject if there was little effort, partially reject if it seems like you could get more ideas out of them or explain to them why it's not allowed.
Then they can be accepted into the wiki. This system, In my opinion, only tests the reading comprehension and if the user can write in complete sentences. It shows nothing about if the user can navigate the wiki or know what they want to edit. We get nothing of why they deserve to be a wikian. I belie these systems need to be combined.
Cυƨтσмнαcκεя ( тαʟκ | cσптяıв ) 02:45, 25 January 2018 (UTC)
Discussion
|
---|
- I'm hesitant about making request notes more intensive like this because it makes it harder, and scares away more people. I think the current system is good enough on its own.
- That being said, I do agree that the current system doesn't really make users show why they want to join; perhaps require an actual article that they would edit, as before, but nothing beyond that.
kenny2scratch Talk Contribs Directory 04:37, 25 January 2018 (UTC)
- Interesting; I do see what you are saying, Customhacker. But I also see what Kenny2scratch is saying. I don't think it would hurt to add another small thing, like "Please explain why you want to join the wiki in your request notes."
- I don't think that's too much, is it?

bigpuppy talk ▪︎ contribs 00:27, 26 January 2018 (UTC)
- I would ask the question of whether we want to build a skilled community or a community with vision. @customhacker Experience certainly builds the kind of vision which you reference, and therefore I just don't believe that it is as important for a first-time wiki applicant.
Makethebrainhappy (talk | contribs) 11:00, 30 July 2018 (UTC)
- As A user who used the request notes recently, I agree with Customhacker. There isn't so much to do for New Wikians so I think we might as well make sure the people who are doing something useful stay there, while the people who doing anything useful (like me) stay out of the way.
Dude613 (talk | contribs) 19:18, 24 August 2020 (UTC)
|
Not Done doesn't get enough attention
One of them is done, Not Done discussions are collapsible
So I was browsing through Scratch Wiki talk:Community Portal/Not Done and realized that all of the discussions had been moved there and left to rot simply because they happened to last longer than an archive period. I suggest that we do at least one of the following things:
- Don't have a separate Not Done page at all and keep the not done discussions on the main CP.
- This would be effective but not feasible.
- Pros
- Great at keeping attention on topics.
- Cons
- Would likely break links and increase CP loading time.
- Link to them in a more obvious way
- This would be feasible but potentially not effective.
- Pros
- Saves space, keeps links.
- Cons
- Doesn't really solve the problem. Nobody wants to click an extra link just to get to topics they might not even care that much about. From my point of view, people comment on discussions because they're new and they want to get their opinion in. When a discussion takes an extra click to get to and has been rotting for so long, it no longer is attractive to comment on. Also, the Not Done page actually feels like an archive more than another discussion page - thereby discouraging new comments on it.
- Have an entirely separate page for not done topics (maybe "Scratch Wiki talk:Not Done"?).
- This would be partially feasible but potentially effective too.
- Pros
- Wouldn't break links (redirects exist, people), and would remove the feeling of an archive since it's a talk page of its own; would also save space on the actual CP because the content is literally in another page.
- Cons
- Still needs another click, and still seems too separate from the actual CP.
What are your thoughts? Do you have another suggestion for this problem? Do you have an opinion on or amendment to one of the current suggestions? Discuss!
kenny2scratch Talk Contribs Directory 14:12, 7 February 2018 (UTC)
Discussion
|
---|
- I think putting {{Scratch Wiki talk:Community Portal/Not Done}} is better - we can still put them here, and no problem for page size.
Apple502j Talk/Activities 2,229edit 02:15, 8 February 2018 (UTC)
- Page size would still be a problem - the point is, there is so much content here that browsers need a long time to load the page. Also, by transcluding the not done page, it has to parse the contents of that page anyway, so the only thing that does is increase loading time.
kenny2scratch Talk Contribs Directory 03:36, 8 February 2018 (UTC)
- This is something that definitely needs to be addressed, I personally think the last option is the best, but it is a hard one.
-Vuton- (Talk 💬 | Contribs 💾 | Pages 📚) 22:40, 8 February 2018 (UTC)
- I also vote for the last option.
MartinWollenweber Talk Contribs Directory 07:42, 19 February 2018 (CET)
- ^
banana439monkey (Talk | Contribs | Scratch | Edits (3,138)) 12:52, 19 February 2018 (UTC)
- Something like that is mentioned in different recent posts + continued at: #A little reorganization of old topics
MartinWollenweber Talk Contribs Directory 12:39, 22 February 2018 (CET)
- I suggest adding a link in page options.
banana439monkey (Talk | Contribs | Scratch | Edits (3,138)) 13:19, 24 June 2018 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
Offtopic :D
This topic is not getting enough attention :D
This topic is in the place that isn't getting enough attention :D
12944qwerty Talk Contribs Scratch 16:34, 22 May 2019 (UTC)
- This suggestion might seem bit idiotic, but it'll get the job done. How about we make every active user post at least one comment on a ND Topic once a month?
NYCDOT [ Talk Page | Contributions | Directory ] 22:17, 12 June 2019 (UTC)
- ...no? Forcing users to do anything is not how we work...
kenny2scratch Talk Contribs Directory 10:50, 26 June 2019 (UTC)
- Force users? No way! Plus, what would be the punishment if they don't comment?
TenType (talk | contribs) 20:34, 4 August 2019 (UTC)
- Why was this marked as done? It seems like the discussion is still ongoing.
Groko13 (talk | contribs) 15:17, 9 June 2020 (UTC)
- One of the solutions that ken had layed out is marked as done, not the entire discussion.
12944qwerty Talk Contribs Scratch 15:46, 31 July 2020 (UTC)
- Just an idea, we could add the CPND TOC onto the CP page to link to it.
12944qwerty Talk Contribs Scratch 15:48, 31 July 2020 (UTC)
|
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}}
(2,056)) [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)
Discussion
|
---|
- 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.
Drunken 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,229edit 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.
Drunken 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.
Drunken 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.
Drunken 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.
Drunken 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)
|
Not Done
Look at the OP
I know someone already brought it up...
Anyways, Not Done is not getting any attention. I know that Kenny2scratch already added “Things To Do” on the left sidebar, and the TOC of Not Done, yet no one seems to notice it. I think that we should release an announcement to all existing editors about ND, and all incoming users about ND on their welcome page. In fact, I’m going to add that to my welcome right now.
Any thoughts?
NYCDOT [ Talk Page | Contributions | Directory ] 23:53, 19 June 2018 (UTC)
Discussion
|
---|
- Nice idea, support!
asqwde talk | contribs 12:06, 20 June 2018 (UTC)
- Thanks!
NYCDOT [ Talk Page | Contributions | Directory ] 15:15, 20 June 2018 (UTC)
- Support, I think that is a great idea.
Purplewolves (talk | contribs) 20:32, 21 June 2018 (UTC)
- Thanks for support!
NYCDOT [ Talk Page | Contributions | Directory ] 22:15, 21 June 2018 (UTC)
- No worries.
Purplewolves (talk | contribs) 22:53, 21 June 2018 (UTC)
- Support better way to mark not done. Should the TOC on the CP mark out all the not done discussions in a different text color, or something like that? One idea
KrIsMa user | talk | contribs | edits 03:45, 24 June 2018 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
Perhaps make all of the Not Done topics have bold titles? That should attract attention to them for those who browse the TOC.
kenny2scratch Talk Contribs Directory 03:47, 24 June 2018 (UTC)
- Maybe what we could do is put the Not Done Topics in Red in the TOC of the CP, the done topics Green in the TOC of the CP, and the in progress discussions the blue color it currently is.
NYCDOT [ Talk Page | Contributions | Directory ] 12:47, 24 June 2018 (UTC)
- I agree with KrIsMa, Kenny2scratch, and NYCDOT on having some way to show which topics are done and which are not done, but how would we make topics show as a different color in the table of contents?
bigpuppy talk ▪︎ contribs 15:31, 24 June 2018 (UTC)
- That...is a really good question. I have no idea. I really don't.
NYCDOT [ Talk Page | Contributions | Directory ] 19:22, 24 June 2018 (UTC)
- I noticed that Jedibrine's userpage's TOC has different colors and font. You can ask how they did it.
12944qwerty Talk Contribs Scratch 20:18, 5 February 2019 (UTC)
- A very simple solution would be to put the {{done}} and {{not done}} templates in the title of the post instead of right below the title. If everyone put
{{not done/done}} {{-}} <title here...> in the titles of their posts, everyone could easily see whether a post is done or not. Here's an example. It even shows up bold in the TOC! I see no reason why we shouldn't implement this, considering that the CP already says to put {{not done}} at the start when creating a new post.
Groko13 (talk | contribs) 01:23, 27 July 2020 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
I give my support. Nice idea, but I also agree with Kenny2Scratch with the idea about making the titles bold.
Filmlover12 (talk | contribs) 13:53, 31 July 2020 (UTC)
|
Not done
It's as it says on the tin.
As part of this new revival of featured images (and leading on from #An Interval for Featured Images, I propose that we create a page similar in concept to S:WWS, where users leave new section saying which image they think deserve to be featured. This will clean up the CP (just slightly). At around the same time as Wiki Wednesday, the EWs/Bureaucrats review the suggestions and pick three images which will then to onto S:FI. If necessary, we could also edit the current Wiki Wednesday suggestion forum post to incorporate Featured Images too.
What do you think?
Drunken Sailor [ Talk | Contribs | More... ] 15:24, 4 August 2018 (UTC)
Discussion
|
---|
- This is a great idea! +1!

bigpuppy talk ▪︎ contribs 17:23, 4 August 2018 (UTC)
- Yes!
Millie S (talk|961 contribs|directory) 18:12, 4 August 2018 (UTC)
- Thank you! Any bits that need improving?
Drunken Sailor [ Talk | Contribs | More... ] 18:26, 4 August 2018 (UTC)
- I think the featured images are too minor to have a dedicated projectspace page. I propose instead to have a miscellaneous "homepage tasks" page (or something like that) where you can suggest news items, featured images, and edits to other things that appear on the homepage. Does that sound better?
kenny2scratch Talk Contribs Directory 19:51, 4 August 2018 (UTC)
- good idea
Millie S (talk|961 contribs|directory) 19:53, 4 August 2018 (UTC)
- Nice idea,
Support
asqwde talk | contribs 21:46, 4 August 2018 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
@Ken won't a homepage tasks page just get cluttered up? If they had to filter through edits and news items to find featured images, wouldn't it be harder for the admins? Also, having a dedicated project space is better because it's a) more obvious to Wiki Editors what the page is for, and seems less boring and gruelling than "homepage tasks", which sounds like just a big long list of stuff to do. And b) it would be easier for editors to suggest, because having a clearer Featured Image Suggestions would be more obvious to others what has already been suggested and what hasn't, et cetera. And c) having a dedicated page would make it so much easier to implement into the current WW forum post.
Drunken Sailor [ Talk | Contribs | More... ] 08:49, 5 August 2018 (UTC)
- We could have Scratch Wiki:Homepage Tasks and have there be a section for featured images, news things, and any other sections that may be needed. Then it wouldn't be as messy (if there were sections). Then we could make a shortcut called S:FEATUREDIMAGESUGGESTIONS (although that's a pretty long "shortcut") and have it redirect to Scratch Wiki:Homepage Tasks#Featured Image Suggestions. Or we could have Scratch Wiki:Featured Image Suggestions redirect to Scratch Wiki:Homepage Tasks#Featured Image Suggestions.

bigpuppy talk ▪︎ contribs 15:32, 5 August 2018 (UTC)
- If we're talking about shortcuts, how about S:FIS, since S:FI redirects to the featured images?
Drunken Sailor [ Talk | Contribs | More... ] 08:44, 6 August 2018 (UTC)
- Yeah, that'd probably be good.

bigpuppy talk ▪︎ contribs 16:33, 6 August 2018 (UTC)
- Support to Bigpuppy's and Drunken's last two suggestions. :) Also are we going to have somthing smilar to this?
Jakel181 (talk | contribs) 23:45, 17 December 2018 (UTC)
- Perhaps even simply add the featured image suggestions to that forum topic's purpose? That saves effort :)
kenny2scratch Talk Contribs Directory 02:32, 18 December 2018 (UTC)
- Nah, keep it on the wiki. Editors should be the only ones that can propose changes to the front page that are as minor as switching out the images.
NYCDOT [ Talk Page | Contributions | Directory ] 21:34, 15 May 2019 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
I have to disagree to you with that. Just like non-wikians are able to talk on the CP in forums and suggest Wiki Articles for WW, they should be able to suggest for Featured Images. +1 for putting in forum.
Also, is there already a forum topic for Featured Articles? (or is that WW?)
12944qwerty Talk Contribs Scratch 00:15, 16 May 2019 (UTC)
- After thinking about whether I agree with putting it in the forum or not, I've come to the opinion that I disagree, at least somewhat. Perhaps we could have that as one place where people suggest featured images, but look at the recent replies to that forum topic. We're on page seven right now, and the first reply on that page was in January of this year. Furthermore, the majority of the posts on that topic are not Wiki Wednesday suggestions. Now look at S:WWS. That shows that the last suggestion for an article was in December, not even January. If not many people outside of the wiki would like to submit articles for Wiki Wednesday, then why would they want to suggest featured images? Again, perhaps we could have that as an option, but I also feel like maybe the fact that that's the place where wiki editors suggest articles too causes it to be neglected by wiki editors.
bigpuppy talk ▪︎ contribs 18:58, 16 May 2020 (UTC)
- I'm not sure that I see the point of a page for homepage tasks. How much is there that actually needs to be done on the homepage? If someone wants to make changes, they could probably just post something on the Community Portal. Although, I think that the Wiki Wednesday and Featured Image suggestion pages could be grouped together/merged into one page on the Wiki, since they're both updated at the same time now. We could have the forums open to suggestions from non-Wikian Scratchers for both Wiki Wednesday articles and Featured Images, and I think that Wikians should just be able to suggest articles or images by editing the page directly in the wiki (is there a reason that they have to use the forums instead?). I think that this would make it easier to get Wikians and New Wikians into suggesting images and articles as well.
- So, to summarize, I think we should have a page for editors to suggest Wiki Wednesday articles and Featured Images for upcoming months, as well as a forum post for Scratchers. I don't really think lumping it into a "homepage tasks" page would be a good idea though, because it might not get a lot of attention (I mean, just look at S:CPND
).
Groko13 (talk | contribs) 03:37, 29 June 2020 (UTC)
- Drunken Sailor kind of already said this, but I wanted to add: a dedicated page would make it much easier to see which images have already been suggested and used previously as well.
Groko13 (talk | contribs) 04:01, 29 June 2020 (UTC)
- What if we also advertised the featured images along with the featured article each month, in the Wiki Wednesday forum post?
Groko13 (talk | contribs) 04:09, 29 June 2020 (UTC)
Supported by myself, but also if someone share featured images in Announcements forum, we need to upload another source manually; because Scratch Wiki photos isn't working on forums.
- @Groko13: I agree your opinion, but also we're adding stars to featured images/articles.
ahmetlii Talk Contributions Directory 11:18, 1 July 2020 (UTC)
- Ahmetlii, the Scratch Wiki is an approved image host.
bigpuppy talk ▪︎ contribs 16:04, 1 July 2020 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘Actually, the correct link is Image Hosting#Host List, sorry.
bigpuppy talk ▪︎ contribs 16:19, 1 July 2020 (UTC)
Yes, Scratch Wiki is an approved host; but it's not working correctly on forums as I know - if I'm wrong, sorry about that. You need to use real image source rather than file's link, also you cannot shrink it with [img] code.
ahmetlii Talk Contributions Directory 17:06, 1 July 2020 (UTC)
- I can see the image you posted here.
bigpuppy talk ▪︎ contribs 17:10, 1 July 2020 (UTC)
- Me too.
ahmetlii Talk Contributions Directory 17:19, 1 July 2020 (UTC)
- I think this is a really good idea although I don't think we need to edit the current Wiki Wednesday suggestion forum post. Good job!
Filmlover12 (talk | contribs) 09:44, 15 July 2020 (UTC)
- It seems tht we've come to a general consensus that a dedicated spot on the Wiki to suggest featured images should be added, but we haven't settled on how to implement it yet. Here are the suggestions I've seen:
- A page such as Scratch Wiki:Featured Image Suggestions for Wikians to suggest images.
- A forum post/editing the current forum post to allow featured image suggestions from people outside of the Wiki.
- A page such as Scratch Wiki:Homepage Tasks for suggested changes to the homepage, with a dedicated section for suggesting featured images, along with a shortcut and/or redirect.
- Merging a page for suggesting featured images into S:WWS and allowing editors to suggest images and articles directly on the page.
- Did I miss anything? Which of these should we implement, or does anyone have any other ideas?
Groko13 (talk | contribs) 04:29, 18 July 2020 (UTC)
- +1 for everything! This seems like a great idea! However, we must decide whether there should be another forum post for suggestions or if we edit the current post. I'm fine with either option.
TenType (talk | contribs) 19:38, 19 July 2020 (UTC)
|
New page for mall simulators
Sti_scratch has been inactive since a year (as of June 2020), and mall simulators/cryptocurrencies banned; they were a few users
Should we make a new page for mall simulators? Mall simulators are sort of big with the biggest mall simulator (Palace of Points) having more than 1400 members. Should we create a page for it?
Sti_scratch (talk | contribs) 04:55, 21 November 2018 (UTC)
Discussion
|
---|
- Maybe not as a whole page, but as a section in Simulation Projects?
bigpuppy talk ▪︎ contribs 16:11, 22 November 2018 (UTC)
- Mall simulators, let me explain, are studios where people can register and make projects and add them to the studio. These projects are shops, where people (that are registered in a mall simulator the shop is added in) can buy from. Mall simulators invent their own currency, not tradeable for real money, that is used within the mall simulator itself. So, I don't really think it would fit there since it's technically not a project.
Sti_scratch (talk | contribs) 08:54, 23 November 2018 (UTC)
- That's a new kind of shop. Actually, there is no article to write about it, I think.
Apple502j Talk/Activities 2,229edit 12:56, 23 November 2018 (UTC)
- Yeah, it means that we have to create two pages. for the shops and the sim itself.
Sti_scratch (talk | contribs) 03:34, 25 November 2018 (UTC)
- Couldn't shops in the mall simulators be a sub-section?
Purple_Ember (talk | contribs) 04:27, 31 December 2018 (UTC)
- @Purple_Ember Yeah, that works too.
Sti_scratch (talk | contribs) 06:00, 12 February 2019 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘I haven't heard of mall simulators until now, so I don't they're that necessary.
NYCDOT [ Talk Page | Contributions | Directory ] 22:24, 12 June 2019 (UTC)
- Actually, doesn't scratch ban users that participate in such activities? e.g. Mattcoin
Kritav (talk | contribs) 03:44, 4 September 2019 (UTC)
- Yes, some users banned because of that, including sti_scratch(not active anymore); and nobody want to use cryptocurrencies or mall simulators. Some of ironic. Maybe we should close this topic..
ahmetlii Talk Contributions Directory 11:23, 1 July 2020 (UTC)
|
Split the Paint Article
Needs doing
I was browsing the wiki and noticed that the Paint editor article (here) is really long and could possibly be split up into three different articles: History of the paint editor, 2.0 Bitmap Paint editor, and 2.0 Vector Paint Editor.
Jakel181 (talk | contribs) 20:55, 18 September 2018 (UTC)
Discussion
|
---|
- It is kinda long, but so is the CP, and do we split this? I realize it's not exactly the same thing, but it's not long enough to truly need splitting.
kenny2scratch Talk Contribs Directory 07:03, 19 September 2018 (UTC)
- in Japanese wiki, we did split it. At that time, "Types of Graphics", "Bitmap Editor", "Vector Editor", "Bitmap and Vector Comparison", "Paint Editor Conversion", "Interaction With Other Programs", "Example Uses", and "Alternatives" section is kept. Others are moved to version subpages, such as Paint Editor (2.0). Guess what will happen next January here, without the change.
- By the way, block workaround page is enough big to split, too, I think. It will be good for performance issues.
Apple502j Talk/Activities 2,229edit 08:24, 19 September 2018 (UTC)
- Currently, Bitmap Editor redirects to Paint Editor#Bitmap Editor. The bitmap editor is a large part of Scratch, so I think it needs its own article.
CrazyBoy826 Talk | Contribs | Scratch account 01:29, 22 December 2018 (UTC)
- So Vector Editor too?
Apple502j Talk/Activities 2,229edit 03:25, 22 December 2018 (UTC)
- I merged the previous 'The "Bitmap Editor" Page' topic with this one that I pulled from the archives, as I realize that the original one shouldn't have been archived. If the replies by CrazyBoy826 onwards seem out of context, that's why.
- Next question: "Paint Editor" will have to redirect to either Bitmap or Vector Editor (not a disambig page, because there's only two). Which one?
kenny2scratch Talk Contribs Directory 05:19, 22 December 2018 (UTC)
- There are some sections that cannot be on the two: Types of Graphics, Bitmap and Vector Comparison, Costume Pane, Basic Options, Interaction With Other Programs, Example Uses, History, and Alternatives. Keep them on Paint Editor.
Apple502j Talk/Activities 2,229edit 10:40, 22 December 2018 (UTC)
|
3.0 updating question
Not done
Should we rename the page Getting Started with Scratch to Getting Started with Scratch 2.0 and create a new page called Getting Started with Scratch 3.0? Because some people (Mainly teachers who's curriculum is based around S2) will still use the offline 2.0 editor.
Jakel181 (talk | contribs) 22:41, 8 January 2019 (UTC)
Articles to update for 3.0
Won't be done for a long time
Hello everyone, it's already January 2nd for me, so I figure I might as well get the preparations started.
Observations/Edit Guidance
Pages outdated upon 3.0 release are incredibly numerous. In most cases, one or more of the following edits can or should happen:
- Parts that talk about 3.0 features in future tense (e.g. "there will be a new paint editor") should be changed to use present tense (e.g. "there is a new paint editor") or past tense (e.g. "a new paint editor was introduced")
- Parts that talk about 3.0 changes in future tense (e.g. "the editor will be moved to the right side") should be changed to use past tense (e.g. "the editor was moved to the right side")
- Parts that mention dates in any tense should have their tense updated (e.g. "the official release will be January 2019" -> "the official release was January 2019")
- Parts that talk about 2.0 features in any tense (e.g. "the paint editor has these features") should be changed to use past tense (e.g. "the paint editor had these features")
- Parts that talk about 2.0 changes in any tense (e.g. "the editor was moved to the left") should all be changed to past tense if they haven't already.
- Take this opportunity to update things that weren't changed from 1.4 days as well.
Progress
Here is a list of articles that need to be updated (on their real versions in mainspace) upon the release of 3.0. You can probably already start updating them now. Articles marked with an asterisk (*) have updates available at Scratch Wiki:3.0 Articles/the article title, but:
Warning: | do not copy articles directly from their 3.0 versions! |
Though in most cases the information will be correctly updated, make sure to use your own judgement as to its accuracy.
Note: | Some of the articles listed below need to be created. |
Feel free to update this list yourself. Add any articles that you discover that need updates; remove articles that have been updated.
- Blocks
- File:Name bar.png
- File:Offline Editor Share Icon.png
Remember to take this opportunity to clean up articles as well as update them!
Fix typography or other writing issues as you come across them
We don't want to have to make a second sweep to clean up all the weird grammar from tense changes. Remember to fix the grammar and spelling of the articles as a whole while you update them.
Ask for help when you need it
If a page or redirect needs to be deleted or you need some other admin action, leave a message at Scratch Wiki talk:Community Portal/Admin Requests. If you don't specifically need admin actions, you can ask anyone you think would know the answer to your question.
Here's to a good 3.0 release!

kenny2scratch Talk Contribs Directory 05:40, 2 January 2019 (UTC)
Discussion
|
---|
- Oh I thought a bot would do it :P also are we saving old articles, for example Block Plugin(2.0)?
Jakel181 (talk | contribs) 12:19, 2 January 2019 (UTC)
- I thought we were moving 2.0 to a different place and 3.0 to where 2.0 used to be.
12944qwerty Talk Contribs Scratch 16:11, 2 January 2019 (UTC)
- Removed some articles from the list :)
Jakel181 (talk | contribs) 22:31, 2 January 2019 (UTC)
- Should Scratch Wiki:3.0 Articles/Front Page (2.0) be updated? It's so similar to Front Page, that it seems redundant to create a new page.
Jakel181 (talk | contribs) 22:46, 2 January 2019 (UTC)
- I noticed that many of the things needed to be changed were the same in 2.0 and 3.0. What should we do?
12944qwerty Talk Contribs Scratch 18:14, 3 January 2019 (UTC)
- Please don't externally link to Wiki pages! And please don't use underscores in links.
- I'm pretty sure it's the pictures that need updating. Would you mind adding all the files on that page that need updating to the #Progress list?
kenny2scratch Talk Contribs Directory 10:14, 4 January 2019 (UTC)
- Nothing has changed between 2.0 to 3.0 in Front Page, Messages, Discuss, Profiles. (Maybe more but these are all I've been to). The Project page and project editor are the only ones that have.
12944qwerty Talk Contribs Scratch 15:01, 4 January 2019 (UTC)
- The front page has changed, they've just been using the 3.0 skin for a while. Notice how the top bar is bright blue there and on project pages but a darker blue in discuss and the profiles as well as studios. Messages have also been at the 3.0 skin for a while. My stuff (and everything in it, like trash) has not been updated either.
EIephant_Lover (talk | contribs) 02:36, 5 January 2019 (UTC)
- Also I think "Images of stuff in 2.0 should be updated to 3.0." should be included.
VFDan Talk Contribs On Scratch 22:03, 28 May 2019 (UTC)
|
“Secret” Compliments
We all know Compliment Tuesday. To suggest compliments we have the S:CT page. It’s a great way to compliment people, but could be even better.
Right now you suggest a compliment, everyone who wants to including the person who was complimented can see it and get posted on CP.
So I thought that’s good but you do let look forward to the CP post because you know if you have been complimented.
I propose proposing compliments on a way no-one else can see apart from the organizer(s). This can be achieved by a Google Form.
Proposed new method:
- Users suggest compliments on Google Form entering all details as they would before
- End of the month (organizer)s have admin access to the form and gather responses
This way:
- Users will look forward to see compliments received and not seeing anytime of the month
- People will be more encouraged by the compliments
Ideas?
asqwde talk | contribs 07:28, 9 May 2019 (UTC)
Discussion
|
---|
- There are pros and cons to this... on one hand, people will be less self-conscious about complimenting if nobody knows it's them, but on the other hand some compliments either don't make sense if you don't know who it is or imply on their own who the person complimenting is. I do like the idea of looking forward to compliments rather than seeing them immediately, but the con to that is people might be disappointed if CT doesn't come out at the end of the month due to not enough people complimenting...
kenny2scratch Talk Contribs Directory 07:39, 9 May 2019 (UTC)
- I'm on board with this. I still would like to keep the non-secret compliments as a second option if we go about this. The main problem would be moderation. With anonymity, there is more of a chance that something mean would come out of it. An unwritten policy of CT is, if I see a disrespectful "compliment" it won't be included. If we were to use a google forum, we would have to have some way of knowing who compliment who, we can't just ask for a username since we can't verify it wasn't an impostor. Any ideas how to go about this?
Jakel181 (talk | contribs) 11:48, 9 May 2019 (UTC)
- Perhaps (again) an extension? Special:ComplimentTuesday sounds like an interesting idea...
kenny2scratch Talk Contribs Directory 11:50, 9 May 2019 (UTC)
- Guess who forked your report extension ;) (or possibly Special:ThankfulThursday :P)
Jakel181 (talk | contribs) 12:18, 9 May 2019 (UTC)
- +1 for a Special: page where compliments can be submitted and a way of suggesting public compliments
asqwde talk | contribs 16:23, 9 May 2019 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
But also,Scratch and Scratch Wiki are growing up with "Imagine, Program, Share".Here's an rejected example suggestion:
“
|
Private Messaging
When communication is public, people are more likely to be respectful because they know that everyone can see it. However, when posting PMs, people know that only the intended recipient can see it, so do not think as much before posting. Even if a "Flag PM" function is implemented, the Scratch Team currently does not have the resources to moderate it, because of the reason said before there would be a lot of inappropriate/disrespectful messages.
|
”
|
– Scratch Team
| Also,we can see other's compliments(Google Forms give this in finish of the form,right?).
Shortly:
- It's a bad idea because...
- It means a lot of disrespectful or other bad messages
- I have some questions about Google Forms security
- Also, we'll need a lot code(if we'll use the Wiki for this)
- And,we and Scratch Team have some notes about private messaging
- If we'll try to check all of messages,it'll mean more time and more work
- Anonymous and fake users have a big problem(in Google Forms)
Ahmetlii (talk | contribs) 20:59, 9 May 2019 (UTC)
- I would generally discourage the use of google forms for this kind of project given that you are seeking input from the entire community.
Makethebrainhappy (talk | contribs) 00:33, 10 May 2019 (UTC)
- I also disagree with using Google Forms because fake or anonymous users could abuse the feature. However, maybe Special:ComplimentTuesday could be the way to go...
TenType (talk | contribs) 02:53, 10 May 2019 (UTC)
- Google Forms are out by multiple Community and Wiki G/guidelines. A special page is the way to go. @Ahmetlii: If we're using a special page, problems solved include:
It means a lot of disrespectful or other bad messages
- Compliments would be reviewed before being shown. Inappropriate messages are vandalism and would be treated as such.
Solved
I have some questions about Google Forms security
- No Google Forms.
Solved
Also, we'll need a lot code(if we'll use the Wiki for this)
- Not a problem for me, it'll be fun!
Solved
And,we and Scratch Team have some notes about private messaging
- Compliments are shown to everyone - only who submitted the compliment is hidden. Not private messaging.
Solved
If we'll try to check all of messages,it'll mean more time and more work
- Not very much more, and @jakel181 has been doing a great job on CT so far, I'm sure he wouldn't mind looking through the compliments before he posts them.
Anonymous and fake users have a big problem(in Google Forms)
- Not with a special page!
Solved
- I think a special page is definitely the way to go. I believe the following are the only questions to really consider:
- Do we actually want compliments to be hidden from everyone (except the organizer and the submitter) until they are posted?
- If so, who do we want to review the compliments so that nothing is inappropriate?
- Do we actually want to allow anonymous compliments? (Note: This and the previous question are two separate questions - the answer to one does not imply any answer to the other.)
- If we do want to allow anonymous compliments, we will have to still also allow onymous compliments - people can just include their names in their compliments.
- This concludes my post.
kenny2scratch Talk Contribs Directory 08:33, 11 May 2019 (UTC)
- I think we should allow EW/Admins/Bureaucrats see in some fashion. (Maybe not all but a couple)
12944qwerty Talk Contribs Scratch 12:54, 11 May 2019 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
- Do we actually want compliments to be hidden from everyone (except the organizer and the submitter) until they are posted? -Yes, they are. (I don't need it :P)
- If so, who do we want to review the compliments so that nothing is inappropriate? -It's named as "be shy" :)
- Do we actually want to allow anonymous compliments? (Note: This and the previous question are two separate questions - the answer to one does not imply any answer to the other.)
-No, we don't because S:JOIN-if somebody want to send a message, they must join and login to the Wiki.
- If we do want to allow anonymous compliments, we will have to still also allow onymous compliments - people can just include their names in their compliments.
-They can use Scratch profiles to send a message - it's only a Wiki about Scratch.
Ahmetlii (talk | contribs) 17:03, 25 May 2019 (UTC)
No clear resolution
NYCDOT [ Talk Page | Contributions | Directory ] 22:35, 18 October 2019 (UTC)
- Probably this wiki won't need "secret" compliments anymore.
Ahmetlii (talk | contribs) 19:55, 10 May 2020 (UTC)
|
List of deleted pages
Done
(Brought up here after discussion here.)
So, there are currently four lists of deleted pages on this wiki:
- Mathfreak231's, which is the most comprehensive but is no longer updated in his absence
- Mine, which is a duplicate of Mathfreak's but hopefully more organized
- Jammum's Deleted Pages, which are more recent than either of the above
- Jammum's All Deleted Pages, which seems to be more recent and extensive but has the least information (it's only a list of titles)
I suggest (from jakel181's idea) that these become a single page in projectspace, something like "Scratch Wiki:Deleted Pages". This could be a Scratch Wiki Project.
- Advantages
- More organized
- One place for all
- Can be updated by anyone
- Disadvantages
- None I can think of off the top of my head
Thoughts? Shall we do it?
kenny2scratch Talk Contribs Directory 11:15, 26 April 2019 (UTC)
Discussion
|
---|
- I think we should! I like the style yours is in, snice it is more oragized, and a bit easier to find pages, so we should base the page off that.
Jakel181 (talk | contribs) 11:45, 26 April 2019 (UTC)
- +1 :)
NYCDOT [ Talk Page | Contributions | Directory ] 13:06, 26 April 2019 (UTC)
- Just to remind everyone, I have not finished my "All Deleted Pages" page at the time of posting this message. It will be contributed to frequently.
Jammum (talk | contribs) 14:55, 26 April 2019 (UTC)
- To Kenny2Scratch: This will be a great idea, as it will make it more accessible to people. If this get made, maybe put it could be put in the "Navigation" box on the side?
Yaov_1991 (talk | contribs) 21:37, 26 April 2019 (UTC)
- I think the page will not be notable enough to go there.
Jammum (talk | contribs) 07:02, 2 May 2019 (UTC)
- I don't think it goes in the sidebar, it's not that important; however, come to think of it, this is a nice candidate for a Scratch Wiki Project. Thinkest you that this is a suitable mission to embark upon?
kenny2scratch Talk Contribs Directory 14:24, 14 May 2019 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘I say aye.
Jakel181 (talk | contribs) 01:27, 15 May 2019 (UTC)
- @Kenny2scratch, let's do that!
NYCDOT [ Talk Page | Contributions | Directory ] 20:01, 18 May 2019 (UTC)
- Are we going to do this?
Jammum (💬 Talk - ✍️ Contribs - 🐱 Scratch) 11:11, 31 May 2019 (UTC)
- Okay, I just created a page called User:TenType/Deleted Files, was scrolling through the Community Portal, and found this discussion.
Maybe this page could contain pages only and not files? (I really spent a lot of time and effort onto my deleted files page) Anyways, still waiting for a response on whether or not this project will be started.
TenType (talk | contribs) 05:53, 24 June 2019 (UTC)
- Why not? It sounds like a great idea; let's get started. How do you guys find deleted pages anyway (just wondering)?
Groko13 (talk | contribs) 15:00, 30 December 2019 (UTC)
- Why hasn't this happened yet? :P
VFDan Talk Contribs On Scratch 16:15, 9 April 2020 (UTC)
- I don't know, VFDan. It's a good idea, and I would love to see this on the wiki.
Ew10528 (talk | contribs) 11:55, 27 May 2020 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
Should I delete this page (https://en.scratch-wiki.info/wiki/User:Jammum/Deleted_Pages)?
Dude613 (talk | contribs) 19:42, 15 July 2020 (UTC)
- Firstly, that page is in my user space, and that can only be deleted if I wanted it. Secondly, only Experienced Wikians and above can delete articles. Thirdly, you used the wrong link syntax to link that page.
Jammum (💬 Talk - ✍️ Contribs - 🐱 Scratch) 06:15, 16 July 2020 (UTC)
- I now think the list of deleted pages in Scratch Wiki space might not be necessary.
Jammum (💬 Talk - ✍️ Contribs - 🐱 Scratch) 09:19, 23 July 2020 (UTC)
- I personally think it's a good idea and it will make it a lot more organised so yeah.
Filmlover12 (talk | contribs) 17:30, 28 July 2020 (UTC)
- I have already replied to this saying this such list would not be necessary, but I think such list might have no proper use at all.
Jammum (💬 Talk - ✍️ Contribs - 🐱 Scratch) 13:59, 11 August 2020 (UTC)
- Can this discussion be finished? Although no other users have no supported this, my point in this discussion about such page not being useful might conclude this discussion if possible.
Jammum (💬 Talk - ✍️ Contribs - 🐱 Scratch) 15:38, 4 September 2020 (UTC)
|
Block Problems
Not done, as blocks are still unfinished or broken
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)
Discussion
|
---|
- 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????
VFDan 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)
|
Tinkercad Codeblocks
Tinkercad has a new feature called Codeblocks that looks similar to Scratch. It has hat blocks and variables. I think this could have a page on this wiki.
LiamSapp123 (talk | contribs) 19:47, 27 September 2019 (UTC)
Discussion
|
---|
- Does it have a specific connection to Scratch in particular though? We don't have a page on Blockly, even though it's a similar concept (and even though 3.0 has Blockly code in it).
kenny2scratch Talk Contribs Directory 04:35, 28 September 2019 (UTC)
- Maybe we should have one about Blockly
Congyingzhou (talk | contribs) 13:31, 13 November 2019 (UTC)
- I agree that we should make one on Blockly.
Ravenclaw900 (talk | contribs) 01:56, 19 January 2020 (UTC)
Further discussion needed
kenny2scratch Talk Contribs Directory 11:11, 3 March 2020 (UTC)
- There is already a page on Blockly and since it is involved with how Scratch works, I think the page can be kept. As for Tinkercad Codeblocks, it is not completely related to Scratch other than the fact that it resembles it. I think it could be listed in Alternatives to Scratch, due to its similarity to Scratch.
- Also, Scratch modification pages are no longer allowed to be created, and Tinkercad Codeblocks might be of a similar level (even though it is not a Scratch modification). Other pages about Scratch-like programming languages that are not modified from it do not have articles as far as I know.
Jammum (💬 Talk - ✍️ Contribs - 🐱 Scratch) 17:52, 4 September 2020 (UTC)
|
Scratch Wiki Adventure
Not done
On Wikipedia, there is an option for new Wikians to complete the Wikipedia Adventure. This teaches them skills and covers all the basics of using Wikipedia. I think it'd be a good idea to create a Scratch Wiki Adventure of our own to teach new Wikians the basics of the Scratch Wiki. This would include editing tips, rules, etiquette, etc. I'm wondering what people's thoughts are on this idea and/or if anyone would like to work with me on creating this.
54329 (talk | contribs) 17:08, 20 November 2019 (UTC)
Discussion
|
---|
- +1
12944qwerty Talk Contribs Scratch 22:41, 20 November 2019 (UTC)
- I hope you're prepared to put in the amount of work involved, because The Wikipedia Adventure is really involved (I've done it once before) and a lot of stuff has to be created for it to work. I like the idea, but I don't know if anyone here has the follow-through to actually focus on a project like this that could take a week or more to make.
- If you think you can commit yourself (and furthermore get others to commit themselves) you can make a Scratch Wiki Project of it. Good luck!
kenny2scratch Talk Contribs Directory 03:22, 21 November 2019 (UTC)
- Woohoo; we got bureaucratic approval! I think we can do it (maybe not as well as the Wikipedia Adventure, but still good). I'll start thinkin' up some basic ideas to start us off. If anyone is interested in working with me on this, please let me know on my talk page.

54329 (talk | contribs) 05:54, 21 November 2019 (UTC)
- Isn’t this going to be a duplicate of the welcome tutorial?
Jammum (💬 Talk - ✍️ Contribs - 🐱 Scratch) 06:41, 21 November 2019 (UTC)
- No, the Wikipedia Adventure is really involved and more interactive.
TenType (talk | contribs) 06:44, 21 November 2019 (UTC)
- Adding on, when I did it, it felt a lot more like a game/activity than a guidebook. It allows the user to actually collaborate, talk to people and create/edit a page all in a sandbox setting. It helped me learn the basics of Wikipedia far more than a guide could (probably because I was really interested in it and getting those shiny badges was nice).
54329 (talk | contribs) 06:53, 21 November 2019 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
Description | Status | Owner | Started | Links |
Create the Scratch Wiki Adventure "game" to help teach new Wikians the basics of the Scratch Wiki in a fun, interactive setting. | Creating files for interactive tour... | - Owner: 54329
- Assigned:
- TenType
- 12944qwerty
- Apple502j
- Scratch-Coding
- Jammum
- Dominic305
- JJBullet
- Kenny2scratch
- Nambaseking01
- GrahamSH
- ahmetlii
| 11/21/2019 | Project results | Project page | Project discussion |
kenny2scratch Talk Contribs Directory 10:45, 21 November 2019 (UTC)
- I can help some tech stuff maybe?
Apple502j Talk/Activities 2,229edit 17:55, 21 November 2019 (UTC)
- I can help too!
12944qwerty Talk Contribs Scratch 22:33, 21 November 2019 (UTC)
- I want to help too, so should I add myself or should 54329 do it as he's the owner?
12944qwerty Talk Contribs Scratch 01:38, 22 November 2019 (UTC)
- In reply to both of you: Thanks for offering to help out! I'll add both of your names to the list. For future people that wish to help: feel free to just add your name under the "Assigned" section.
54329 (talk | contribs) 05:11, 22 November 2019 (UTC)
- I just took a quick glance at the Wikipedia Adventure, and that looks cool! I created a very different page a while ago with the same goal of educating New Wikians using a sort of quest system - you can check it out at User:Bigpuppy/Quests.
It seems like this would be very different than that, though. Good idea!
bigpuppy talk ▪︎ contribs 02:32, 27 December 2019 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘That's super cool that you made a quests page. This will be semi-similar. Feel free to stop by if you have any ideas for it. wink wink
54329 (talk | contribs) 08:03, 31 December 2019 (UTC)
We could make a scratch project and link it when people get welcome notficiations on their talk page.
ACS_Scratch_admin (talk | contribs) 14:56, 21 July 2020 (UTC)
I'm new to the scratch wiki and am kind of counfused so i think this would be a great idea
AirMargaret33 (talk | contribs) 21:44, 3 September 2020 (UTC)
|
Suggestion: Mention that the Privacy Policy and Disclaimers are in German
Currently, the links under the 'Legal' category do not are not mentioned that they are in German. I suggest that the footer mentions that the content under the Legal category are in German.
Without mentioning that, some people might be confused that they are in German, and not English. They also cannot be translated into English without it being inaccurate.
Jammum (💬 Talk - ✍️ Contribs - 🐱 Scratch) 13:21, 28 March 2020 (UTC)
Discussion
|
---|
- Why would they be German?
OurPrincess (talk | contribs) 16:35, 28 March 2020 (UTC)
- The Wiki servers are located in Germany and therefore follow the rules/regulations of Germany.
Makethebrainhappy (talk | contribs) 00:33, 29 March 2020 (UTC)
- Would you be amenable to using the external link marker on them instead? Putting "(German)" on a footer link seems unorthodox...
kenny2scratch Talk Contribs Directory 10:33, 29 March 2020 (UTC)
- The servers are German because they are owned by Martin Wollenweber, who lives in Germany.
OurPrincess (talk | contribs) 11:55, 29 March 2020 (UTC)
- Maybe the Privacy Policy and the Disclaimers can be individually labelled that they are in German, or is that still 'unorthodox'? They could have 'in German' put in brackets after them.
Jammum (💬 Talk - ✍️ Contribs - 🐱 Scratch) 13:29, 29 March 2020 (UTC)
- I think it's fine the way it is, but it should get translated for other wikis so we know what happens to our data.
Dominic305 Talk Contribs (1,771) Scratch Directory 17:35, 7 April 2020 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
Did you read the OP? They can't be translated accurately.
Having a notice at the top of the actual pages saying something similar to what I say on my userpage (the "many other wikis link here" thing), ideally translated into everything, would also be fine for me - I'm only opposed to changing the footer.
kenny2scratch Talk Contribs Directory 11:03, 8 April 2020 (UTC)
|
Scratch Wiki YT Channel
Hi everyone! I wanted to put a little feeler out there to see who was interested in participating/creating content for a possible Scratch Wiki YT Channel. We would publish wiki-like content within YT's video format. We could then link to this content from within the Wiki. You could for example create a Scratch tutorial, run-through a certain block or feature, or discuss a recent community venture you participated in. If y'all are interested in seeing this idea come to fruition, please comment to express your interest and volunteer yourself for content creation. Thanks!
Makethebrainhappy (talk | contribs) 14:51, 27 April 2020 (UTC)
Not done
Per title.
bigpuppy talk ▪︎ contribs 01:13, 29 June 2020 (UTC)
Hello there!
In case you didn't know, I'm a Forum Helper (https://scratch.mit.edu/studios/3688309/) on Scratch, which means I generally help out on the the Scratch discussion forums. One day, I headed over to the Community Portal and it seemed like a sort of "discussion forums" within the Scratch Wiki, and I understand that the concept is different, but for me it personally seemed that way.
Anyways, I mostly help around a lot on the Suggestions forum, which, yet again, redirects to the Community Portal since there are a lot of suggestions for the Scratch Wiki here. One difference is though, that the Scratch Team and some Scratchers (like me) enforce the rule of "constructiveness" while making posts, and I'm pretty sure most of you know what that means but I'll just clarify:
- It means that one does not simply post "Support!", "Good idea!", or "+1!" and explain why they like the suggestion, that they provoke discussion, and look for possible issues instead of continuosly leaning on one side, like "I love this suggestion" or "I hate this suggestion"
- It means that one does not simply add one sentence to act as if their post is constructive. For example, "Support, because this might be useful for many Wikians!" seems constructive but it isn't really constructive, because they're not stating how it would be useful for many Wikians or why it would be.
Now, I've been looking around in the CP, and I've been seeing a couple of responses just saying "+1!" or merely "Support!" without provoking any further discussion and merely showing your satisfaction. So I thought, maybe, we could enforce the constructive rule on the CP as well. Especially because the ideas here much more mature and complex, and not like Scratch where it's just new blocks or random new features.
I do agree that many people are already following this rule, but maybe just enforce it more? I do think it'll be incredibly helpful for the type of suggestions being given here.
wow... that's... long
Nambaseking01 (talk | contribs) 09:31, 4 July 2020 (UTC)
Discussion
|
---|
- While I understand what you're saying, I don't think it would be necessary to enforce constructiveness here. The discussion forums and Community Portal are two fundamentally different things. The Scratch Team has an extremely large userbase. Thus, there are many possible people contributing to discussions, and also many people that decisions will affect. It makes sense for there to be an expectation that people are constructive. However, as of writing, there are 72 active users on the Scratch Wiki. This is much smaller than the userbase on Scratch. And yes, you might argue that our "userbase" is not just our editors but also our readers; yes, but our editors are the ones who are supposed to make the decisions here.
- Anyway, on the topic of having fewer active users on the wiki, it helps to see if someone supports your idea. And it matters, too. If multiple people like your idea, it probably has a better chance of being successful here. This is in stark contrast to the Suggestions Forum, where that is simply not true. This is why simply saying "support" or "no support" on that forum is not helpful, nor constructive.
- In summary, yes, I think it would be helpful for people to provide a reason that they like or dislike an idea (perhaps we could recommend it), but I don't think it's necessary to enforce it. I don't think that it's fair to compare the convention here to the convention on the Suggestions Forum, because the CP is fundamentally different from the Suggestions Forum and the discussion forums in general. That said, if someone dislikes an idea, I think it is more necessary to provide reasoning than if they like it, as they are disagreeing with the reasoning provided by the OP, and thus need to provide their own reasoning.
- So, to end this off, I agree that we should recommend it, but I disagree that we should enforce it.
bigpuppy talk ▪︎ contribs 14:13, 4 July 2020 (UTC)
- Good idea! I suppose that could work too.
Nambaseking01 (talk | contribs) 09:23, 6 July 2020 (UTC)
- Depends on what you mean by "enforce". The policy of discussion over polling already exists, however if by "enforce" you mean removing comments like Support! is not a good idea, as such comments generally should be left as-is, however, explaining that such a comment holds no weight can be done.
Naleksuh (talk | contribs) 22:17, 19 September 2020 (UTC)
|
Scratchblocks Plugin not Working
On any wiki page I go to that has the Scratchblock Plugin, all of the blocks end up half-rendered, except for the text. Are other people seeing this?
Ravenclaw900 (talk | contribs) 13:30, 9 July 2020 (UTC)
Discussion
|
---|
- This does not happen to me - the bug might only happen to the device or computer you are using the Scratch Wiki on.
Jammum (💬 Talk - ✍️ Contribs - 🐱 Scratch) 14:18, 9 July 2020 (UTC)
- This might not be of much help but have you tried realoding the page or freeing space on your computer/device sometimes when the tablet I use is out of space/storage everything malnfuctions
Godslamb (talk | contribs) 15:09, 9 July 2020 (UTC)
- What device/OS/browser are you using?
bigpuppy talk ▪︎ contribs 15:37, 9 July 2020 (UTC)
- If you are using a phone it is probably because the screen is too small so the wiki malfunctions. If you are on another device then I think it is because your storage is full, so in that case you need to free up space.
Filmlover12 (talk | contribs) 17:28, 9 July 2020 (UTC)
- I'm using Brave Browser on a Macbook Pro, with about 70GB left on the hard drive. I have tried both reloading and clearing the cache, to no avail.
Ravenclaw900 (talk | contribs) 22:15, 10 July 2020 (UTC)
- Hmm, could you try using a different browser, like Firefox or Chrome? That might be the issue.

bigpuppy talk ▪︎ contribs 23:00, 10 July 2020 (UTC)
|
Require custom welcome messages to be transcluded
When custom welcome messages on new Scratch Wikians' talk pages are not transcluded from a templat (when the entire contents, including the formatting is copied and pasted onto the talk page), it could lengthen the talk page.
I suggest that there should be a rule (unless one already exists) requiring all custom welcome messages (this excludes the default Scratch Wiki welcome message) to be transcluded as a template (from the creator's userspace, obviously).
Jammum (💬 Talk - ✍️ Contribs - 🐱 Scratch) 16:04, 10 July 2020 (UTC)
Discussion
|
---|
- #Standardized signatures Transcluded pages are loading slower, also the default welcome message is too big for transclusion.
ahmetlii Talk Contributions Directory 18:14, 10 July 2020 (UTC)
- No, transcluding messages should be prohibited as this can result in edits years later or the meaning changed. I would say require them to be substituted. But really there's no need for more than one welcome message, so piling on 4-5 welcomes is not a good idea.
Naleksuh (talk | contribs) 22:17, 19 September 2020 (UTC)
|
A flaw in the "Random Page" button I see
Not done
So, I've been using the Scratch Wiki for almost 3 months without an account, and about 1 with, and I see a flaw in the "Random Page" button. Sometimes it links you to disambiguation pages, and I'm just wondering- is this really useful? Because most people (I'm assuming) who use the RP (Random Page) button just want to find an article they can revise or look at, and I find that whenever a disambiguation page while clicking the RP button, I just click the RP button again, and find an article. I have a suggestion, maybe have an option to toggle if you want to not go to disambiguation pages while clicking the RP button? Just a little suggestion.
Foxlife37 (talk | contribs) 23:16, 14 July 2020 (UTC)
Discussion
|
---|
- See wikipedia:mw:Help:Random page; I think that since Special:Random is a built-in MediaWiki thing, this would require some sort of extension. That said, I'm no MediaWiki guru, so I could be wrong about that. An easy solution would be to put disambig pages in their own namespace; though this has the downside that they won't show up in search. Again, I'm not a MediaWiki guru, so I don't know whether there's an easy solution to that downside.
- I really wanted to make a joke about not being able to play TenType's Disambiguation Dodge, but then I realized you were just suggesting a way to toggle seeing disambiguation pages...
bigpuppy talk ▪︎ contribs 23:25, 14 July 2020 (UTC)
- Haha, I was going to make that joke too!
I don't think we should move disambigs to their own namespace though; that seems like quite a drastic change just to make sure that they don't show up via the Random Page button.
Groko13 (talk | contribs) 23:31, 14 July 2020 (UTC)
- Thanks! I now have an idea that came from your answers. It's 100% not related to the problem, but it's definitely a cool idea! Oof so much happened. I had to re-write this because of an edit conflict, and I guess this is an example of an idea that came from a problem. And wow is this hard on a phone...
Foxlife37 (talk | contribs) 23:37, 14 July 2020 (UTC)
- Maybe we can add mw:Extension:Disambiguator (jawiki has it)
Apple502j Talk/Activities 2,229edit 13:59, 16 July 2020 (UTC)
- I personally enjoy finding disambigs in random page. I think they are useful resources to build up the wiki (on a particular subject perhaps, or a set of linked pages). I see no reason it should simply be removed or excluded, which furthur tampers with it being a random page from anywhere on the wiki. If you want a different page, you could always simply pres the random page button multiple times.
Naleksuh (talk | contribs) 22:17, 19 September 2020 (UTC)
|
Merging Cloud Data Articles?
I think that there are far too many articles on Cloud Data. I think these should all be merged or certain ones removed to reduce the amount of potential editing.
ContourLines (talk | contribs) 06:42, 15 July 2020 (UTC)
Linking Style Sheets
Not done
Could anyone please tell me if it is possible to link style sheets similar to
<link rel="stylesheet" href="filename.css">
in HTML? If it is then could you please tell me how?
R4356th (talk | contribs) 18:33, 15 July 2020 (UTC)
Discussion
|
---|
- It's "perfectly" impossible for the Scratch Wiki. It will need FTP server access. You cannot do it if you're not a bureaucrat.
ahmetlii Talk Contributions Directory 19:08, 15 July 2020 (UTC)
- But why would I need FTP server access if the linked style sheet is on the wiki?
R4356th (talk | contribs) 19:23, 15 July 2020 (UTC)
- Wiki pages cannot run HTML codes itself.
ahmetlii Talk Contributions Directory 20:40, 15 July 2020 (UTC)
- While this is impossible. You can, however, use your common.css file in your userspace which will effect the style of the wiki skin.
ContourLines (talk | contribs)
- @Ahmelii, you are wrong. I suggest you to test it by yourself. @ContourLines, I am not asking about changing the style for only me; I am asking about changing the style for the contents of that page for everyone.
R4356th (talk | contribs) 11:56, 16 July 2020 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
@R4356th, are you sure about that? I cannot run it in my CSS sheet, I will try again. Did you test it in the Wiki?
ahmetlii Talk Contributions Directory 12:53, 16 July 2020 (UTC)
- I believe @Kenny2scratch might know. They seem to of effected the style of all their userspace.
ContourLines Talk | Contributions | Directory 18:23, 16 July 2020 (UTC)
- You can not run the wiki on just html and css files. It needs the files that run the server accsept of it too like the php files.
ajsya Profile | Talk | Contribs 11:21, 21 July 2020 (UTC)
- Replying after a month, well, @Ajsya and @Ahmelii, you can have HTML on the wiki. See Help:HTML.
R4356th (talk | contribs) 17:09, 24 August 2020 (UTC)
- But also, the wiki softwares don't use some tags. We're already using "<div>" tag, but the wiki software compiles it for HTML.
ahmetlii Talk Contributions Directory 09:07, 25 August 2020 (UTC)
- But it does not mention the link tag in particular.
R4356th (talk | contribs) 03:14, 27 August 2020 (UTC)
|
Custom Signatures
Would it be a violation of S:USERSPACE to replace the contents of another user's custom signature which has all its code and formatting on the page itself with a transclusion of the template it is from?
Jammum (💬 Talk - ✍️ Contribs - 🐱 Scratch) 11:43, 16 July 2020 (UTC)
Naming Blocks
Not done
When referring to Scratch's blocks within an article, what format should be used? Some articles follow the capitalization of the title (like Tempo (block)), some articles use all lowercase (like Abs () (block)), and some use the block plugin (e.g. Set Video Transparency to () (block)). If there's not a consistent format, then there probably should be one.
(Thanks to Naleksuh for bringing this up)
Groko13 (talk | contribs) 17:33, 30 July 2020 (UTC)
Discussion
|
---|
- I looked at the Editing Conventions, and they say that "capitalization for blocks remain the same as the title; for example, Tempo (block) changes to 'Tempo' and Project Downloading (1.4) changes to 'Project Downloading.'" If this is the case, should we change articles that don't follow this capitalization to match? What about articles that just use scratchblocks code?
Groko13 (talk | contribs) 17:33, 30 July 2020 (UTC)
- I am okay with the block name the same as in the title, however I do think that this means the title system should be changed, as it is currently using incorrect grammar, unnecessary disambigs, and not even aligning with the actual names used in Scratch
- For example:
- * If on Edge, Bounce (block) will become "if on edge, bounce" (yes, titles that start with a lowercase letter *are* possible - can be done individually or via the infobox)
- * Boolean Block will become "Boolean block"
- * How to Move Sprites with the Arrow Keys will become "How to move sprites with the arrow keys"
- * Advanced Topics (forum) will become "Advanced Topics"
- * New Scratcher Status will become "New Scratcher status"
- * Scratch Design Studio will stay "Scratch Design Studio"
- Any objections? Naleksuh (talk) 18:46, 30 July 2020 (UTC)
- It's ironic that I have to be this person this time.
- I brought this up nearly 3 years ago, and most people agreed that capitalization here is not ideal. However, Scimonster, an admin who predates me by nearly 6 years, came out of inactivity just to push down the idea. He quoted JSO, a founder:
“
|
I'm sorry to disappoint you all, but I really think this is a change we should not put our efforts and time in. I think the titles look just fine as they are, but most importantly I think it's not worth either breaking every single link ever created to the wiki or messing up the wiki by creating hundreds of redirects.
|
”
|
– JSO
|
- I appreciate your eagerness to improve the Wiki, but suggesting sweeping radical changes literal hours after being accepted is not the way to go about it.
- Also, fight your own fights. Why did you make Groko bring it up instead of posting it yourself?
kenny2scratch Talk Contribs Directory 20:35, 30 July 2020 (UTC)
- So, we should make sure all pages follow the same capitalization as the title, correct? What about pages with scratchblocks code? Personally, I think we should change them if the scratchblock replaces the bolded words in the intro paragraph, like in Set Video Transparency to () (block), but leave scratchblocks elsewhere.
Groko13 (talk | contribs) 04:39, 31 July 2020 (UTC)
- "I appreciate your eagerness to improve the Wiki, but suggesting sweeping radical changes literal hours after being accepted is not the way to go about it." I do not appreciate the condescending tone here. Especially not when "literal hours" was all I needed to find that multiple blocks were named wrong for over a year and half. I try to be polite and informative. Granted sometimes I fail at this. This attempts neither.
- I do not agree with the text's capitalization matching the title (although I also disagree with how the titles are, so this may be null to begin with). I also do not think blocks mixed with text is a good idea, especially in introduction. Naleksuh (talk) 17:48, 1 August 2020 (UTC)
- If you disagree with the Editing Conventions or titles, you should bring it up in a separate topic (although, as per what Ken said, a change in title case has been suggested and rejected multiple times now).
Groko13 (talk | contribs) 20:18, 3 August 2020 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
Back to my original question; the Editing Conventions do not say whether blocks within the article should match the capitalization of the title; it only has guidelines for the bolded words in the intro paragraph. I think that a consistent way to refer to blocks should be added to the Editing Conventions, if one does not already exist. Personally, I think that blocks should all follow title capitalization, or else it would look strange and inconsistent. I also think that inline scratchblocks are fine as well. Thoughts?
Groko13 (talk | contribs) 20:18, 3 August 2020 (UTC)
- Changing all names to truth names is a hard job as Ken said before. Yes, the capitalizations might looks like terrible, but also I think manually create redirects or move some articles are better than manually move all of them. For example, change "creepy" titles, but don't edit others so much. Maybe should use a Wiki extension - I'm not sure about that is possible, however.
ahmetlii Talk Contributions Directory 20:46, 3 August 2020 (UTC)
- I think that we should change the articles that replace the bolded words with scratchblocks, ex. Set Video Transparency to () (block) because it looks a bit messy and unprofessional. I also think we should capitalise the name of the block the same way it has been done in the title, it keeps things neat.
Bananaandchoc1 (talk | contribs) 13:26, 15 August 2020 (UTC)
|
Misdirected Request error
Moved to Scratch Wiki:Bugs
Sometimes, when I go to the Test Wikis and back on an iPad, I sometimes get a '412 Misdirected Request' error. However, this does not happen on a desktop computer.
Jammum (💬 Talk - ✍️ Contribs - 🐱 Scratch) 17:55, 30 July 2020 (UTC)
Discussion
|
---|
- I guess it's happening because of MediaWiki version. Test Wiki is using old version when compared to English Wiki. Also, there can be another reason: Test Wiki has a backdoor for FTP transfer but it has low probability.
ahmetlii Talk Contributions Directory 16:12, 3 August 2020 (UTC)
- Also, it's '421' error, not '412'.
ahmetlii Talk Contributions Directory 20:26, 3 August 2020 (UTC)
- I have this problem too, also on an iPad. I might have gotten it on my computer before, but I don't remember.
Dominic305 Talk Contribs (1,771) Scratch Directory 11:17, 13 August 2020 (UTC)
- It happened on my Windows desktop just today. I think the Wifi disconnected when the screen turned off, maybe something similar happened to the iPads?
Jettypumpkin07 (talk | contribs) 11:32, 23 August 2020 (UTC)
|
Suggestion: Have a dedicated page for feedback on the account request system
Not done
I was browsing through some old CP archives, and one of the topics reminded me of a suggestion I thought of earlier. My suggestion may have been partly inspired by an account request I reviewed that included feedback on the account request system.
Currently, I leave users one of two messages if I accept their account request. I use this one if their request meets all the requirements already (I have preserved the external links, since this is how I post it on the Scratch website):
Now, some people inevitably miss something in S:CONTRIB. When we're reviewing account requests, and someone seems to have put in effort and has not missed too much of S:CONTRIB, we first put their request on hold. We comment on their profile and ask them further questions. If they satisfy the requirements after replying to our comment(s), we accept their request. This is all outlined in Scratch Wiki:Become a contributor/Admin Guide.
This is the comment I leave on people's profiles if I first put their request on hold and then accept it:
Some Experienced Wikians have a slight variation of this message, but we all link them to Special:Login, S:NEW, S:GUIDES, and S:FAQ (or other shortcuts that link to those pages). Now, why am I mentioning the messages that I use when accepting someone's account request? Well, because those may be changed if my suggestion gets implemented.
What is my suggestion? Well, in short, I think we should have a dedicated page for feedback on our account request system. As a wiki, we should always be looking to improve; and this is a way to do it. People can already give feedback on the account request system (or anything else wiki-related, for that matter) in the CP, but feedback is not actively facilitated. This is why I think we should have a dedicated page.
This page would be specifically designed to be easy-to-use for people who are new to the Scratch Wiki and wikis in general. Users would be able to click a link or button, and the "new section" interface would be filled with a form where they could insert their feedback. The user's signature would be automatically inserted at the end. It would be similar to the link users click to nominate themselves for an EW election.
However, I don't think that the page should just exist — I think we should actively make New Wikians aware of it. When someone gets accepted, the account request system is fresh in their mind, and they may have some ideas on how to improve it. However, they may not know where they can put that feedback, or may be too nervous to make us aware of it. My first thought was to add a link to the page to the messages used when accepting users. If we feel that that already has too much information, we could also add it to S:WELCOME.
Of course, all of this is subject to change. What do y'all think of this idea? Is it a good one? A bad one? Do you have any ideas to make it better? Everyone's feedback is equally valued. 
bigpuppy talk ▪︎ contribs 02:16, 3 August 2020 (UTC)
Discussion
|
---|
- Project talk:Become a contributor
-unsigned comment by Naleksuh (talk | contribs)
- Thanks for your comment. However, did you read my whole suggestion? That page does not include everything I suggested. Plus, my suggestion would not encompass feedback on just S:CONTRIB, but also on the Special:RequestAccount interface, how we manage account requests, etc.
Thank you for reminding me of that page, though!
bigpuppy talk ▪︎ contribs 02:21, 3 August 2020 (UTC)
- I understood what you were saying. However it may have been my fault for including only a link instead of an additional explanation. My point here was that I do not believe a whole new page is necessary, but that the existing page should suffice, and that discussions there can be extended to this new ground (since Special pages do not have talk pages). b
-unsigned comment by Naleksuh (talk | contribs)
- Alright. So, assuming that we would not create a whole new page, but rather extend that page to be about feedback on the account request system in general, what do you think of my other suggestions (e.g. actively facilitating feedback, making the page easy to use even for people new to wikis, etc.)? Thank you for your quick response, by the way — it is greatly appreciated.

bigpuppy talk ▪︎ contribs 02:28, 3 August 2020 (UTC)
- I think these are good suggestions! it's a good idea to actively facilitate feedback from New Wikians, and putting a link in the acceptance or welcome message will hopefully make them aware of the page. We could probably add the button which you suggested that automatically creates a form to the top of the S:CONTRIB talk page, and/or have the link do it automatically. I think we should also create a shortcut for the talk page if possible, if this suggestion gets implemented.
Groko13 (talk | contribs) 22:03, 7 August 2020 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘Great! I've created a draft of what the feedback page could look like here. (As we've discussed, the feedback page might be the S:CONTRIB talk page.) I also think it might be a good idea to create a Scratch Wiki Project for this. The users assigned to the project would be in charge of creating the page and maintaining it. The job of maintaining it might include:
- Observing how users use the page, and finding ways to improve the user experience
- Answering users' questions about how to provide feedback
- Archiving old feedback sections
If you would like to participate, feel free to add your name here! You don't have to process account requests to be a part of this Scratch Wiki Project!
Feel free to make edits to the draft of the feedback page as you see fit.
bigpuppy talk ▪︎ contribs 05:38, 9 August 2020 (UTC)
- So, this is expected to post to Project_talk:Become_a_contributor? If so, I see few objections to this, although I would have preferred a single section myself. It might also help to say what you are planning to do with the responses.
Naleksuh (talk | contribs) 05:52, 9 August 2020 (UTC)
- Having it as the talk page of S:CONTRIB is a possibility. It all depends on what we want to do. Currently, I'm keeping it in my userspace since it's just a draft.
- For the second part of your post, could you clarify what you mean? We will find trends in the responses, then propose changes to the account request system if those trends are major enough. Thanks! (Would you like to join the SWP?)

bigpuppy talk ▪︎ contribs 05:58, 9 August 2020 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
I'm not sure I see the point of this. I've never heard of anyone having feedback on the account request process, especially not immediately after being accepted. All the changes to the account request system have come from proposals by EWs, as far as I'm aware.
kenny2scratch Talk Contribs Directory 10:52, 9 August 2020 (UTC)
- Right — that's why we should have a dedicated page for it.
As I said in my original post:
- "When someone gets accepted, the account request system is fresh in their mind, and they may have some ideas on how to improve it. However, they may not know where they can put that feedback, or may be too nervous to make us aware of it."
bigpuppy talk ▪︎ contribs 15:53, 9 August 2020 (UTC)
- Furthermore, they may not think their thoughts are important enough to point out. Or, they might not think they have feedback, but when we facilitate their feedback, they think of feedback. New users have a unique point of view when it comes to the issue of account requests; thus, I think we should actively facilitate their feedback on the account request system.

bigpuppy talk ▪︎ contribs 16:11, 9 August 2020 (UTC)
- In that case, we should direct them to the Wiki CP forum topic, so that both accepted and rejected users have equal representation, instead of silencing those who were rejected. The Wiki isn't a good place for feedback about account requests if not everyone who might have feedback has an account.
kenny2scratch Talk Contribs Directory 20:56, 9 August 2020 (UTC)
- I understand what you're saying, and I think I may have considered that issue before too. I do agree with you at first thought. However, after I think it through, here's my view: Time has shown that many people are able to get accepted with our current account request system. The account request system is designed so that anyone who reads all of S:CONTRIB can get through, if they put in the work. I feel that if we actively facilitate rejected users' feedback, we might get feedback from a lot of people who haven't actually read all of S:CONTRIB. If we get feedback from a lot of people who haven't read S:CONTRIB, then we're getting feedback from people who don't really know everything about how the account request process works. This is not to say that we should shield our eyes from rejected users' feedback, but I'm not sure whether we should actively facilitate it.
- I disagree that actively facilitating accepted users' feedback and not doing so for rejected users is "silencing" rejected users, though. If a rejected has a valid concern about the account request process, I would assume that they would let us know of it. They might not know about the CP forum topic, but they could reply to the account processor and tell them their thoughts.
- Please keep in mind that I'm not trying to discriminate against rejected users; the above thoughts are just things to think about.

bigpuppy talk ▪︎ contribs 21:46, 9 August 2020 (UTC)
- You took me way too seriously - I was just pointing out that rejected users are shut out by your proposal, not saying that you have a vendetta against them.
- I still don't think that the Wiki is the place for it, though. The account request process concerns the people as Scratch users, not Wiki users, so the feedback should be done on Scratch. But if you think rejected users have a less informed opinion, we can simply invite accepted users to give feedback on the CP topic and omit that invitation for rejected users.
kenny2scratch Talk Contribs Directory 21:56, 9 August 2020 (UTC)
- I think many rejected users have a less informed opinion (those who have not read S:CONTRIB). If someone has actually read all of S:CONTRIB and is still getting rejected, I think there should be a place for them to give feedback. However, we shouldn't necessarily put it in the rejection message because many rejected users have not read S:CONTRIB.
- I disagree with your logic on why it should be done on Scratch, though. The account request system is a product of the Wiki, so it should be done on the Wiki. It's also a good chance for them to have a "first experience" with how things like talk pages work.
- However, this is just my opinion. Again, I am not trying to be disrespectful to rejected users.

bigpuppy talk ▪︎ contribs 17:01, 10 August 2020 (UTC)
|
How to Connect to the Physical World is really outdated.
GrahamSH (talk | contribs) 19:26, 19 August 2020 (UTC)
Discussion
|
---|
- Please use internal links for links to other Scratch Wiki pages. As for this, maybe you could try to update part of it yourself?
Jammum (💬 Talk - ✍️ Contribs - 🐱 Scratch) 06:36, 20 August 2020 (UTC)
- @Jammum Thank you for pointing out the usage of an external link. I've corrected the formatting so that @GrahamSH can see how it is done correctly (@Jammum please wait for an EW/administrator to correct if you see this elseware). @GrahamSH I would ask that you be more specific in the types of changes that we should collaborate in order to accomplish. Thanks
Makethebrainhappy (talk | contribs) 17:46, 30 August 2020 (UTC)
|
Tip of the Day
Not done
Description | Status | Owner | Started | Links |
Create a panel that will show one tip for each day of the year. | Not done | - bigpuppy
- ahmetlii
- Illusion705
- Groko13
- Filmlover12
- Jammum
- garnetluvcookie
- jakel181
- Dominic305
- 12944qwerty
| 8/22/2020 | Project results |
Project page |
Project discussion |
I created a Tip of the Day system that will show one tip for each day of the year. It's inspired by Wikipedia's tip of the day. However, we need tips! If you would like to help, feel free to add your name to the project page. 
bigpuppy talk ▪︎ contribs 02:29, 23 August 2020 (UTC)
Discussion
|
---|
- Ooh! Sounds interesting :) Should I just add my name next to yours or somewhere else?
Illusion705 talk | contribs 02:33, 23 August 2020 (UTC)
- How do we add tips? Is every tip going to have it's own subpage? If so, it would be cool if the "Add one?" link for adding a tip linked to the subpage for the current day's tip.
Groko13 (talk | contribs) 04:31, 23 August 2020 (UTC)
- Is there enough to know about the Wiki for 365 tips? (Regardless, I've fixed your {{SWP}} usage, Bigpuppy - the
page parameter is meant for the /project page itself.)
kenny2scratch Talk Contribs Directory 07:56, 23 August 2020 (UTC)
- Based on what Ken said above, maybe there could be tips for each day of the month (eg. on the first of January, February and the rest of the months, one tip shows, and so on for the rest of the days in a month)?
Jammum (💬 Talk - ✍️ Contribs - 🐱 Scratch) 09:00, 23 August 2020 (UTC)
- I agree with what Jammum said. I think the Scratch Wiki doesn't need 365 tips for each day because this wiki isn't a Wikipedia.
ahmetlii Talk Contributions Directory 10:40, 23 August 2020 (UTC)
- Wow, I didn't expect so many people to reply in such a short amount of time.
- @Illusion705 — You can add your name to User:Bigpuppy/Tip of the Day/project similar to how ahmetlii's name is.

- @Groko13 — Currently, it's just one page with all of them. While that would be a lot of subpages, I think that might be cool too.
- @Kenny2scratch — I mean, there might be, but there might not be. (Thanks for fixing that.)
- @Jammum — I think that's a good idea. I'll do that today.
- @ahmetlii — As per above.
- However, after I made this, I had another idea. We could run a Scratch tip of the day as well. It would show tips related to Scratch, its editor, and its website. Unlike the wiki, I think there is room for one tip for each day of the year. We could have this be part of the same Scratch Wiki Project. What do you think?

bigpuppy talk ▪︎ contribs 17:03, 23 August 2020 (UTC)
- I think that's a good idea. Would that be separate from the Wiki tip of the month, but in the same SWP? Also, I think that if there are enough Wiki tips, we could expand it to a tip every week, but that depends on how many tips we can come up with.
Groko13 (talk | contribs) 18:11, 23 August 2020 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘I think they would be part of the same SWP, since they are both Tips of the Day. I've created two separate pages: User:Bigpuppy/Tip of the Day/Scratch Wiki and User:Bigpuppy/Tip of the Day/Scratch. 
bigpuppy talk ▪︎ contribs 20:51, 23 August 2020 (UTC)
- Do you think we'll be able to find 366 tips for Scratch? While I understand the concern that we won't be able to, I also don't want us to be limited by a lower number. We can take all the time we need to write them.

bigpuppy talk ▪︎ contribs 21:40, 23 August 2020 (UTC)
I'm currently making tips and already have about 75. Will share when done
Acebsa (talk | contribs) 19:05, 24 August 2020 (UTC)
- Ok here is the huge list of quite a few tips I made/ found online:
You can use the language extension to make your projects multilingual.
To become a SDS curator you need to help around the studio.
There are 2 types of paint editors bitmap and vector
Use the Scratch Wiki to find helpful info. About many scratch topics.
Use turbo mode to make projects run faster.
You can use cloud variables to store data on Scratch Servers
You can use starter projects to help get started on Scratch!
You can join the welcoming committee to welcome new scratchers by making a project on what scratch is about.
Use the discussion forums to give suggestions on new Scratch features.
Use the report button to let the ST know about inappropriate projects or comments.
To delete multiple sprites, Shift+ click with the Scissors tool (it won't revert to the arrow).
Find a sprite: To show a sprite that's off the screen or hidden, Shift+click on its thumbnail in the sprite list (bottom right-corner of screen) - this will bring the sprite to the middle and show it.
To turn a costume into a separate sprite, right-click (Mac Ctrl+click) and select "turn into a sprite".
Drag the blue line on sprite thumbnail (in the middle of the screen) to rotate the sprite.
To rotate a sprite from the stage, shift+click on the sprite.
Shortcut to get a sprite to "point in direction 90": double-click on sprite thumbnail in the top middle of the screen.
To delete multiple sprites, Shift+click with the Scissors (it won't revert to the arrow)
To make multiple copies of a sprite, Shift+click with the Copy tool (it won't revert to the arrow)
Drag to reorder thumbnails in sprite list (bottom right corner of screen)
Drag to reorder costumes in the Costume tab area
To make a sprite that looks like part of the background, Right-click (Mac Ctrl+click) the stage to grab a portion of the image on the stage.
BLOCKS AND SCRIPTS
To copy a stack of blocks from one sprite to another, drag the stack to the thumbnail of the other sprite (at the bottom right corner of the screen).
To clean up the script area, right-click (Mac Ctrl+click) in Scripts area.
Get help for any block: right-click (Mac Ctrl+click) on the block
You can fit some blocks within other blocks. For example, you can put any Number or Sensing blocks with curved edges inside a "switch to costume" block or any block that has a white number or text area.
Want to get the current x-y of a sprite? Click on the Motion category to update the x-y numbers in the glide and go-to blocks in the palette.
PAINT EDITOR
To crop an image, outline it with the Selection tool, then Shift+delete (or Shift+backspace)
To rotate part of a costume, use the selection tool, then click the left or right Rotate button (curved arrows).
To rotate more precisely: Shift+click on the left or right Rotate button. It will let you enter a # of degrees to rotate
Grow or shrink more precisely: Shift+click on the Grow or Shrink button (arrows pointing out or in). It will let you enter a % size for a costume
To stamp multiple times, press Shift while using the Stamp tool.
Press Shift with the Rectangle tool to make a square.
Press Shift with the Oval tool to make a circle.
Press Shift with Line tool to make a straight horizontal or vertical line.
Press Shift key when clicking on a color square to change the other color.
To pick up a color from outside the paint editor, select the Eyedropper tool, click in the Paint editor, then drag while holding down the mouse key.
REPORTERS & VARIABLES
Click a monitor to toggle between options (hide monitor name, show slider)
Check boxes to show monitors on stage
KEYBOARD SHORTCUTS (some of these are repeats with above)
To delete multiple sprites, Shift+ click with the Scissors tool (it won't revert to the arrow).
Check boxes to show monitors on stage
To make multiple copies of a sprite, Shift+click with Copy tool (it won't revert to the arrow).
Ctrl+S to save your project.
OTHER
You can drag multiple images at once into Scratch. They will become costumes within a sprite.
You can drag in an animated gif.
You can drag in images from a web browser, Word, and some other programs (on Windows).
You can drag in a Scratch project from a file folder.
Right click a block for help.
Visit the Scratch wiki for more help.
There's a whole community of Scratchers that have come across a multitude of issues and would also love to help.
To join the community make an account!
Hope this helps!
Acebsa (talk | contribs) 20:33, 25 August 2020 (UTC)
- Really awesome project! I didn't realize that we were planning this kind of thing. Would you like me to post the tip of the day on our twitter account @ScratchWiki?
Makethebrainhappy (talk | contribs) 17:43, 30 August 2020 (UTC)
|
Would it possible to prevent users from using external links to wiki pages in the AbuseFilter?
Question is in title. If this were to be implemented (if it even is possible), would it apply to all non-userspace or just mainspace?
Jammum (💬 Talk - ✍️ Contribs - 🐱 Scratch) 10:50, 25 August 2020 (UTC)
Discussion
|
---|
- It's possible but I would never do this because sometimes there's a legitimate use for external links. Possibly an AbuseFilter warning, rather than disallow?
kenny2scratch Talk Contribs Directory 09:09, 28 August 2020 (UTC)
- I am asking about disallowing external links to other Scratch Wiki pages, not all external links.
Jammum (💬 Talk - ✍️ Contribs - 🐱 Scratch) 09:46, 28 August 2020 (UTC)
- There is sometimes a legitimate use for external links to the Scratch Wiki, e.g.: [3]
- Unless you're just talking about content pages. Still, though, there are probably some special cases where disallowing it would be inconvenient. A warning might be good, though.

bigpuppy talk ▪︎ contribs 17:43, 28 August 2020 (UTC)
- The fullurl template can be used for some of those links that cannot be linked normally, so does that solve the problem?
Jammum (💬 Talk - ✍️ Contribs - 🐱 Scratch) 07:38, 29 August 2020 (UTC)
- (Reviving this) I think if a user uses an external link to Scratch Wiki pages, the proper way to do a link to another Wiki page could be shown. The edit could either be warned or prevented.
Jammum (💬 Talk - ✍️ Contribs - 🐱 Scratch) 13:21, 26 September 2020 (UTC)
|
Allowing borders in custom sigs
I think we should allow borders in custom signatures. S:CSIG states that there shouldn't be borders in custom sigs, but so many people already have it in their signatures (kenny2scratch, 12944qwerty, EIephant_Lover, Dominic305, ahmetlii, ContourLines, ajsya, etc.) As long as the border isn't needlessly large or flashy, I believe it's fine.
VFDan Talk Contribs On Scratch 03:14, 28 August 2020 (UTC)
RfC about the usage of fixed with in ScratchWikiSkin2
Hello all. As you may have noticed, ScratchWikiSkin2 seems to used a fixed width (similar to Fandom's Oasis skin), as a holdover from previous skins designed to look similar to scratch.mit.edu -- however, I and several other users have noticed an increasing number of problems using fixed width. Fixed widths generally leave a large amount of the screen entirely unused, and show a small amount of the page content. It also introduces design problems that rely on fixed width and break for some users. The current, fixed width style, looks a bit like this. I am proposing to use free-styled width based on the screen resolution (a mockup something like [ https://i.imgur.com/UEd14yX.png this], ignore the blue line, that is accidental and will not be shown in the final version). This allows for a larger content space, as well as making the view more consistent across skins. Please let me know if you support or oppose this proposal.
Naleksuh (talk | contribs) 00:44, 1 September 2020 (UTC)
Discussion
|
---|
- Addendum: I would also appreciate if all could specify what skin they use when commenting? (The information is helpful, most are likely either using ScratchWikiSkin2 or Vector, but others like me primarily use Monobook).
Naleksuh (talk | contribs) 01:12, 1 September 2020 (UTC)
- I support. Fixed width looks terrible. (Reply to the addendum: I use SWS2)
VFDan Talk Contribs On Scratch 01:08, 1 September 2020 (UTC)
- (SWS2 user) Consistency across skins is completely irrelevant - consistency with the Scratch website is more important. We use fixed width to emulate the mainsite, which does the same. If you want free width, you can make a user CSS file for it.
kenny2scratch Talk Contribs Directory 09:50, 5 September 2020 (UTC)
- I personally am of the belief that consistency with the Scratch website is "completely irrelevant" -- this is a third party site with different needs and goals. This is where a lot of the design has been poured into as well, such as by changing the header to a different color. There does indeed appear to be support for increasing the width apart from Kenny2scratch's comment. However, custom CSS files are not relevant here as what is being discussed is not personal views (I use Monobook) but what would actually improve the skin, primarily to those logged out and browsing the wiki.
Naleksuh (talk | contribs) 17:50, 5 September 2020 (UTC)
- I agree with the above statement. I have an
ebic gamer HD monitor, and SWS2 is tiny on my monitor. There are at least 500 pixels of free space. It almost looks like it was designed for a tablet (it fits perfectly on iPadOS). This is the reason why I use Vector because it takes up almost all of my monitor space. You technically could make a CSS script for it, but the majority of users here (not everyone) don't know any other programming languages and/or markup languages than Scratch.
garnetluvcookie (talk | contribs) 15:51, 9 September 2020 (UTC)
- If you like Vector, use Vector. If you like SWS2 enough to keep using it but also want non-fixed width, then use user CSS. For those not logged in, fixed width is what they get, because that's what they'll be used to from the Scratch website. I don't consider fill width an improvement, only a matter of preference. Find me examples of people (who have no relation to you) actually asking for fill width SWS on, say, the forums, and then it'll be more worth considering.
kenny2scratch Talk Contribs Directory 15:45, 12 September 2020 (UTC)
- I support. While garnetluvcookie said it looks like it's designed for a tablet, personally I prefer setting zoom to 75% or 85% on most pages. However setting the zoom on the Wiki causes content to get squished and lots of tables (including on File: pages) to overflow into the empty space. And on my 1080p display, it looks like a site designed for computers from 2009.
Dominic305 Talk Contribs (1,771) Scratch Directory 17:31, 22 September 2020 (UTC)
|
An idea
Hi everyone,
I had an idea recently to make a way for non-wiki editors to suggest changes if they don't want to go through the hassle of making a wiki account. Maybe a google form or something that editors can look at and, if needed, make the change.
Acebsa (talk | contribs) 04:12, 2 September 2020 (UTC)
I am just reviving the discussion mentioned in the title above because it was archived and it did not seem to be completed. Also, on the latest Wiki Wednesday topic, no notice in the first post telling Scratchers not to spam in the topic was put in.
In the discussion linked above, I mentioned some examples of what the notice would mention as being spam. I also think posts only saying 'Hi', 'Hello' or something similar could also be mentioned as being spam.
Jammum (💬 Talk - ✍️ Contribs - 🐱 Scratch) 15:37, 5 September 2020 (UTC)
Discussion
|
---|
- Isn't it just common sense not to spam? It's already against the CGs, so I don't see a use for it or it's because I stalk the Announcements forum, get a first-page post, and move on. It could be useful to the 5 year-olds here that need a notice saying "Don't spam, it's sUpEr AnNoYiNg!11!!1"
garnetluvcookie (talk | contribs) 15:42, 9 September 2020 (UTC)
|
RfC about User:Gdpr000001, User talk:Gdpr000001 and S:B redirects
As explained in the title, these are discussed on their related talk pages and User talk:Ahmetlii, but I'd like to an RfC for solving the question.
ahmetlii Talk Contributions Directory 06:27, 10 September 2020 (UTC)
Suggestion: Resolved and Unresolved Templates
Not done
There are many discussions on talk pages on the wiki that get abandoned until someone discovers them again. Wouldn't it be helpful if we had a list of all the pages with unresolved discussions that have yet to be finished? Here are some advantages to a list like this:
- In many cases, discussions won't get abandoned without being documented as unresolved discussions somewhere.
- Users who want discussions to contribute to can just look at the list for some unresolved discussions.
- It would improve the wiki's organization.
I think one way we could implement a system like this would be with two templates: {{unresolved}} and {{resolved}}.
The {{unresolved}} template would mark the discussion with "unresolved." It would also add the page to the hidden category Category:Pages With Unresolved Discussions, and provide a link to the category. If the page was in the "User talk" namespace, it would not be added to the category. This is so that if users want to use the templates on their own talk pages, they can, but users looking for discussions to participate in won't have to dig through user talk pages. There would also be a cat=no
option to manually prevent the page from being added to the category. I've created a draft of this template at User:Bigpuppy/Unresolved. Note that the category part is commented out right now, so that pages don't get added to a nonexistent category. If this suggestion gets accepted, it will be un-commented.
The {{resolved}} template would mark the discussion with "resolved." It would have a date
parameter that would show when the discussion was resolved. Resolved discussions would not be added to any category (unless that is something we want). I've created a draft of this template at User:Bigpuppy/Resolved.
Here are answers to some questions you may have:
- Don't we already have the
Done and
Not done templates?
- Yes. However, those templates don't have all of the functionality that the {{resolved}} and {{unresolved}} templates would provide. If we added this functionality to the
Done and
Not done templates, all of the discussions that were not actually marked
Done but still have the template on them (e.g. if the template was used in casual conversation) would be added to the category.
- Would these templates replace the
Done and
Not done templates?
- No. Those templates would still be used in casual conversation and in tandem with the {{resolved}} and {{unresolved}} templates (e.g. "is this conversation
Done?"). The {{resolved}} and {{unresolved}} templates would be used more formally at the top of discussions.
- Would use of these templates be required?
- No. However, it would be recommended, so that the page gets added to the category of pages with unresolved discussions.
- Would anyone be allowed to add these templates to any discussion, even ones they didn't create?
- Yes. Similar to how the
Done and
Not done templates are used now, anyone would be able to mark a discussion as resolved or unresolved, even if they didn't create it.
- The drafts you created look curiously similar to the {{shortcut}} template.
- That's because I based part of their code on the {{shortcut}} template.

Kenny2scratch implemented semi-similar templates at User talk:Kenny2scratch/Permalinks. They are similar in that they are templates located in the top-right of a discussion and show whether the discussion is done or not.
So, thoughts? Do you like the idea? Do you think it could use some improvement? Do you think we shouldn't create these templates at all? Please share your thoughts below. 
bigpuppy talk ▪︎ contribs 19:44, 13 September 2020 (UTC)
Discussion
|
---|
- We already have S:CPND as a "unresolved" placeholder archive. I didn't see any usage of it unless marking "resolved" and "unresolved", and this gets another question: Will it be done or will not? (like 1 and 0, not includes 2 or 4). I don't think it's not important enough and @Kenny2scratch is using his permalinks to "never done" topics. I can support never done but not resolved-unresolved. Any opinions?
ahmetlii Talk Contributions Directory 19:57, 13 September 2020 (UTC)
- S:CPND isn't really relevant here because this wouldn't necessarily be used on the CP (but it could); the main purpose is for things like article talk pages. Could you clarify what you mean in the rest of your comment? Also, User talk:Kenny2scratch/Permalinks includes done topics; look at the statuses on the right of each discussion. However, that was just an example.

bigpuppy talk ▪︎ contribs 20:03, 13 September 2020 (UTC)
- I don't think it's necessary for article talk pages, because they don't need an archive or a job queue. It's not necessary as I think and said before.
ahmetlii Talk Contributions Directory 06:59, 14 September 2020 (UTC)
- Thank you for your opinion.

bigpuppy talk ▪︎ contribs 20:29, 14 September 2020 (UTC)
- You're welcome.
ahmetlii Talk Contributions Directory 20:30, 14 September 2020 (UTC)
- Couldn't we just add the functionality to {{done}} and {{not done}}?
12944qwerty Talk Contribs Scratch 20:01, 17 September 2020 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘Please see the answer to "Don't we already have the Done and Not done templates?" in my original post. 
bigpuppy talk ▪︎ contribs 21:41, 17 September 2020 (UTC)
- True, but you also stated that we could use
cat=no as the default cat option. That way, all you'd need to do for casual conversation is add {{not done}} on the section. But on an "official" conversation, we would add cat=yes .
- 2 questions though: Would only {{unresolved}} add to a category? And, doesn't adding to a category add the entire page?
12944qwerty Talk Contribs Scratch 15:00, 18 September 2020 (UTC)
- Oops, first question has been answered as soon as i posted lol
12944qwerty Talk Contribs Scratch 15:01, 18 September 2020 (UTC)
|
GitHub interwiki links
There seem to be a lot of GitHub links (including references) to the Scratch Wiki. Although the URL is not very long, maybe LLK github links (and maybe other github links) could have an interwiki link made for them (such as gh-llk, not 'gh' due to the presence of non-LLK github links as well).
Jammum (💬 Talk - ✍️ Contribs - 🐱 Scratch) 06:48, 14 September 2020 (UTC)
Discussion
|
---|
- I don't think so. Github is an external link, even its links host Scratch repos. They may cause confusion. Plain links are a better solution.
ahmetlii Talk Contributions Directory 06:52, 14 September 2020 (UTC)
|
Megathread: MediaWiki Version Bump
TL;DR: We're upgrading to MediaWiki Version 1.35. Date: Tuesday, September 29, 2020
Why upgrade?
Currently we're using MediaWiki 1.28, which is unsupported. This caused some problems and MW 1.28 is also incompatible with some extensions. This is why we upgrade to MediaWiki 1.35, a LTS version soon to be stable.
Timeline
Time not set, but this is a big project which can take weeks.
Checklist
Extensions and Skins:
Compatible ScratchWikiSkin2
Compatible ScratchLogin (patch applied to fix warning)
Replaced ConfirmAccount (new version built)
Compatible Report (patch needs review)
Compatible ScratchSig
Replaced EditAccount (new version built)
Compatible ScratchBlocks4
Compatible RecentChangesWebhooks
Compatible VisualEditor (but sb blocks will be only seen as string)
Bots:
Compatible InterwikiBot
Compatible TemplatesFTW
Internal errors WikiMonitor (has problems about dependencies)
Misc:
Compatible Special:BlockList patch - new version created
Compatible Common.css
Incompatible Common.js (sigwarn is problematic)
List of all extensions and skins installed on all wikis
|
---|
Status: C - Compatible, I - Incompatible
- C: Cologne Blue (en)
- C: Modern (en)
- C: MonoBook (en)
- C: ScratchWikiSkin2 (en)
- C: Vector (en)
- C: CategoryTree (en)
- C: CheckUser (en)
- I: ConfirmAccount (en)
- I: EditAccount (en)
- C: Interwiki (en)
- C: Random In Category (en)
- C: Report (en)
- C: ScratchLogin (en)
- C: CharInsert (en)
- C: Cite (en)
- C: CodeMirror (en)
- C: InputBox (en)
- C: ParserFunctions (en)
- C: RandomSelection (en)
- C: mw-ScratchBlocks4 (en)
- C: SyntaxHighlight (en)
- C: NativeSvgHandler (en)
- C: AbuseFilter (en)
- C: RecentChangesWebhooks (en)
- C: WikiEditor (en)
- C: DismissableSiteNotice (en)
- C: EventLogging (en)
- C: Google Analytics Integration (en)
- C: GuidedTour (en)
- C: DynamicPageList3 (de)
- C: EmbedScratch (de)
- C: EmbedPhosphorus (de)
- C: EmbedVideo (de)
- C: Labeled Section Transclusion (de)
- C: Lockdown (de)
- C: Admin Links (ja)
- I: Contribution Scores (ja)
- C: MassMessage (ja)
- C: Newest Pages (ja)
- I: ImagePagePrintLink (ja)
- C: ImageMap (ja)
- C: OpenGraphMeta (ja)
- C: YouTube (ja)
- C: RelatedArticles (ja)
- C: AutoSitemap (ja)
- C: BetaFeatures (ja)
- C: Description2 (ja)
- C: Disambiguator (ja)
- C: GuguruSearch (ja)
- C: InterwikiSorting (ja)
- C: RevisionSlider (ja)
- I: SearchStats (ja)
- C: TextExtracts (ja)
- C: Loops (fr)
- C: WikiSEO (fr)
- I: HeadScript (fr)
- C: HitCounters (test)
|
Discussion
This is gonna be big.
Apple502j Talk/Activities 2,229edit 08:24, 16 September 2020 (UTC)
Discussion
|
---|
- Question: Is Vector going to be compatible with it? I sometimes use SWS2 but I mostly use Vector on my laptop.
garnetluvcookie (talk | contribs) 13:43, 16 September 2020 (UTC)
- @garnetluvcookie: Definitely because MediaWiki uses Vector as default.
ahmetlii Talk Contributions Directory 13:45, 16 September 2020 (UTC)
- Thanks!
garnetluvcookie (talk | contribs) 13:55, 16 September 2020 (UTC)
- While we are doing this, can we add the VisualEditor? I have used it at snapwiki.miraheze.org, and it works great! I'm so excited for this update!
GrahamSH (talk | contribs) 22:27, 16 September 2020 (UTC)
- We are planning on adding the Visual Editor, however a bit of adaptation is necessary.
VFDan Talk Contribs On Scratch 01:03, 17 September 2020 (UTC)
- Why is the VisualEditor incompatible with ScratchWikiSkin2? As far as I know, (and I've been exploring this) the skin has all of the necessary hooks. Has anyone tried it?
GrahamSH (talk | contribs) 16:21, 17 September 2020 (UTC)
- @GrahamSH: I tried and tested. I know it has all necessary hooks, but also it cannot simulate the editing visually(because our skin is restrictive). We (as all developers in the Wikis) are looking for compatibility.
ahmetlii Talk Contributions Directory 16:25, 17 September 2020 (UTC)
- Update: VisualEditor is working currently with a few unimportant things like sb is not seen as block.
ahmetlii Talk Contributions Directory 18:14, 17 September 2020 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘(Remember to outdent at 6) What changes are there between 1.28 and 1.35? I know there's visual editor but I'm not sure what else.
Dominic305 Talk Contribs (1,771) Scratch Directory 00:26, 18 September 2020 (UTC)
- If Scratchblocks are to be added to the VisualEditor here, how will they be inputted?
Jammum (💬 Talk - ✍️ Contribs - 🐱 Scratch) 07:02, 18 September 2020 (UTC)
- @Jammum: We're working on it for editing blocks visually. Probably we will use text, but also the blocks will be seen instantly on VisualEditor when someone did an edit on the Scratchblocks text.
- @Dominic305: There are a lot changes, I suggest you to read all changelogs between 1.28 and 1.35.
ahmetlii Talk Contributions Directory 07:20, 18 September 2020 (UTC)
- Will the extension Popups be enabled instead of the current thing in the common.js? Popups, (the extension) is much better.
GrahamSH (talk | contribs) 12:13, 18 September 2020 (UTC)
- Also, since Special:BlockList patch is broken, you could try using https://www.mediawiki.org/wiki/Extension:Lockdown
GrahamSH (talk | contribs) 14:01, 18 September 2020 (UTC)
- Thanks for the helping, but the developers is thinking that manually editing MediaWiki is better than use an extension for it. Anyway, thanks again!

ahmetlii Talk Contributions Directory 14:24, 18 September 2020 (UTC)
- I am not sure where Ahmetlii got the idea above-- nobody has even suggested that, in addition to it being a bad idea for a number of technical reasons that I am sure ISW understands. There have not been any suggestions for a way of implementing Special:BlockList privacy, but I will see about some solutions.
Naleksuh (talk | contribs) 18:19, 18 September 2020 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
For VisualEditor, couldn't you do something similar to the way it's done in scratch forums?
I wish I could help but I don't know a single thing about PHP
12944qwerty Talk Contribs Scratch 18:26, 18 September 2020 (UTC)
- I don't think so. BBS systems and wikis are two different things. btw, I'm not also good at PHP (my specialty is Python on backend)
ahmetlii Talk Contributions Directory 18:42, 18 September 2020 (UTC)
- They are, but I wasn't saying that you use the systems. I was just saying to use the concepts of how the scratchblocks are entered into the visual space.
- SAME, but I actually don't know a single thing of PHP
12944qwerty Talk Contribs Scratch 19:03, 18 September 2020 (UTC)
- Actually, it could look for typeof="mw:Extension/scratchblocks"
GrahamSH (talk | contribs) 19:48, 18 September 2020 (UTC)
What do you mean by the tags are found? We use <scratchblocks> tags to make scratchblocks on the wiki...
In the visualeditor, we could just make a button, that will make something similar to the templates popup in the visualeditor. Then edit and it makes the block!
- Edit conflict lol, but I wouldn't recommend deleting your entire post and replacing it with something else. It doesn't tell others what your previous thoughts were, (they could support you, or not) And is that
typof= supposed to link anywhere?
12944qwerty Talk Contribs Scratch 20:01, 18 September 2020 (UTC)
- In the visualeditor, elements with scratchblock have
typeof="mw:Extension/scratchblocks" in their html. But, there is no text (shown) that says <scratchblocks>
GrahamSH (talk | contribs) 01:05, 19 September 2020 (UTC)
- That's because <scratchblocks> get's replaced with
<pre class="block"> or <code class="block"> to make scratch blocks...
- I'm sorry but I don't understand your point.
12944qwerty Talk Contribs Scratch 18:36, 19 September 2020 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘
I looked at the MediaWiki website and it said that the EditAccount extension is archived, which might be why it does not work on the latest MediaWiki version. Is it going to be forked or replaced?
Jammum (💬 Talk - ✍️ Contribs - 🐱 Scratch) 10:10, 20 September 2020 (UTC)
- We're working on it. The only thing is we will not use EditUser (because it's so restrictive). Please check the GitHub repos of the International Scratch Wiki for public changelogs of the Scratch Wiki systems.
ahmetlii Talk Contributions Directory 11:17, 20 September 2020 (UTC)
- apple502j has created an alternative to EditAccount that can be used on MediaWiki 1.35: PassEdit. The original reason we needed EditAccount was for the case when users forgot their passwords and emails were set incorrectly (or they entered their email incorrectly when requesting an account and couldn't get their password sent to them when their account was created). However, now that we have ScratchLogin, that is no longer an issue, since users can reset their password by using their Scratch account. We have tested the extension and it does work, but we are not sure if we will enable it or not.
jvvg (talk | contribs) 23:09, 27 September 2020 (UTC)
|
Increase the file size thingy (read this to get it)
Not done
i can't explain anything so here goes...
I've seen many people getting the "compress every file you upload if it's not under 2 KB" message. Why? These users uploaded files that are like 6 KB. 6 KB!!! That's incredibly small, at least for file sizes. I believe that the minimum file size for compression should be raised to 20 KB because that's a size that's small, but large enough that it's too big. Thoughts?
♥ garnetluvcookie ♥ | ♥ talk ♥ | ♥ contribs ♥ 00:56, 20 September 2020 (UTC)
Discussion
|
---|
- I think the title of this topic should actually be "Increase the file size thingy (read this to get it)" (or am I misunderstanding what you're saying?)

- Also, could you please clarify which message you're talking about?
- Special:Upload states "Is the image's filesize over 300KB? If it is, please compress it. TinyPNG is recommended for PNGs and JPEGs (contrary to the name, it does support JPEG)."
- The abuse filter warning that appears when you upload a file that's too large also uses the 300KB number, stating "If your file is over 300KB, please compress it. TinyPNG is recommended for PNGs and JPGs."
- The message that TemplatesFTW posts on users' talk pages after it compresses their files does not state any number, but rather states that "... the image size was kinda big ...".
- None of the above messages mention that you should "compress every file you upload if it's not under 2 KB," so could you please clarify which message you are talking about? If I'm missing something obvious, please point it out. Thank you!

bigpuppy talk ▪︎ contribs 01:36, 20 September 2020 (UTC)
- Ahh, yes I meant increase, it's just pretty late where I am and I'm a bit sleepy. Also, the compress if it's over 2 KB thing was a joke to show how low the compressing thing is :P. I'll fix the post
before I fall asleep in my chair.
♥ garnetluvcookie ♥ | ♥ talk ♥ | ♥ contribs ♥ 02:08, 20 September 2020 (UTC)
- Yeah people take compression way too seriously. Maybe at 30mb losslessly you should consider compressing, but there's no reason to compress something already only 20 kb (which is incredibly small in 2020, a lot of JavaScript files are bigger). Some images have been compressed so aggressively that the text becomes difficult to read and have needed to be reverted. The file dimensions were recently increased to 1080p a couple weeks ago, but there hasn't been much comment on file size. I personally think that an increase on file size limit would be very helpful as compression has been taken way too seriously (in most cases it has almost no benefit, although there are always exceptions). In addition, admins for some reason can upload files up to 218 times larger than non-admins, which again I think is another unnecessary line.
Naleksuh (talk | contribs) 02:19, 20 September 2020 (UTC)
- Exactly. All it does is decreases file size by like 4 KB. Personally I think that compression is taken wayy too seriously here.
garnetluvcookie (talk | contribs) 02:31, 20 September 2020 (UTC)
|
Tone down the rejected messages on S:BR archives
Note: | None of this was made to offend the people who reject bot requests. Please take no offense. |
Some of the rejected summaries at S:BR rejected requests are very unwelcoming. For example, my rejected message had "User has no programming experience" which comes off extremely rude, and when I do have programming experience (if you count Scratch as a programming language... *awkward smile*). The only reason that I don't is because I'm incredibly young, not even in middle school. If I was 5 years older, I would've created a bot already. (Please don't argue this point against me, I don't want the summary bored into my head)
Also, a user may not have much experience in the language, but that doesn't mean that they are incapable of creating a bot. I know many people online (haha don't ask about IRL) that are new to the language that they chose, but they've created amazing stuff. It's enforcing the stereotype of "young children are dumb and can't do complex stuff". No matter how minor, it's still showing bad behavior as a role-model.
This doesn't mean that the admins need to rewrite every single rejected summary, they just need to be more considerate about how others will feel. extreme nostalgia and/or cringe side affects may occur in 3... 2... 1... It's like that concept that everyone was taught in early grade school, fill others buckets, don't dump them.
now my fingers hurt :P
garnetluvcookie (talk | contribs) 21:57, 20 September 2020 (UTC)
Discussion
|
---|
- As mysteriously as he arrived, NYCDOT was gone again. Hi. I checked out your BR, and it appears that Ken wrote "Proposer has no programming experience and VoxBot is the only approved typography bot." He said it like it is, you have no experience. What is he supposed to say? We aren't going to give out gold stars to people who propose that they create their own bots without any idea how to do so. Try out a some programming languages before proposing a a new Wiki Bot, and I'm sure the next time you have a BR the admins will be more than happy to review your request. As for the bot idea itself, VoxBot is an approved bot that we know works well and does its job. If you have problems with it, I'm sure KrIsMa will listen to your suggestions.
NYCDOT [ Talk Page | Contributions | Directory ] 18:20, 21 September 2020 (UTC)
- I do have programming experience, I just only knew Scratch at the time I suggested it. Also, even though I apparently am dumb, I do know a good bit of Python.
garnetluvcookie (talk | contribs) 18:25, 21 September 2020 (UTC)
- Two things. One, no one ever said you were dumb. Not knowing how to do a certain thing doesn't make you dumb. Two, at the time of the bot request, you pretty much had no experience. While you may have some now, that doesn't change the past. If you think of a new, useful bot, you can propose one again.
NYCDOT [ Talk Page | Contributions | Directory ] 18:38, 21 September 2020 (UTC)
- Welcome back NYCDOT, I came back recently too
, also, remember about your indents :P
- Scratch is not counted as programming knowledge. Although you could use scratch knowledge to code with other languages, knowing scratch only isn't enough. Can you make a bot with scratch coding? No, you cannot. Ken writing that you have no programming experience is completely fine. You agreed you have no programming experience outside of Scratch.
- Although it may be rude for you, it is in no way meant to be rude. Ken wrote all details in his rejected message so that everyone understands why this bot got rejected and so that users don't make a bot for the same reason. There's always a reason for writing things the way it's written.
12944qwerty Talk Contribs Scratch 19:42, 21 September 2020 (UTC)
|
make templates like trout
(yes, i am aware of S:NOTWP. i am suggesting because it's funny.)
Self-explanatory. There would also be self-trout, minnow, and whale.
garnetluvcookie (talk | contribs) 14:42, 27 September 2020 (UTC)
Discussion
|
---|
- {{User:Dominic305/Templates/Trout notification}} exists, if it is something multiple people want it could be moved out of my userspace. Until then you can use it with that link. I have not heard of whale or minnow but I'm sure those could also be made if everyone wants them.
Dominic305 Talk Contribs (1,771) Scratch Directory 14:48, 27 September 2020 (UTC)
shameless plug but not many people know about it unless you plug it everywhere :/
garnetluvcookie (talk | contribs) 14:54, 27 September 2020 (UTC)
- We do not allow mainspace templates that aren't intended for use in articles or on talk pages. You may make a template like that in your userspace if you want.
jvvg (talk | contribs) 18:17, 27 September 2020 (UTC)
- Edit: Trout notification is now Trout Selector, I've added whale, and 2 different barnstars (use {{User:Dominic305/Templates/Barnstar/Selector}})
Dominic305 Talk Contribs (1,771) Scratch Directory 15:21, 1 October 2020 (UTC)
- I think this discussion can be finished. A trout template and other userspace-only templates can only be made in userspace per Jvvg's comment.
Jammum (💬 Talk - ✍️ Contribs - 🐱 Scratch) 06:53, 7 October 2020 (UTC)
|
RfC for Interface admins group
With the recent update to MediaWiki 1.35, a new group has been created: Special:ListGroupRights#interface-admin. Currently, nobody has this group-- however this is the only group that is able to edit pages like MediaWiki:Common.js. While we have policies for how to request Experienced Wikian (through annual elections) and sysop (through requests on Community portal); there is no policy as to how to request Interface admin as it is a new group to Scratch Wiki. There are several possible ideas for how users might request this group.
Below there are three proposals. Keep in mind that these are not necessarily contradictory, multiple or all of them could coexist.
Naleksuh (talk | contribs) 03:45, 30 September 2020 (UTC)
Discussion
|
---|
Support
Oppose
- I think the group is too specific for this to be useful-- I also think granting permanent access puts importance and does not allow specific tasks to be vetted as they should be.
Naleksuh (talk | contribs) 03:45, 30 September 2020 (UTC)
- Oppose, as Naleksuh stated.
TenType (talk | contribs) 04:20, 7 October 2020 (UTC)
Proposal 2: Allow interface admin to be requested temporarily (for a specific purpose) through /Admin Requests
Support
- Allows users to edit the interface as needed. Seems like the best path for requesting and allows specific tasks as well as not granting permanent access as needed.
Naleksuh (talk | contribs) 03:45, 30 September 2020 (UTC)
- As per Naleksuh.
garnetluvcookie (talk | contribs) 20:04, 2 October 2020 (UTC)
- Support, but admin will probably only allow certain pages and they can only get certain permissions.
12944qwerty Talk Contribs Scratch 22:01, 2 October 2020 (UTC)
Oppose
- "Hey can I have permissions to edit common.js? I want to [do something innocent]. - User1" "Sure, I'll grant you perms. - Admin1" "Thanks! - User1" User1 then proceeds to add a script that steals passwords. Admin1 quickly undos and bans User1, but the damage has been done. User1 can now login as User2 and User3. The exploitation possibility is too large here.
VFDan Talk Contribs On Scratch 20:55, 30 September 2020 (UTC)
- True, but this could also easily happen through permanent requests on the community portal. I see you chose not to vote on proposal 1 at all, neither support nor oppose. Is that mistake or intentional?
Naleksuh (talk | contribs) 21:00, 30 September 2020 (UTC)
- Intentional, I would've just been repeating your message.
VFDan Talk Contribs On Scratch 02:47, 1 October 2020 (UTC)
- Naleksuh, saying one of the other proposals would do the same thing isn't really an argument against VFDan's point (I'm not sure if your intention was to argue against the point, though); because of this, I am interested to know if you do have an argument against it?

bigpuppy talk ▪︎ contribs 04:23, 3 October 2020 (UTC)
- I agree with VFDan's statement, and I also think that the ambiguity in this proposal is a very big issue that needs to be addressed. Who would be able to request the permissions? Anyone? Wikians? Users who have been here for 30 days? You might argue that this could be decided afterwards if this proposal is chosen, but that doesn't really make sense to me. Who can request permissions is a very important thing to consider about this proposal before it is chosen, simply because of the sheer trust someone with this usergroup needs to receive from the community. Even if you argue that, for example, time on the wiki is not an effective measure of trustworthiness and/or experience (which is certainly a valid argument to make), there are other issues with ambiguities in this proposal. If anyone can request the permissions, how will "trustworthiness" by measured? For example, say it is a simple vote by the community. How many votes in support of granting the user the permissions will be required to actually grant the user the permissions? Even disregarding all of the ambiguities I've mentioned so far, I'm not sure really think this is a good idea under any circumstances (unless something was put in place where only bureaucrats—for example—would be able to request the permissions). The reason this discussion is happening in the first place is because the permissions granted by the
interface-admin usergroup can be used dangerously and maliciously. Instead of taking a shot in the dark and giving users who haven't been trusted with many other permissions a usergroup that can be used dangerously—even temporarily—why don't we grant the permissions to users that are already trusted by the community (for example, bureaucrats with server access)? I really don't see many pros that outweigh the cons of granting any users this permission if they find a use for it and a haphazard look at the user by the community determines that the user is "trustworthy." I want to make it very clear that this is not to say that I don't trust users who aren't EWs, admins, bureaucrats, etc. (I trust very many users who do not have these usergroups!), but rather to say that I don't really see a point in granting the usergroup (again, even temporarily) to users that haven't already been trusted with other permissions by the community when there are readily available users who are trusted with other permissions by the community. Please keep in mind I do not mean to offend anyone with this comment; I just disagree with this proposal. If you have any questions about my statements above, please feel free to ask. 
bigpuppy talk ▪︎ contribs 04:23, 3 October 2020 (UTC)
- I do not think any groups would be required to request it. However, as a guideline, I would say that anyone who was not a Project:Wikians would be unlikely to get it, as it would be difficult to level trust to someone that new. However, I think that people put too much comparison to groups and trust. I would not tie usergroups and trust together here, and would not require Experienced Wikian or administrator. I do not like the implication that anyone who does not have Experienced Wikian is clearly untrustworthy. I would say trust is not something that can be measured or defined, but is done on a user-by-user basis. The three things I think about when granting usergroups are trust, need, and experience. I think it very much works here. Trust is certainly an issue, but I think that most people on Scratch Wiki only think about trust. The other two parts, need and experience, also apply. Need is actually much more easy to do with a temporary group. As one explains what the purpose of it is for, then it is granted for that one purposes then expires once it is done. Experience is also another thing that is commonly considered. If I was a crat, I would be likely to decline the group to anyone who I thought did not have experience with JavaScript/or the type of person who uses weak passwords/no antivirus/etc or something that is likely to get their account compromised. So I think the entirety of this "how would you define who is trustworthy" is kind of a question that it isn't really possible to answer, but trustworthiness can be found for users individually.
Naleksuh (talk | contribs) 04:49, 3 October 2020 (UTC)
- "I do not think any groups would be required to request it. However, as a guideline, I would say that anyone who was not a Project:Wikians would be unlikely to get it, as it would be difficult to level trust to someone that new."
- "However, I think that people put too much comparison to groups and trust. I would not tie usergroups and trust together here, and would not require Experienced Wikian or administrator. I do not like the implication that anyone who does not have Experienced Wikian is clearly untrustworthy."
- When did I imply this? I think I made it very clear in my post that my point was not that I don't trust people who aren't Experienced Wikians, admins, bureaucrats, etc., but rather that those people are already trusted with extra permissions by the community and thus it is less of a risk to grant them the usergroup than others who are simply given a haphazard review by the community. EWs go through a whole election process, and you are suggesting that anyone would be able to easily get this usergroup if they are seen as trusted by the community. By comparison, EWs have proven that they are trustworthy by having access to permissions such as
delete , and using them responsibly. I think that you and I both know that there are very many other users in the community who could be trusted with delete , and yet we don't grant them Experienced Wikian, right? Right, because there's not a need. In this case, there is not a need for users who have not been trusted with any extra permissions by the community to be granted this usergroup when there are users readily available who are already trusted with many dangerous permissions. By the way, I am not necessarily saying that I would support EWs, admins, or even bureaucrats without server access having this usergroup; I'm just trying to use those usergroups as a starting point to explain my opinion.
- "I would say trust is not something that can be measured or defined, but is done on a user-by-user basis."
- Yes. However, some users have been trusted with more dangerous rights than other users, and those users have proven that they can use these rights responsibly. This needs to be taken into account; it can't just be ignored.
- "The three things I think about when granting usergroups are trust, need, and experience. I think it very much works here."
- Well, yes, those things are good to take into account.
- "Trust is certainly an issue, but I think that most people on Scratch Wiki only think about trust. The other two parts, need and experience, also apply. Need is actually much more easy to do with a temporary group. As one explains what the purpose of it is for, then it is granted for that one purposes then expires once it is done."
- While I definitely see your point here, I think I should refer to my comment in the "Support" section of Proposal 3 here: "If we don't trust users with server access to only make controversial/major changes after there is consensus, then I feel we have a much larger problem on our hands.
" The point is that Proposal 3 can still go hand-in-hand with consensus; users with server access—who are already extremely trusted by the community—can get consensus from the community before making a major or controversial change. If the community sees a user making major changes without first getting consensus, then perhaps the community should revoke their privileges.
- "Experience is also another thing that is commonly considered. If I was a crat, I would be likely to decline the group to anyone who I thought did not have experience with JavaScript/or the type of person who uses weak passwords/no antivirus/etc or something that is likely to get their account compromised."
- (I think you meant "not commonly considered" here? Unless I am misunderstanding you?) Anyhow, the fact is, we already have users who have this experience and are bureaucrats with server access.
- "So I think the entirety of this "how would you define who is trustworthy" is kind of a question that it isn't really possible to answer, but trustworthiness can be found for users individually."
- Going off of my previous statement, we have users who have already individually proved themselves as trustworthy over years (for example, jvvg and Ken). Therefore, if those users are willing to take the responsibility for the usergroup (I'm not saying they are or aren't, I'm just using them as an example), why would we take a proverbial "shot in the dark" with someone who the community hasn't yet determined over a long period of time is trustworthy (even if they are trustworthy)?
- I'm going to re-post this statement from my earlier comment, since I really want to emphasize it: "I want to make it very clear that this is not to say that I don't trust users who aren't EWs, admins, bureaucrats, etc. (I trust very many users who do not have these usergroups!), but rather to say that I don't really see a point in granting the usergroup (again, even temporarily) to users that haven't already been trusted with other permissions by the community when there are readily available users who are trusted with other permissions by the community."
- Again, I do not mean to offend anyone with my statements. If you have any questions, feel free to ask.

bigpuppy talk ▪︎ contribs 05:23, 3 October 2020 (UTC)
- Furthermore, why would we want to make sure a user is trustworthy and experienced as well as making sure that the changes are necessary many of the times when someone proposes changes, when we would just have to do one of those things with Proposal 4 (make sure the changes are necessary)? Just something to keep in mind.

bigpuppy talk ▪︎ contribs 05:47, 3 October 2020 (UTC)
Proposal 3: Allow interface admin to be non-controversially granted to any user with server access
Support
- This is exactly how it used to be, and anybody with server access is trusted, and they usually won't make changes without the community's approval; they should still ask for feedback, but they should have the right.
VFDan Talk Contribs On Scratch 20:55, 30 September 2020 (UTC)
- My statements in the "Oppose" section of Proposal 2 apply here. If we don't trust users with server access to only make controversial/major changes after there is consensus, then I feel we have a much larger problem on our hands.

bigpuppy talk ▪︎ contribs 04:23, 3 October 2020 (UTC)
- My point here was that the request for the group also serves as a chance to discuss the proposed edits, which is why I wanted them to request it through there. Jvvg had raised a point on Discord about that sometimes urgent changes must be made that don't have time for consensus, but I was not really satisfied with the examples given and did not think it was worth it. I could see a server user granting to themself for example to perform a change that must be done for legal reasons, or to revert vandalism to such a page. But because the request process also serves as a way to discuss the edits, I do not think they should have the group 24/7.
Naleksuh (talk | contribs) 04:49, 3 October 2020 (UTC)
- We already trust users with server access with, well, server access; so why should we not trust that they will get consensus from the community before making a major change? Consensus doesn't have to come through a usergroup request system.

bigpuppy talk ▪︎ contribs 05:32, 3 October 2020 (UTC)
- There are some times that changes need to be made with little or no notice. For example, when setting up a new extension (a recent example that comes to mind is that due to a small glitch in setting up the new account request system, some messages on the account request page did not render properly, so we had to update the messages immediately). Having to go through community approval usually takes days, which in most cases is ok, but requiring it to be able to make any change at all adds unnecessary burden when sometimes quick action is needed. Thus I think keeping the permission available to server admins while having a policy be that non-urgent changes should be community approved would be best, but making it so we do not have the technical ability to make urgent changes could actually cause problems.
jvvg (talk | contribs) 17:30, 4 October 2020 (UTC)
- This seems reasonable, however in the past granting a permission to a specific group leads to that group interpreting it as "go and do whatever you want with it". I think it does make sense for server users to grant interface admin to themselves for solely technical maintenance or time-sensitive tasks, but not for anything that requires discussion. Sounds okay.
Naleksuh (talk | contribs) 18:05, 4 October 2020 (UTC)
Oppose
- This was initially proposed because users with server access have the ability to escalate their own permissions to begin with-- but I would still prefer they request it through the traditional method as the community should still at least be given a chance to weigh in on the attempted edits.
Naleksuh (talk | contribs) 03:45, 30 September 2020 (UTC)
- Oppose. What if in the rare case that someone with server access ruins the wiki with the admin privilege? Additionally, as per Naleksuh.
garnetluvcookie (talk | contribs) 20:04, 2 October 2020 (UTC)
- Someone with server access can delete every single file on the wiki anyway...
VFDan Talk Contribs On Scratch 00:31, 3 October 2020 (UTC)
Proposal 4 (by apple): Get rid of that group, and grant the permissions to bureaucrats
This is similar to Proposal 3 except we remove the interface admin entirely. Bureaucrats are trusted enough to edit Common.js; no need for a new group. This is basically the same as 1.28 system.
We can (probably) also grant this to admins - they are trusted members chosen by bureaucrats.
Apple502j Talk/Activities 2,229edit 10:48, 2 October 2020 (UTC)
Support
Support, no need to have a new usergroup. What we had in 1.28 worked just fine.
Jakel181 (talk | contribs) 12:08, 2 October 2020 (UTC)
Oppose
- Oppose. It did not "work just fine", admin is too low a barrier to be editing JavaScript pages and the group was added for a reason. In addition, removing the group seems like another attempt to turn Scratch Wiki into a hierarchy which I will certainly oppose. The group was created for a reason, security reasons, and removing it would be a net negative for the same reason there is consensus to not remove CheckUser and Suppressor groups. If you think that all users with server access should be able to edit the interface, I'd say support proposal 3. But not remove the group.
Naleksuh (talk | contribs) 19:30, 2 October 2020 (UTC)
As per Naleksuh.
garnetluvcookie (talk | contribs) 20:04, 2 October 2020 (UTC)
- Same as the above ^^
TenType (talk | contribs) 04:20, 7 October 2020 (UTC)
- From Naleksuh's original post: "While we have policies for how to request Experienced Wikian (through annual elections) and sysop (through requests on Community portal); ..." — I am surprised no one has pointed out that this is not how we choose Experienced Wikians and admins. EW elections are not annual; the current EWs and admins start one when they feel a new one is needed. Admins are not always elected through the Community Portal; for example, makethebrainhappy was appointed (not elected) during an EW election. I think the reason my case when being granted admin (for instance) was different was because there was no EW election happening at the time. I just wanted to clarify this, since when a controversial discussion is happening, we should at least make sure that objective statements are correct.

bigpuppy talk ▪︎ contribs 04:23, 3 October 2020 (UTC)
|