Sigton wrote:

If you “don't have time” to reply to a post fully, then wait until you have time to finish it. You wouldn't send a half finished email or text, would you?

Sigton

Well if you don't have time to write a post how do you have time to full read the post and form a opinion about it?

Well, I think that posts that only state an unexplained opinion should count as spam.

Support.

I think that if you can't think of anything constructive– don't post.

Also, if a block has a workaround then it might still be a good adition. Does this sound right:

OP wrote:

I think we should have a new motion block:

move (10) steps

It moves the sprite in its current direction a certain amount of pixels.

No support, workaroundable:

go to x: ((x position) + ((...::grey) * ([sin v] of (direction)))) y: ((x position) + ((...::grey) * ([cos v] of (direction))))

And then Scratch becomes less attractive for begginers.

powercon5 wrote:

Sigton wrote:

If you “don't have time” to reply to a post fully, then wait until you have time to finish it. You wouldn't send a half finished email or text, would you?

Sigton

Well if you don't have time to write a post how do you have time to full read the post and form a opinion about it?

You don't; and that's the problem.

Sigton

jokebookservice1 wrote:

Well, I think that posts that only state an unexplained opinion should count as spam.

Support.

I think that if you can't think of anything constructive– don't post.

Also, if a block has a workaround then it might still be a good adition. Does this sound right:

OP wrote:

I think we should have a new motion block:

move (10) steps

It moves the sprite in its current direction a certain amount of pixels.

No support, workaroundable:

go to x: ((x position) + ((...::grey) * ([sin v] of (direction)))) y: ((x position) + ((...::grey) * ([cos v] of (direction))))

And then Scratch becomes less attractive for begginers.

funny, I literally just used that workaround in my newest project xD

Sigton wrote:

If you “don't have time” to reply to a post fully, then wait until you have time to finish it. You wouldn't send a half finished email or text, would you?

Sigton

Yeah.

1. No support. I don't agree. No supporting a suggestion can help the user who suggested the suggestion learn the consequences of the suggestion.
2. No support. I don't agree. If someone has their reason to no support, they have their reason. It's fine as long as it's aloud. (A kind that's not aloud would be said by the stickies not to do it.)
3. No support. I don't agree. Not knowing the consequences could end up with the Scratch Team accidentally doing a suggestion where bad stuff would happen.
4. Semi-support. I kind of agree. What if someone suggested a

this block does nothing :: control

block? It makes no sense. So it might be okay for a suggestion like that, but if it's a

(pen color :: pen)

block, then you shouldn't call it unnecessarily because it would do something.

Ziggy741 wrote:

1. I don't agree. No supporting a suggestion can help the user who suggested the suggestion learn the consequences of the suggestion.

The consequences?
“You thought of a suggestion I don't agree with, you must be punished!”

Ziggy741 wrote:

2. I don't agree. If someone has their reason to no support, they have their reason. It's fine as long as it's aloud. (A kind that's not aloud would be said by the stickies not to do it.)

*allowed
Saying support/no support without reason helps nobody. It doesn't help the suggestion get better, it doesn't benefit the creator of the suggestion, it doesn't make the suggestion any more likely to be accepted by the ST.

Ziggy741 wrote:

3. I don't agree. Not knowing the consequences could end up with the Scratch Team accidentally doing a suggestion where bad stuff would happen.

Please elaborate on this one.

Ziggy741 wrote:

4. I kind of agree. What if someone suggested a

this block does nothing :: control

block? It makes no sense. So it might be okay for a suggestion like that, but if it's a

(pen color :: pen)

block, then you shouldn't call it unnecessarily because it would do something.

I don't understand what you are meaning here.

Sigton

Ziggy741 wrote:

1. No support. I don't agree. No supporting a suggestion can help the user who suggested the suggestion learn the consequences of the suggestion.

That's not what we're saying, we're saying that you shouldn't just say “No Support” without stating a reason.

Ziggy741 wrote:

2. No support. I don't agree. If someone has their reason to no support, they have their reason. It's fine as long as it's aloud. (A kind that's not aloud would be said by the stickies not to do it.)

Yes, but they should at least refrain from supporting or no supporting till they understand the topic, or it's just junk.

Ziggy741 wrote:

3. No support. I don't agree. Not knowing the consequences could end up with the Scratch Team accidentally doing a suggestion where bad stuff would happen.

Well, that doesn't mean you should just shoot down their suggestion without saying how you think it could be improved, many people just say only bad things about suggestions.

Ziggy741 wrote:

1. No support. I don't agree. No supporting a suggestion can help the user who suggested the suggestion learn the consequences of the suggestion.
2. No support. I don't agree. If someone has their reason to no support, they have their reason. It's fine as long as it's aloud. (A kind that's not aloud would be said by the stickies not to do it.)
3. No support. I don't agree. Not knowing the consequences could end up with the Scratch Team accidentally doing a suggestion where bad stuff would happen.
4. Semi-support. I kind of agree. What if someone suggested a

this block does nothing :: control

block? It makes no sense. So it might be okay for a suggestion like that, but if it's a

(pen color :: pen)

block, then you shouldn't call it unnecessarily because it would do something.

1. Not as much as you explaining the consequences though..

2. Yes, well the reason should be agood one. I believe Sigton meant that you shouldn't no support because you don't fully understand a suggestion or think that something looks weird just because you've never encountered something before

3. Yes, say what is bad, and also say how you could fix the problem. And I think lots of members of the Scratch Team will spend ages thinking about the suggestion before they actually implement it

4. Yes, but some blocks that do something can be unnecessery and vice versa:

(direction plus 1  ::motion) //Bad
Ignore code \(for debugging\) {
...::control
} :: grey //Possibly useful

For Sigton:
1. I never said that you should not give a reason.
2. You're not supposed to support/semi-support/no support without a reason.
3. The Scratch Team could think that an idea is good, and then they add it, and then it leads to bad stuff happening.
4. There is no use for the first block example I gave because it would do nothing, and the other one would be useful because it would report the pen color value.

For MegaByteCorporations:
1. I never said that you should not give a reason.
2. What do you mean?
3. But the Scratch Team could accidentally add a bad idea. Just say it nicely.

For jokebookservice1:
1. What's wrong with telling the consequences?
4. How would that ignore code block be helpful?
(I skipped 2 and 3 because I didn't have anything to say.)

Sigton wrote:

2ndSuggestion wrote:

Secondly, I'm also disliking the fact people are jumping to conclusions about suggestions. People are picking out the smallest reason to down a suggestion, or just downing a suggestion simply because they don't understand it. For example, I saw this:

Anonymous wrote:

I have no idea what you're asking for. No support until further notice.

Can you go ahead and remove my quote? I find the use of it disrespectful.

Ziggy741 wrote:

For Sigton:
1. I never said that you should not give a reason.
2. You're not supposed to support/semi-support/no support without a reason.
3. The Scratch Team could think that an idea is good, and then they add it, and then it leads to bad stuff happening.
4. There is no use for the first block example I gave because it would do nothing, and the other one would be useful because it would report the pen color value.

For MegaByteCorporations:
1. I never said that you should not give a reason.
2. What do you mean?
3. But the Scratch Team could accidentally add a bad idea. Just say it nicely.

For jokebookservice1:
1. What's wrong with telling the consequences?
4. How would that ignore code block be helpful?
(I skipped 2 and 3 because I didn't have anything to say.)

I think the scratch team tests all these things first to make sure they work and how would it be different if they added something from their own ideas there could be a bug then?

Ziggy741 wrote:

For Sigton:
1. I never said that you should not give a reason.
2. You're not supposed to support/semi-support/no support without a reason.
3. The Scratch Team could think that an idea is good, and then they add it, and then it leads to bad stuff happening.
4. There is no use for the first block example I gave because it would do nothing, and the other one would be useful because it would report the pen color value.

For MegaByteCorporations:
1. I never said that you should not give a reason.
2. What do you mean?
3. But the Scratch Team could accidentally add a bad idea. Just say it nicely.

For jokebookservice1:
1. What's wrong with telling the consequences?
4. How would that ignore code block be helpful?
(I skipped 2 and 3 because I didn't have anything to say.)

1. I said that you should explain the consequences, something that No supporting doesn't really aid.

4. If a part of your code is buggy then you can try running your project without a piece of code, and its distinct colour helps you find that code

powercon5 wrote:

Ziggy741 wrote:

For Sigton:
1. I never said that you should not give a reason.
2. You're not supposed to support/semi-support/no support without a reason.
3. The Scratch Team could think that an idea is good, and then they add it, and then it leads to bad stuff happening.
4. There is no use for the first block example I gave because it would do nothing, and the other one would be useful because it would report the pen color value.

For MegaByteCorporations:
1. I never said that you should not give a reason.
2. What do you mean?
3. But the Scratch Team could accidentally add a bad idea. Just say it nicely.

For jokebookservice1:
1. What's wrong with telling the consequences?
4. How would that ignore code block be helpful?
(I skipped 2 and 3 because I didn't have anything to say.)

I think the scratch team tests all these things first to make sure they work and how would it be different if they added something from their own ideas there could be a bug then?

What do you mean?

MasterJPixel wrote:

Can you go ahead and remove my quote? I find the use of it disrespectful.

I'd kept it anonymous so if you hadn't made that comment no-one would've known it was you

Sigton

Ziggy741 wrote:

powercon5 wrote:

Ziggy741 wrote:

For Sigton:
1. I never said that you should not give a reason.
2. You're not supposed to support/semi-support/no support without a reason.
3. The Scratch Team could think that an idea is good, and then they add it, and then it leads to bad stuff happening.
4. There is no use for the first block example I gave because it would do nothing, and the other one would be useful because it would report the pen color value.

For MegaByteCorporations:
1. I never said that you should not give a reason.
2. What do you mean?
3. But the Scratch Team could accidentally add a bad idea. Just say it nicely.

For jokebookservice1:
1. What's wrong with telling the consequences?
4. How would that ignore code block be helpful?
(I skipped 2 and 3 because I didn't have anything to say.)

I think the scratch team tests all these things first to make sure they work and how would it be different if they added something from their own ideas there could be a bug then?

What do you mean?

Well when the scratch team gets a suggestion I think they would think about problems it would cause and if they did it they would make sure it is tested first and even if it had bugs they would fix them.

And the scratch team would add their own ideas and they would not have people tell the problems they would test it for themselves.

You should also add more to the first suggestion by not making quote trains, like so:

user4 wrote:

user3 wrote:

user2 wrote:

user1 wrote:

This would be very useful! I hope this gets added!

As per this.

^^^

…Because you're not adding to the discussion, rather, you are copying what others have said.

alexphan wrote:

You should also add more to the first suggestion by not making quote trains, like so:

-Snip-

…Because you're not adding to the discussion, rather, you are copying what others have said.

I'll just add that as another suggestion

Sigton

Sigton wrote:

MasterJPixel wrote:

Can you go ahead and remove my quote? I find the use of it disrespectful.

I'd kept it anonymous so if you hadn't made that comment no-one would've known it was you

Sigton

I knew who it was and I dislike it's use, anonymous or not. Please remove it.

@alexphan
I've added your input
See? building on ideas ;)

Sigton