1. IMHO that there is a workaround (by itself) is NEVER a valid response to ANY suggestion. Let's all use machine code from now on. You object? But there is always a workaround! It's nonsense. Cut it out. THINK. I offend you? Tough. That's the long and short of it. It is just not relevant, and mostly a waste of time to say that. PLEASE DON'T.

Why do I feel this way? Because too many good suggestions have fallen by the wayside or been given short shrift because a small but persistent contingent thought their preferred workaround was the only one that should be allowed, without considering the needs of other users with different needs and use cases.

Let me be clear: I agree there may be valid reasons for thinking a particular workaround is sufficient, but the onus is on the person saying this to state what these are.
* Is the workaround AS EASY as the suggestion?
* Does the suggestion have any negative consequences?
* Does it conflict with other factors?

Two cases I know of are perfect examples. Folders for projects, and listing all the studios when pressing the add to studio button on a project page. Both of these have generated significant “there is a workaround” comment, without actual justification (some people have offered reasons. But many just throw “workaround” out there. This is what i am talking about.) The workarounds suggested are time consuming. They require extra steps such as page loads, keystrokes, memorization, that can easily become not trivial in some cases and are obstacles for a sufficiently large portion of target users. The solutions have benefits that the workarounds do not. The solutions meets reasonable and, importantly, STANDARD expectations about ease of use, especially for inexperienced/low ability (e.g. young) users. It is not unusual, and I would argue a de facto standard, for similar programs that in some fashion create libraries of projects to provide the features suggested, e.g. the ability to see all your projects when given a choice, or to organize your projects into subfolders. Scratch is the outlier here, and so the burden is on Scratch to show why its behavior is justified. It serves no direct purpose to the general user and goes against standard practice. If the concern is not overwhelming the user with choices, the number of initial choices could be limited, but providing no access at all requires justification. If it is an internal problem, i.e. an implementation issue, then that needs to be MADE EXPLICIT and looked at in balance with the user perspective. That is a different thing than merely “a workaround exists”. That is the key point.

You may prefer your solution to a given problem, but the question you need to ask is (along the lines of): Would enough people/projects benefit, with a great enough frequency, and at a low enough cost, to justify the quantity of work needed to implement the suggestion in the long term.

I, personally, would even go so far as to say that if a solution were easy enough (and justifiable enough) to implement, it would be worth it even if only one person on one project would benefit. You may think that is exactly the situation you want to avoid, but imagine if it involved fixing hate speech directed at you, or protecting your privacy or other rights, would you really deny it to yourself due to a “workaround”, if it the workaround were lengthy, not easily used, or potentially less effective? What does that say about your priorities? I admit this is rare and not likely to occur, but as a matter of principle this shows how priorities need to be balanced, not ad hoc or dogmatically and reactively applied. I think a situation can be sufficiently illustrative that it can be relevant and actionable even if it is rare. AND, I say that fully willing to listen to alternate points of view about it, and honestly assessing the limitations of my own view.

I agree that in many, even potentially most, cases a given workaround can be sufficient. Often, suggestions are made from a lack of knowledge of the workaround. But I know of cases where someone specifically mentions the workaround when making the suggestion, and tries to make the case for their solution, only to be shouted down by calls “workaround workaround”, when that wasn't the question. The existence of the workaround by itself is not a reason, and too often all people say is “there is a workaround” when they haven't really thought through (in some cases blatantly refuse to think through) WHY the workaround is sufficient or WHY the solution not necessary or beneficial.

Consider this: the Scratch Wiki has a page devoted entirely to workarounds for various actions. Shouldn't we erase that? Of course not, because individual circumstances may make one or another method more useful. Workarounds and multiple approaches make Scratch better, and can lead to new capabilities over time. What seems redundant at one point can eventually become its own thing. Again, not always, but that should be the default perspective and is in line with Scratch's objectives.

My proposal is, jocularly, to ban this. By this I mean should be treated as deprecated, i.e. should be labeled as such in a consistent manner, and should be ignored/made unprofitable. I think a large part of this would involve action by the community to police this behavior (respectfully but firmly), but may also entail actions/overt support by the scratch team itself to address. I am not for censoring speech, but establishing and raising standards to improve the relevance, accessibility, and effectiveness of the discussion.

But we need to know there is a workaround.

Here is a chart generated from text


Simple suggestion Moderate Suggestion Complex Suggestion

Easy workaround OK Workaround Workaround
Moderate workaround Workaround OK OK
Complex workaround Workaround OK OK


Workaround = Workaround is the better solution
OK = The suggestion is the better solution

(this is a terrible graph)

How would the community collectively draw the same conclusion over where the proverbial line is? What constitutes as “calling workaround” in an unconstructive matter, and what constitutes as pointing out that there is a very simple way with which to avoid having the developers spend time, resources, and possibly money to fix a problem which is relevant only for a small subset?

It is also possible to point out that there is an alternate solution (“workaround”) to the problem without raising that as a point against the suggestion. Suggestions typically take some time to be enforced/implemented, and well-meaning community members could easily get confused.

I think the logic which was used in the following rejection of a “Ban Certain Franchises” suggestion may be applicable to this counterargument:

The Official List of Rejected Suggestions wrote:

3.3 Ban certain franchises
Generally, the Scratch Team does not censor projects based on a certain franchise unless a large number of inappropriate projects were made with the franchise. An example is Five Nights at Freddy's; see this announcement for more information. In general, it is usually possible to make appropriate projects based on a certain franchise. Of course, you should always report inappropriate projects of any kind.

As stated earlier, a parallel can be drawn to conclude that such logic applies to this suggestion as well. While the instances you speak of the original post do occur with frequency, many have proven that it is possible and even useful to point out a workaround in a constructive manner.

In conclusion, while I hear your point, I believe that “jocularly banning” the act of pointing out a workaround may cause confusion about what instances of this constitute “over the line,” which may lead to unpleasant misunderstandings. It would be better suited to simply encourage users to fully think through a suggestion before replying – an action which is already taking place.

Some people might need a workaround, for example, the poster made the suggestion but is new to scratch and didn't realize there is a very simple workaround for that reason

No Support. For one, some suggested blocks (like not equals) have very easy workarounds, so that should be pointed out on them. For two, it can be convenient to have a workaround for an idea if it's not implemented.

ScratchCat1038 wrote:

No Support. For one, some suggested blocks (like not equals) have very easy workarounds, so that should be pointed out on them. For two, it can be convenient to have a workaround for an idea if it's not implemented.

No support for this reason.

Yellowsheep43 wrote:

But we need to know there is a workaround.

Here is a chart generated from text


Simple suggestion Moderate Suggestion Complex Suggestion

Easy workaround OK Workaround Workaround
Moderate workaround Workaround OK OK
Complex workaround Workaround OK OK


Workaround = Workaround is the better solution
OK = The suggestion is the better solution

(this is a terrible graph)

The graph is not terrible, it is useful.It is an attempt at a logical approach, so I respect it.

I agree that knowing there is a workaround is relevant. My complaint is with stating that this is sufficient to trump the suggestion without stating a reason. As I said, sometimes the suggester KNOWS there is a workaround.

Anyway, you are right to evaluate the two and the graph is a way of sorting through it. With you up to there.

Once concern with your approach would be then that it reduces the question to one factor, complexity. So I agree we need to go beyond the mere existence of the workaround, but would go further than you. I tried to suggest there are many factors involved, questions that need to be answered, etc.

Secondly, you say a moderately complex workaround trumps a simple suggestion. Why?
For that matter, a complex suggestion seems to trump a moderate workaround? I wouldn't necessarily agree with that either.
Am I misreading your graph?

removed

So what if you did this?

Support because there is a workaround. However, it's hard, especially for newer Scratchers and this would be used often.

No support because it's mainly used constructively by people who are well into the forums.

My opinion is that if a workaround is

1. Extremely time consuming
   
2. Not easy to figure out
   
3. Uses (an) external program(s)
   

then it shouldn't be posted. However, if the suggestion will only help <5% of Scratch's users and/or projects, then it's better to use the workaround.

TurtleLegos wrote:

ksdavidc wrote:

Yellowsheep43 wrote:

But we need to know there is a workaround.

Here is a chart generated from text


Simple suggestion Moderate Suggestion Complex Suggestion

Easy workaround OK Workaround Workaround
Moderate workaround Workaround OK OK
Complex workaround Workaround OK OK


Workaround = Workaround is the better solution
OK = The suggestion is the better solution

(this is a terrible graph)

The graph is not terrible, it is useful.It is an attempt at a logical approach, so I respect it.

An attempt? It is a logical approach.

Anyway, the graph is something that really changes my mind. Sometimes the workaround is the solution, sometimes it isn't. No support, more of the time, it's the best solution.
Also there is a workaround

I am sorry I didn't mean to sound as though I was impugning the remark. I agree it is logical, I meant attempt at a full solution. FOr example, I am not sure I understood how to read the chart, and I think I might argue against some of the entries, so it may be logical, but I still think open to discussion.

My more fundamental concern is it reduces the problem to merely a matter of complexity, which I feel is not sufficient. I agree often the workaround is the better solution, and I am all for making that apparent. What I am suggesting is thinking more deeply about what factors would or would not make this the case (e.g. ease of use, likelihood of benefit, ability to help those with special needs, etc.) so that we can better help sort this out. Too often we get remarks like “I don't support because there is a workaround” with no justfication for how that addresses differences in the approach. Even mere complexity is not crystal clear.

modesties wrote:

So what if you did this?

Support because there is a workaround. However, it's hard, especially for newer Scratchers and this would be used often.

I am not sure I understand what you are saying. For me that would be a valid response, as it gives reasons. Anyway, I am more concerned with “non-support because workaround” type comments.

modesties wrote:

No support because it's mainly used constructively by people who are well into the forums.

Do you mean you do not support (my sugggestion) because saying “no support due to workaround” is being properly used? I can cite many examples where it is not IMHO used constructively, such as when reasons have been offered for why the suggestion is better than the workaround, or addresses issues not covered by the workaround, and the response does not address.

Support or not support is not the issue here. I am seeking to create a discussion that would lead to a proposal to address the situation. I don't literally mean ban anything, so no one is being asked to support that. But I hope you could support discussing how to better address this.

Steve0Greatness wrote:

My opinion is that if a workaround is

1. Extremely time consuming
   
2. Not easy to figure out
   
3. Uses (an) external program(s)
   

then it shouldn't be posted. However, if the suggestion will only help <5% of Scratch's users and/or projects, then it's better to use the workaround.

I would agree that those kind of workarounds are probably not relevant and should be deprecated/discouraged, but I would argue that it is not the number of users that matters but the cost benefit ratio, and whether the two are truly equivalent. Nonetheless I think you are right that that is how it is ought likely pan out in most cases.

ScratchCat1038 wrote:

No Support. For one, some suggested blocks (like not equals) have very easy workarounds, so that should be pointed out on them. For two, it can be convenient to have a workaround for an idea if it's not implemented.

I am not objecting to workarounds be posted, but to workarounds being used to justify lack of support without reasons being offered. You are right, workarounds are a good thing. I hoope it is clear my suggestion for a ban was tongue in cheek, and I explain later what I am really suggesting, which is in line with what you are saying.

@Queer_Royalty This is a very thoughtful reply and you raise good points.

Queer_Royalty wrote:

How would the community collectively draw the same conclusion over where the proverbial line is?

How does the community collectively draw conclusions about anything? It doesn't, but somehow we are able to institute norms that most people follow, such as how to quote things, how to etc. The Scratch team itself publishes guidelines, and the community helps (re)e/inforce these. I do allude to this question, and agree it is somewhat nebulous. I do think there are some near-bright lines on this such as the difference between merely mentioning the workaround, and stating the specific reason this excludes the suggestion.

Queer_Royalty wrote:

What constitutes as “calling workaround” in an unconstructive matter, and what constitutes as pointing out that there is a very simple way with which to avoid having the developers spend time, resources, and possibly money to fix a problem which is relevant only for a small subset?

Again, I suggest that the line be whether the workaround is offered with a reason why this expressly refutes the need for the suggestion. Granted there may be borderline cases, but there are also cases that are clearly contructive or not constructive and developing criteria to identify these is valuable.

Queer_Royalty wrote:

It is also possible to point out that there is an alternate solution (“workaround”) to the problem without raising that as a point against the suggestion. Suggestions typically take some time to be enforced/implemented, and well-meaning community members could easily get confused.

Agreed. There is a difference between “Are you aware there is a workaround”, and “I don's support any suggestion for which there is a workaround I like”.

Queer_Royalty wrote:

I think the logic which was used in the following rejection of a “Ban Certain Franchises” suggestion may be applicable to this counterargument:

The Official List of Rejected Suggestions wrote:

3.3 Ban certain franchises

Queer_Royalty wrote:

Generally, the Scratch Team does not censor projects based on a certain franchise unless a large number of inappropriate projects were made with the franchise. An example is Five Nights at Freddy's; see this announcement for more information. In general, it is usually possible to make appropriate projects based on a certain franchise. Of course, you should always report inappropriate projects of any kind.

As stated earlier, a parallel can be drawn to conclude that such logic applies to this suggestion as well. While the instances you speak of the original post do occur with frequency, many have proven that it is possible and even useful to point out a workaround in a constructive manner.

I understand your point. One could interpret you as saying that this is not a common phenomenon, and so should not be constrained even if it is not recommended. (Note again that I am not suggestion (seriously) censoring anyone in any way. Arguably my use of the word “ban” might be seen as inflammatory, but it was not intended as such.)

However, as your case mentions, even this has its limits. I would prefer not to view this through the lens of the number of people affected but through some (arguably) more relevant criteria.

Queer_Royalty wrote:

In conclusion, while I hear your point, I believe that “jocularly banning” the act of pointing out a workaround may cause confusion about what instances of this constitute “over the line,” which may lead to unpleasant misunderstandings. It would be better suited to simply encourage users to fully think through a suggestion before replying – an action which is already taking place.

I don't want to create confusion. Far from it, I want to develop some clear criteria by which such situations can be evaluated. I take no a priori position as to whether workarounds or solutions are better, and while i may have opinions about some things (e.g. how important the number of beneficiaries is, etc.) my goal is merely to develop relevant criteria which can be used to evaluate individual cases. This is far from trying to confuse matters.

I agree that encouraging others to think more before posting is part of the solution, and thank you for pointing out that there are efforts in this direction.

In fact, I discovered on searching in a different way for this topic, that there was a long thread on this from about 4 years ago, and will post the link once I have had a chance to look at it.

Again, thank you for the thoughtful and thought-provoking response.

oops, I pressed submit by error. Editing now…

Someone asked how we would be able to get the community to agree on what is a good versus bad workaround. One way this could be addressed would be to provide some kind of response template, e.g.

I support this suggestion because:


I would like to state the following workaround:


I believe this workaround is a sufficient alternative because:

It can be used in all cases that the suggestion can be used. It is redundant and without benefit.
While not entirely redundant, the differences are not significant. They are only minor inconveniences, without loss of functionality.
There is loss of functionality but the loss is minor because the new functionality:
Is outside of the goals of Scratch
Those who would benefit are can reasonably be asked to live without it without it being discriminatory.
The suggestion does not provide a capability that is
Standard for this application
expected for this situation
despite being novel or interesting, is not likely to have wide application
The cost of implementing it is too high due to:
amount of coding time needed
difficulty or complexity of creating the workaround
high possibility of misuse
The suggestion has the following negative consequences:
The people who would gain from the suggestion are few and would only bear minor inconveniences
The workaround addresses all the concerns raised

This is very rough, and just suggestive, but I think it would help people think about the issue in a way that is likely to be relevant to decision makers. I am sure with some effort, the coders and other relevant parties would be able to draw up a more salient list based on a wider ranne of experinec.e

Nor would this be intended as a limitation on either the expression or the content of opinions. No one's speech would be curtailed by the existence of a template. But it could help improve the quality and usefulness of the communication.

No support. Theres a workaround. People need to know the workarounds. Even ST members use workarounds.

ksdavidc wrote:

modesties wrote:

So what if you did this?

Support because there is a workaround. However, it's hard, especially for newer Scratchers and this would be used often.

I am not sure I understand what you are saying. For me that would be a valid response, as it gives reasons. Anyway, I am more concerned with “non-support because workaround” type comments.

modesties wrote:

No support because it's mainly used constructively by people who are well into the forums.

Do you mean you do not support (my sugggestion) because saying “no support due to workaround” is being properly used? I can cite many examples where it is not IMHO used constructively, such as when reasons have been offered for why the suggestion is better than the workaround, or addresses issues not covered by the workaround, and the response does not address.

Support or not support is not the issue here. I am seeking to create a discussion that would lead to a proposal to address the situation. I don't literally mean ban anything, so no one is being asked to support that. But I hope you could support discussing how to better address this.

Support because there is a workaround. However, it's hard, especially for newer Scratchers and this would be used often.

read it
Also, what if it still hasn't been added yet and it doesn't involve anything to do with extensions or any of that kind?

Workarounds are temporary solutions before a suggestion gets added. It's good to know there is a workaround. Here is a better version of the chart:

-Is the suggestion simple? The suggestion is the better solution, regardless of how simple the workaround is.

-Is the suggestion moderate and the workaround is simple? The workaround is the better solution
-Is the suggestion moderate and the workaround is also moderate? This would ultimately depend on the context.
-Is the suggestion moderate and the workaround is complex? The suggestion is the better solution.

-Is the suggestion complex and the workaround is simple? The workaround is the better solution.
-Is the suggestion complex and the workaround is moderate? The workaround is the better solution.
-Is the suggestion complex and the workaround is complex? This would ultimately depend on the context.

Yellowsheep43 wrote:

Workarounds are temporary solutions before a suggestion gets added. It's good to know there is a workaround.

Agreed. However, when someone says I don't support merely because there is a workaround, that is a different matter. That is insufficient.

Yellowsheep43 wrote:

Here is a better version of the chart:

-Is the suggestion simple? The suggestion is the better solution, regardless of how simple the workaround is.

-Is the suggestion moderate and the workaround is simple? The workaround is the better solution
-Is the suggestion moderate and the workaround is also moderate? This would ultimately depend on the context.
-Is the suggestion moderate and the workaround is complex? The suggestion is the better solution.

-Is the suggestion complex and the workaround is simple? The workaround is the better solution.
-Is the suggestion complex and the workaround is moderate? The workaround is the better solution.
-Is the suggestion complex and the workaround is complex? This would ultimately depend on the context.

You are begging the questions (i.e. assuming the conclusion). What do simple, moderate and complex mean? It is precisely defining those that is the matter at hand. Plus, I might argue with some of your determinations. You still have to see if (regardless of simplicity) the suggestion has implications or usages missing in the workaround, for example usage inside clones, usage on a given device, etc. Mere simplicity is, well, too simple. IMHO