Scratch is open-source (or at least most of it is, although there are some closed-source repositories like scratchr2), but open-source code generally has a transparent development process, which Scratch does not.

Just today, I had a forum topic closed for speculation (https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/topic/518656/ ), but the only reason for speculation was the lack of transparency.

As I mentioned in that topic, a major change is being made in Scratch, and I wish for the Scratch Team and us in the Scratch community to be able to discuss this before it is implemented so that the best decision is made.

However, we don't even know the official reasons for this change yet, and have been told that we won't know until it is implemented, which is not transparent at all, and does not give us a say in the matters that impact us as a community.

I understand there are some things the Scratch Team must do without our “permission” to keep the community safe, but things like a reply limit will likely make the community less safe in my opinion and the opinions of many others, so I hoped we could discuss this more in a transparent process, yet we have been denied that so far.

For this suggestion, I ask that the Scratch Team discuss upcoming changes and their reasonings beforehand so that we can provide feedback where needed. Also, another place where the process is less transparent is where you will essentially be yelled at if you submit a pull request for any issue that is not labelled “help wanted”, which also goes against all open-source philosophy.

After all, we are a community of programmers in one way or another, as this is a programming website, so we might have some feedback on the programming of this website that might be beneficial to Scratch as a platform and as a community.

Also, I believe a transparent development process will also ease on-going tensions between the Scratch Team and us Scratchers.

Thank you and I hope you consider this, and hopefully start this new transparent process with this upcoming change!

Supporting this.
If this is true:

AmazingMech2418 wrote:

[View post]

Also, another place where the process is less transparent is where you will essentially be yelled at if you submit a pull request for any issue that is not labelled “help wanted”, which also goes against all open-source philosophy.

Then why does Scratch have GitHub in first place? ScratchCat has said on the “prequel” of this topic:

ScratchCat wrote:

[View post]

We welcome your feedback in the future and look forward to sharing more with you.

Well, okay – then why completely ignore everything the community says? I don't say that a reply limit is a bad idea – oh wait, I do! That's because I don't know why. We only get to know reasoning of features after they've been released, while we get to know they exist beforehand, as this is open source, after all. Does this make sense?
There are only two possibilities that make sense.
» Stick with the current way of things, but then make Scratch closed source. Open source just doesn't work like that.
» This.
Well, the first one is kind of one that would make Scratch lose lots of its appeal.

mybearworld wrote:

Supporting this.
If this is true:

AmazingMech2418 wrote:

[View post]

Also, another place where the process is less transparent is where you will essentially be yelled at if you submit a pull request for any issue that is not labelled “help wanted”, which also goes against all open-source philosophy.

Then why does Scratch have GitHub in first place? ScratchCat has said on the “prequel” of this topic:

ScratchCat wrote:

[View post]

We welcome your feedback in the future and look forward to sharing more with you.

Well, okay – then why completely ignore everything the community says? I don't say that a reply limit is a bad idea – oh wait, I do! That's because I don't know why. We only get to know reasoning of features after they've been released, while we get to know they exist beforehand, as this is open source, after all. Does this make sense?
There are only two possibilities that make sense.
» Stick with the current way of things, but then make Scratch closed source. Open source just doesn't work like that.
» This.
Well, the first one is kind of one that would make Scratch lose lots of its appeal.

With the first one, I'm not sure, and “yelling” is a bit of a hyperbole, but I've made various PRs that were all closed because they weren't “help wanted” when a Scratch Team member did the same thing and had the PR merged.

And yes, I completely agree with everything else you said.

More transparency would be great. without it all we can try to do is add things up.

Looks like the development process has been pulled mostly (completely?) in-house.
Developers are making less effort to have a relationship with volunteers.
Your previous topic was close by an team alias which also suggests keeping you at arms length.
The Community guidelines now specifically spells out several violations that look like they are huge time-syncs for moderators.
There is at least one hint from a moderator that it would be better if studio comments were about peoples’ programs and not free-form chat rooms.
The contested change you were talking about limits the number of replies to a comment and that looks like it will have the most impact to studios used as chat rooms (which now require moderation time and chat rooms are not central to the mission).
The new change to the filterbot is now so sensitive that it’s constantly muting ordinary respectful comments but it is also muting many that a moderator would have to spend time on.
The Scratch Foundations expenses have gone up this year. For example, they now have to pay rent for their work facilities.
Over fifty five percent of last year’s donations is labeled ‘at risk’ because it came from just two organizations.
The donation banner is still up on the website even though Scratch Week has ended.

I am not trying to start any rumors. I’m just supporting the suggestion for more transparency. If the new management of the Scratch Team is asking for some improvements to operational efficiency it would be nice if they would tell us that so we don’t keep wondering what the heck is going on.

ScratchCat wrote:

We're also discussing better ways to gather feedback from Scratchers in the future.

What better way to be able to gather feedback than this suggestion?

Support, the reply limit is highly controversial. If a reason they implement the reply limit is because of the difficulty of moderating chat studios, then discourage chat studios. If another part of the reason is expenses would be a little too high for the ST's liking because of the chat studios, then just discourage chat studios. It can be temporary, until Scratch is at a fairly stable financial point where the ST feel like they can handle chat studios, no longder discourage them. If that's not all of the reasoning, it's better to just tell what the other reasons are. If the community can come up with better solutions that sufficiently solve for the other reasons, then let them. Part of that suggestion that was closed by Za-Chary was to have the ST be more responsive to the community, while I would never agree with why the owner of the topic added it in, I do agree that the ST should be more responsive in some way. This suggestion is the perfect example for said way. The ST are human, meaning that they might not be able to come up with the best solution. The community might sure as heck not be able to come up with the best solution most of the time, but by working together, better solutions could be made, making Scratch fundamentally better.

AmazingMech2418 wrote:

With the first one, I'm not sure, and “yelling” is a bit of a hyperbole, but I've made various PRs that were all closed because they weren't “help wanted” when a Scratch Team member did the same thing and had the PR merged.

And yes, I completely agree with everything else you said.

To be fair, I don't think the Scratch Team appreciates random Scratchers attempting to do their job for them without any consultation first.

fdreerf wrote:

AmazingMech2418 wrote:

With the first one, I'm not sure, and “yelling” is a bit of a hyperbole, but I've made various PRs that were all closed because they weren't “help wanted” when a Scratch Team member did the same thing and had the PR merged.

And yes, I completely agree with everything else you said.

To be fair, I don't think the Scratch Team appreciates random Scratchers attempting to do their job for them without any consultation first.

im no expert, but isnt like half of the point of open source being many people can all collaborate on one project?

TopCode wrote:

fdreerf wrote:

AmazingMech2418 wrote:

With the first one, I'm not sure, and “yelling” is a bit of a hyperbole, but I've made various PRs that were all closed because they weren't “help wanted” when a Scratch Team member did the same thing and had the PR merged.

And yes, I completely agree with everything else you said.

To be fair, I don't think the Scratch Team appreciates random Scratchers attempting to do their job for them without any consultation first.

im no expert, but isnt like half of the point of open source being many people can all collaborate on one project?

Yes, however ultimately they are the ones in charge of the project. Open source does not necessarily mean transparent development; I believe that Scratch is open source because it assures Scratch will be free forever.

TopCode wrote:

fdreerf wrote:

AmazingMech2418 wrote:

With the first one, I'm not sure, and “yelling” is a bit of a hyperbole, but I've made various PRs that were all closed because they weren't “help wanted” when a Scratch Team member did the same thing and had the PR merged.

And yes, I completely agree with everything else you said.

To be fair, I don't think the Scratch Team appreciates random Scratchers attempting to do their job for them without any consultation first.

im no expert, but isnt like half of the point of open source being many people can all collaborate on one project?

If anyone could freely submit code, Scratch would be a nightmare of clashing styles, functionalities, and bugs. I'm pretty sure that all new features to Scratch go through a pretty extensive design and development process in order to ensure that they fit the theme and goals of Scratch. Submitting a PR without consulting with the Scratch Team first is nearly guaranteed to get closed because it hasn't gone through the same thought or design process, and therefore might not be a good fit for the Scratch website or editor. Open Source means anyone can view or offer to contribute to the code, but it doesn't mean that your suggestions have to be implemented.

fdreerf wrote:

AmazingMech2418 wrote:

With the first one, I'm not sure, and “yelling” is a bit of a hyperbole, but I've made various PRs that were all closed because they weren't “help wanted” when a Scratch Team member did the same thing and had the PR merged.

And yes, I completely agree with everything else you said.

To be fair, I don't think the Scratch Team appreciates random Scratchers attempting to do their job for them without any consultation first.

agreed, if i went and implemented a pause button into scratch, it would be rightfully rejected because #1 the scratch team didn't want a pause button and #2 it's probably implemented like garbage.

as someone maintaining their own open source projects, (ocular, my-ocular etc) i would hate to have PRs about features i never wanted. what am i supposed to say to them? they obviously spent a lot of time on this, but i never asked for it

so it seems reasonable for the scratch team to limit PRs. open source just means public code, it doesn't necessarily mean anything else.

that being said, i agree with the general ideas you bring up in your post. the scratch team isn't being really transparent, and that's something i wish they did. but it's important to note that they are busy people, so it might not be possible to explain and discuss every change they make.

So here's my two cents as a non-developer;

What fdreerf said is true; Scratch is open-source but they're likely very selective about what PRs they accept to maintain a good standard in their codebase. I imagine any PRs they accept anyways are likely formatted or changed to fit with whatever internal guidelines they have.

I do agree that Scratch would do well to tell us more about what's going on, because it feels like any change made to the website is announced very suddenly and the community feels largely uninvolved. I think the best example of this is the suggestions forum, where all we really have to go on is a post that Lightnin (who is no longer a part of Scratch) made around 7 years ago that outlines some basic design principles. In 7 years I've seen exactly one suggestion added which was then removed a while later (being able to backpack code snippets from the forums.)

The big issue is how you'd actually go about making that development process more transparent. They already seem like very busy people and the argument of “Do Scratch users really have suggestions that benefit the website most of the time” could be its own separate topic.

Jeffalo wrote:

agreed, if i went and implemented a pause button into scratch, it would be rightfully rejected because #1 the scratch team didn't want a pause button and #2 it's probably implemented like garbage.

Horrible open source pull requests are my aesthetic. Whenever I see code on github indented by 20+ tabs I grow stronger.

im pretty sure this will be closed with the funny message “we welcome your feedback”

kccuber wrote:

im pretty sure this will be closed with the funny message “we welcome your feedback”

Yeah, the corporate customer service talk that I often parody needs to go.

Yes, we definitely need community input before something is implemented. This kind of already exists with ScratchLab.

What I may suggest is the following:
-When a new update/feature is planned, a sticky is made on the Suggestions forum (not the announcements forum, to prevent unwanted spam).
-Scratchers from the suggestions forum discuss the feature in that topic.
-The same method when considering suggestions will be applied to this, except the amount of support is taken into account a little.

10goto10 wrote:

More transparency would be great. without it all we can try to do is add things up.

Looks like the development process has been pulled mostly (completely?) in-house.
Developers are making less effort to have a relationship with volunteers.
Your previous topic was close by an team alias which also suggests keeping you at arms length.
The Community guidelines now specifically spells out several violations that look like they are huge time-syncs for moderators.
There is at least one hint from a moderator that it would be better if studio comments were about peoples’ programs and not free-form chat rooms.
The contested change you were talking about limits the number of replies to a comment and that looks like it will have the most impact to studios used as chat rooms (which now require moderation time and chat rooms are not central to the mission).
The new change to the filterbot is now so sensitive that it’s constantly muting ordinary respectful comments but it is also muting many that a moderator would have to spend time on.
The Scratch Foundations expenses have gone up this year. For example, they now have to pay rent for their work facilities.
Over fifty five percent of last year’s donations is labeled ‘at risk’ because it came from just two organizations.
The donation banner is still up on the website even though Scratch Week has ended.

I am not trying to start any rumors. I’m just supporting the suggestion for more transparency. If the new management of the Scratch Team is asking for some improvements to operational efficiency it would be nice if they would tell us that so we don’t keep wondering what the heck is going on.

Yes, I completely agree. Also, if the funding is at risk, don't you think they'd try to put more effort into improving relationships with the Scratch community…

DarthVader4Life wrote:

ScratchCat wrote:

We're also discussing better ways to gather feedback from Scratchers in the future.

What better way to be able to gather feedback than this suggestion?

Support, the reply limit is highly controversial. If a reason they implement the reply limit is because of the difficulty of moderating chat studios, then ban chat studios. If another part of the reason is expenses would be a little too high for the ST's liking because of the chat studios, then just ban chat studios. It can be temporary, until Scratch is at a fairly stable financial point where the ST feel like they can handle chat studios, unban them. If that's not all of the reasoning, it's better to just tell what the other reasons are. If the community can come up with better solutions that sufficiently solve for the other reasons, then let them. Part of that suggestion that was closed by Za-Chary was to have the ST be more responsive to the community, while I would never agree with why the owner of the topic added it in, I do agree that the ST should be more responsive in some way. This suggestion is the perfect example for said way. The ST are human, meaning that they might not be able to come up with the best solution. The community might sure as heck not be able to come up with the best solution most of the time, but by working together, better solutions could be made, making Scratch fundamentally better.

Yes, I completely agree. And most of us also do have some sort of programming experience too, so it's not like we don't have anything to contribute, and with the activity of the Advanced Topics section, there is no reason to assume that communicating with us about this would “confuse us” or anything.

Jeffalo wrote:

fdreerf wrote:

AmazingMech2418 wrote:

With the first one, I'm not sure, and “yelling” is a bit of a hyperbole, but I've made various PRs that were all closed because they weren't “help wanted” when a Scratch Team member did the same thing and had the PR merged.

And yes, I completely agree with everything else you said.

To be fair, I don't think the Scratch Team appreciates random Scratchers attempting to do their job for them without any consultation first.

agreed, if i went and implemented a pause button into scratch, it would be rightfully rejected because #1 the scratch team didn't want a pause button and #2 it's probably implemented like garbage.

as someone maintaining their own open source projects, (ocular, my-ocular etc) i would hate to have PRs about features i never wanted. what am i supposed to say to them? they obviously spent a lot of time on this, but i never asked for it

so it seems reasonable for the scratch team to limit PRs. open source just means public code, it doesn't necessarily mean anything else.

that being said, i agree with the general ideas you bring up in your post. the scratch team isn't being really transparent, and that's something i wish they did. but it's important to note that they are busy people, so it might not be possible to explain and discuss every change they make.

Yes, this makes sense, but when there's an issue that they are already saying they want, and doesn't involve design or anything (like just code, not a new React component or CSS or something), they should at least review the code instead of completely dismissing it just because the issue wasn't “help wanted”.

kccuber wrote:

im pretty sure this will be closed with the funny message “we welcome your feedback”

Yes, it probably will. LOL! And that will just prove my point even more. XD

AmazingMech2418 wrote:

Yes, this makes sense, but when there's an issue that they are already saying they want, and doesn't involve design or anything (like just code, not a new React component or CSS or something), they should at least review the code instead of completely dismissing it just because the issue wasn't “help wanted”.

That's the developers' job and it seems pretty rude to barge in and try and do it for them.

removed

fdreerf wrote:

AmazingMech2418 wrote:

Yes, this makes sense, but when there's an issue that they are already saying they want, and doesn't involve design or anything (like just code, not a new React component or CSS or something), they should at least review the code instead of completely dismissing it just because the issue wasn't “help wanted”.

That's the developers' job and it seems pretty rude to barge in and try and do it for them.

Well, that's how open-source works. XD

fdreerf wrote:

AmazingMech2418 wrote:

Yes, this makes sense, but when there's an issue that they are already saying they want, and doesn't involve design or anything (like just code, not a new React component or CSS or something), they should at least review the code instead of completely dismissing it just because the issue wasn't “help wanted”.

That's the developers' job and it seems pretty rude to barge in and try and do it for them.

It's not that we're trying to do their jobs, it's that we're wanting to be able to offer fresh perspectives more often. This way, the ST can repair their relations with the scratchers and be able to avoid making things that no one really wants. (As long as a better solution comes along.)

AmazingMech2418 wrote:

fdreerf wrote:

AmazingMech2418 wrote:

Yes, this makes sense, but when there's an issue that they are already saying they want, and doesn't involve design or anything (like just code, not a new React component or CSS or something), they should at least review the code instead of completely dismissing it just because the issue wasn't “help wanted”.

That's the developers' job and it seems pretty rude to barge in and try and do it for them.

Well, that's how open-source works. XD

Open source doesn't equate to community volunteering. It just means that the code is openly accessible to everyone.

DarthVader4Life wrote:

It's not that we're trying to do their jobs, it's that we're wanting to be able to offer fresh perspectives more often. This way, the ST can repair their relations with the scratchers and be able to avoid making things that no one really wants. (As long as a better solution comes along.)

Submitting unwarranted pull requests is exactly doing their jobs. They already have enough “fresh perspectives” and ultimately it is their choice on how Scratch is ran.