Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New page in docs: "Rejected Addon Ideas" #314

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
48 changes: 48 additions & 0 deletions content/docs/develop/getting-started/rejected-addon-ideas.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,48 @@
---
title: Rejected Addon Ideas
description: (TODO)
weight: 4
---

<!-- Introduction TODO -->

Below there's a list of some reasons why we've rejected addons in the past.

Please note that these are general rules. Feature ideas are considered in a case-by-case basis.


## Features not specific to Scratch

If a general-purpose extension can be developed to achieve the exact same result in the Scratch website, it's likely that the addon idea will be rejected.

Some examples of rejected ideas:
- Convert Unicode emojis to Twemoji
- Always open links in a new tab
- Applying some CSS to all elements on the page, without any Scratch-specific selectors/logic


## Features that could be implemented as a website first

Some features don't strictly need any extension capabilities. Implementing them as websites first benefits the whole Scratch community, and specially students that cannot download extensions to their devices.

If a website already exists, the developer community can consider whether it makes sense to integrate it as an addon or not.

Some examples of features that could be implemented as websites:
- Displaying public data from a user, such as their profile statistics
- Letting users choose a status and seeing other people's


## Non-urgent vanilla Scratch bug fixes

When a bug is reported to the Scratch Team, we generally give them enough time to fix it for all users. If possible, Scratch Addons contributors should send a pull request directly to Scratch's GitHub repository. Only if enough time has passed without it being merged, we should consider creating a new addon that fixes the bug.


## Unnecessarily using external libraries, services or REST APIs

If possible, all computation should happen on the client's machine for privacy reasons.

This restriction does not include the Scratch website or its REST API.

Some examples of rejected implementations:
- Calling a server that computes project statistics with a project JSON file
- Using an hypotetical image service to show a Scratcher's profile picture by providing their username instead of their user ID