AmazingMech2418 wrote:

fdreerf wrote:

DarthVader4Life wrote:

Which is why the ST should be more transparent.

They absolutely should, but they shouldn't also be obligated to accept every community suggestion/pull request.

They shouldn't be obligated to do that, only to actually look at them and consider them first before deciding to reject them.

They never asked nor needed the pull requests. They would review them and then reject them afterwards, so they might as well save the time. You should respect the etiquette that the developers have set up, and there's not an exemption “because it's free software”.

Accepting unnecessary pull requests is unrelated to being transparent or open source.

fdreerf wrote:

AmazingMech2418 wrote:

fdreerf wrote:

DarthVader4Life wrote:

Which is why the ST should be more transparent.

They absolutely should, but they shouldn't also be obligated to accept every community suggestion/pull request.

They shouldn't be obligated to do that, only to actually look at them and consider them first before deciding to reject them.

They never asked nor needed the pull requests. They would review them and then reject them afterwards, so they might as well save the time. You should respect the etiquette that the developers have set up, and there's not an exemption “because it's free software”.

I personally think that they should allow scratchers to know the reasons behind an upcoming update, and then let them discuss said updates. It could just be the suggestions forum or something that won't get spam.

Maximouse wrote:

Accepting unnecessary pull requests is unrelated to being transparent or open source.

It isn't about accepting them, or about unnecessary ones, but about reviewing the necessary ones that are just made by someone not on the Scratch Team. There have been multiple cases where there was an easy fix to something and I submitted a PR before a dev did, and they got mad at me because the issue wasn't “help wanted”, and closed my PR and then merged one that was nearly identical that was made by a dev. They don't need to accept all PRs, but should at least review those that are made for changes that they agree are needed.

AmazingMech2418 wrote:

Maximouse wrote:

Accepting unnecessary pull requests is unrelated to being transparent or open source.

It isn't about accepting them, or about unnecessary ones, but about reviewing the necessary ones that are just made by someone not on the Scratch Team. There have been multiple cases where there was an easy fix to something and I submitted a PR before a dev did, and they got mad at me because the issue wasn't “help wanted”, and closed my PR and then merged one that was nearly identical that was made by a dev. They don't need to accept all PRs, but should at least review those that are made for changes that they agree are needed.

They didn't want help, so they refused it.

fdreerf wrote:

AmazingMech2418 wrote:

Maximouse wrote:

Accepting unnecessary pull requests is unrelated to being transparent or open source.

It isn't about accepting them, or about unnecessary ones, but about reviewing the necessary ones that are just made by someone not on the Scratch Team. There have been multiple cases where there was an easy fix to something and I submitted a PR before a dev did, and they got mad at me because the issue wasn't “help wanted”, and closed my PR and then merged one that was nearly identical that was made by a dev. They don't need to accept all PRs, but should at least review those that are made for changes that they agree are needed.

They didn't want help, so they refused it.

So why just do the same work again when it's already been done?

AmazingMech2418 wrote:

fdreerf wrote:

AmazingMech2418 wrote:

Maximouse wrote:

Accepting unnecessary pull requests is unrelated to being transparent or open source.

It isn't about accepting them, or about unnecessary ones, but about reviewing the necessary ones that are just made by someone not on the Scratch Team. There have been multiple cases where there was an easy fix to something and I submitted a PR before a dev did, and they got mad at me because the issue wasn't “help wanted”, and closed my PR and then merged one that was nearly identical that was made by a dev. They don't need to accept all PRs, but should at least review those that are made for changes that they agree are needed.

They didn't want help, so they refused it.

So why just do the same work again when it's already been done?

I'm pretty sure they've already have done the work before making a pull request, and also, because they didn't need help, so why should you do work that you don't need to do at all?

fdreerf wrote:

AmazingMech2418 wrote:

fdreerf wrote:

AmazingMech2418 wrote:

Maximouse wrote:

Accepting unnecessary pull requests is unrelated to being transparent or open source.

It isn't about accepting them, or about unnecessary ones, but about reviewing the necessary ones that are just made by someone not on the Scratch Team. There have been multiple cases where there was an easy fix to something and I submitted a PR before a dev did, and they got mad at me because the issue wasn't “help wanted”, and closed my PR and then merged one that was nearly identical that was made by a dev. They don't need to accept all PRs, but should at least review those that are made for changes that they agree are needed.

They didn't want help, so they refused it.

So why just do the same work again when it's already been done?

I'm pretty sure they've already have done the work before making a pull request, and also, because they didn't need help, so why should you do work that you don't need to do at all?

They usually have not already done the work before making the pull request in those instances. It usually takes a day or two for the work to be done and the PR to be made. And it is easier for the devs to work on more complex bug fixes and adding features when the open-source community is fixing the minor bugs. But sometimes, the minor bugs are not labelled “help wanted” although they still certainly can be done by someone else to free up time for the devs to do the more complicated work behind it, which also improves Scratch's functionality. Many suggestions aren't accepted because they don't have the time to always implement the features. Open-source contributors fixing those minor bugs can give them that time.

This went from “the dev process should be more transparent” to “The ST should be forced to accept every pull request” very fast.

Despite being open source we have very little idea as to how development decisions are/were made. Perhaps they have perfectly legitimate reasons for rejecting your pull request for reasons we aren't aware of. Maximouse's point still stands. If you have an issue with it, it'd be more productive to take it up with the developers themselves rather than random users.

Davidstudio wrote:

This went from “the dev process should be more transparent” to “The ST should be forced to accept every pull request” very fast.

Despite being open source we have very little idea as to how development decisions are/were made. Perhaps they have perfectly legitimate reasons for rejecting your pull request for reasons we aren't aware of. Maximouse's point still stands. If you have an issue with it, it'd be more productive to take it up with the developers themselves rather than random users.

Well, the argument was never that they should accept every pull request, but just that they should review them instead of reject them simply due to a “help wanted” tag not being there.

The most important part though is the lack of transparency of decision-making in Scratch development, as is being seen with the reply limit, and as was seen countless times in the past with other controversial changes, such as auto-mute, and even the removal of the Discuss button about 4 years ago which fueled the famous #Bring_it_Back movement.

Support, this would increase the effectiveness of the forums too.

I agree and support, too. I read through the entire gitHub conversation and part of the forum discussion, and I have seen that the community can come up with better and/or more efficient ways to improve the site, rather than do something super-contraversial. I also think that with a more transparent development process, the Scratch Team would not upset many scratchers, of whom Scratch has been a big part of their lives. Also, reading through the conversation here, it seems as if ST is becoming less transparent, and I agree with all the points made.

Support,

Having the ST let Scratchers develop the site/program has several advantages.

1. The ST could focus on moderation more.
   
2. This would greatly reduce the amount of dev work the ST would have too do.
   
3. With more people helping, bugs could be destroyed quicker.
   

Although, if I were the ST I would make some kind of format for it.

skymover1239 wrote:

Support,

Having the ST let Scratchers develop the site/program has several advantages.

1. The ST could focus on moderation more.
   
2. This would greatly reduce the amount of dev work the ST would have too do.
   
3. With more people helping, bugs could be destroyed quicker.
   

Although, if I were the ST I would make some kind of format for it.

I agree with your points too.

skymover1239 wrote:

Support,

Having the ST let Scratchers develop the site/program has several advantages.

1. The ST could focus on moderation more.
   
2. This would greatly reduce the amount of dev work the ST would have too do.
   
3. With more people helping, bugs could be destroyed quicker.
   

Although, if I were the ST I would make some kind of format for it.

Last time I checked, this suggestion is to allow scratchers to offer their help.

I'm going to have to change on this.

I'm going to support the more transparency part of this suggestion only. Transparency can allow the ST to be able to be notified to things they might have missed. It could also help with the tension between the community and the ST.

I'm going to remove my support for the allowing of scratcher pull requests everywhere. Ultimately, it doesn't look like this would be a realistic standard for the ST members. And I want to make a compromise, not a demand.

DarthVader4Life wrote:

skymover1239 wrote:

Support,

Having the ST let Scratchers develop the site/program has several advantages.

1. The ST could focus on moderation more.
   
2. This would greatly reduce the amount of dev work the ST would have too do.
   
3. With more people helping, bugs could be destroyed quicker.
   

Although, if I were the ST I would make some kind of format for it.

Last time I checked, this suggestion is to allow scratchers to offer their help.

Yes, that is correct. The current system requires anyone to ask for permission to create a pull request first. However, this sort of defeats the whole point, since a PR can just be created first and either merged or rejected later. However, if the PR is created with the current system, it will automatically be rejected without reason, even if it fixes the problem in the exact same way the Scratch Team wants it to be fixed.

DarthVader4Life wrote:

-snip-
I'm going to remove my support for the allowing of scratcher pull requests everywhere. Ultimately, it doesn't look like this would be a realistic standard for the ST members. And I want to make a compromise, not a demand.

The suggestion isn't to merge any PR that comes in, just to allow PRs to be made and to review them instead of just rejecting them due to the lack of a “help wanted” label. One solution though would be to add a “in progress” label to the repos and use that if it is currently being fixed by a dev, so that a community member doesn't attempt to fix a bug that is already being fixed.

Bump…

It would also be cool if their design documentation would be public.

bump