Skip to content

New "bugfix" tag for addons - #4515

Closed
Norbiros wants to merge 3 commits into
ScratchAddons:masterfrom
Norbiros:bugfix-tag
Closed

New "bugfix" tag for addons#4515
Norbiros wants to merge 3 commits into
ScratchAddons:masterfrom
Norbiros:bugfix-tag

Conversation

@Norbiros

@Norbiros Norbiros commented Apr 19, 2022

Copy link
Copy Markdown
Contributor

Resolves #2568 (comment)

Changes

Adds new tag to addons: don't run duplicated blocks and fix SVG upload
file

Tests

Firefox newest.

Merge before: ScratchAddons/manifest-schema#59

@Norbiros

Norbiros commented Apr 19, 2022 via email

Copy link
Copy Markdown
Contributor Author

@Samq64

Samq64 commented Apr 19, 2022

Copy link
Copy Markdown
Member

Okay, added.

I didn't mean to post that review.

@cobaltt7

Copy link
Copy Markdown
Contributor

Okay, added.

I didn't mean to post that review.

it does sound better tho tbh

Comment thread webpages/settings/data/addon-groups.js
Comment thread addons/block-duplicate/addon.json Outdated
@WorldLanguages

Copy link
Copy Markdown
Member

@mxmou @lisa-wolfgang What do you think about this PR?

I'm unsure. We don't allow users to list/filter addons with a tag, so should we create an addon group dedicated to addons that fix Scratch bugs? Enabled, recommended, bugfixes(?), featured, forums, others, beta?
How can we explain "this addon fixes a Scratch bug" with fewer words? Can't "bug fix" be confused with an addon we made that had a bug, then we fixed our bug?

@lisa-wolfgang

Copy link
Copy Markdown
Member

I like the idea of having an addon group without showing the tag on each addon, like what we do for featured addons. Like W_L said, putting the tag directly on the addon in a similar manner as the "updated" tag implies that we're fixing our own bugs, but a group has a more permanent connotation, especially since it would be distanced from the "new addons and updates" sections.

However, what I'd like even more is for these addons to be enabled by default. I know that it's been a challenge to come up with a universal solution for indicating our modifications, but I don't think that's the best way to think about it. Every addon is different and will need its own indication, so such a system will need to be flexible. Therefore, I'd suggest the following implementation:

  • fix-pasted-scripts: the first time the user performs a duplicate or paste action, show a popup near the code editor that says something to the effect of "hey, we made it so that putting that block on another one doesn't run them anymore."
  • fix-uploaded-svgs: the first time the user uploads an SVG file, show a popup near the costume editor that says something to the effect of "hey, we made it so that SVG files upload properly."
  • fix-editor-comments: since the user may have been deterred from using comments in Scratch at all, the first time the user creates a block, show a popup near the code editor that says something to the effect of "hey, we made it so that comments actually move with blocks they're attached to."

@cobaltt7

Copy link
Copy Markdown
Contributor

How can we explain "this addon fixes a Scratch bug" with fewer words? Can't "bug fix" be confused with an addon we made that had a bug, then we fixed our bug?

I think the tag should be called "bug fix" with a tooltip "this addon fixes a Scratch bug"

@lisa-wolfgang

Copy link
Copy Markdown
Member

How can we explain "this addon fixes a Scratch bug" with fewer words? Can't "bug fix" be confused with an addon we made that had a bug, then we fixed our bug?

I think the tag should be called "bug fix" with a tooltip "this addon fixes a Scratch bug"

That doesn't solve the issue of being confusable with our own bugs. Tooltips aren't reliable enough.

@WorldLanguages

Copy link
Copy Markdown
Member

However, what I'd like even more is for these addons to be enabled by default.

I think discussing that is out of scope for this PR, maybe we can create an issue?

@lisa-wolfgang

Copy link
Copy Markdown
Member

If we go ahead with this PR, it would make sense to have a "feature" tag as well, since there's already a tag for themes.

@mxmou

mxmou commented Jun 27, 2022

Copy link
Copy Markdown
Member

If we go ahead with this PR, it would make sense to have a "feature" tag as well, since there's already a tag for themes.

I don't think that would be very useful - almost every addon would have the tag.

@WorldLanguages

Copy link
Copy Markdown
Member

I think we should have an open discussion about the settings page as a whole and deal with this as well as #3955 at the same time 🤔

@cobaltt7

cobaltt7 commented Oct 11, 2022 via email

Copy link
Copy Markdown
Contributor

@Samq64 Samq64 added the scope: webpages Related to the web pages (settings page, pop-up, etc) label Dec 18, 2022
@Samq64 Samq64 added the status: needs discussion Still in review or consideration label Jul 3, 2023
@Samq64 Samq64 added the status: pending A PR is still not ready to merge, or an issue is being worked on/on consideration label Jul 25, 2023
@Samq64 Samq64 removed the status: pending A PR is still not ready to merge, or an issue is being worked on/on consideration label Feb 3, 2024
@Samq64 Samq64 mentioned this pull request Mar 3, 2024
3 tasks
@Samq64 Samq64 added status: abandoned PR is no longer being actively worked on and removed status: needs discussion Still in review or consideration labels Jun 17, 2024
@Samq64

Samq64 commented Jul 18, 2024

Copy link
Copy Markdown
Member

Should this be closed in favour of #7242?

@WorldLanguages

Copy link
Copy Markdown
Member

Okay, let's focus on that one instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

scope: webpages Related to the web pages (settings page, pop-up, etc) status: abandoned PR is no longer being actively worked on

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants