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

Add quality guidelines page #219

Open
wants to merge 12 commits into
base: master
Choose a base branch
from

Conversation

lisa-wolfgang
Copy link
Member

@lisa-wolfgang lisa-wolfgang commented Jul 18, 2022

This PR adds quality guidelines for PRs to the main extension repo.

Since the addon compatibility checklist will be a large undertaking, it will be PRed separately.

@Samq64
Copy link
Member

Samq64 commented Jul 19, 2022

I think creating-an-addon.md needs to be re-done, but I'm not sure if that should go in this PR.

@lisa-wolfgang
Copy link
Member Author

This PR should be for new docs content related to the overhauled PR merge system in ScratchAddons/ScratchAddons.

@lisa-wolfgang lisa-wolfgang added help wanted Extra attention is needed scope: docs Related to the documentation (Scratch Addons Docs) labels Jul 19, 2022
@lisa-wolfgang
Copy link
Member Author

lisa-wolfgang commented Jul 19, 2022

The addon compatibility list will be a relatively large undertaking. Contributions from those experienced in specific areas of the website and editor would be greatly appreciated. See #225

@Hans5958 Hans5958 added the type: enhancement New feature or request label Jul 20, 2022
@lisa-wolfgang lisa-wolfgang changed the title Add quality guidelines and addon compatibility checklist Add quality guidelines page Jul 21, 2022
@lisa-wolfgang lisa-wolfgang removed the help wanted Extra attention is needed label Jul 21, 2022
@lisa-wolfgang lisa-wolfgang marked this pull request as ready for review July 21, 2022 02:02
@lisa-wolfgang
Copy link
Member Author

lisa-wolfgang commented Aug 2, 2022

It might be a good idea to require approvals to be accompanied by a checklist (as a comment on the approval) that we provide on this page. That way, the person approving the PR communicates exactly what they've looked at.

@lisa-wolfgang
Copy link
Member Author

There hasn't been any additional feedback on these guidelines for a while, so I'm going to assume that they're final for the time being. However, to have any actual bearing on the PR approval process, org members will need to become familiar (and agree) with these guidelines.

@WorldLanguages @apple502j @GarboMuffin @GrahamSH-LLK @Hans5958 @jeffalo @mxmou @RedGuy12 @TheColaber @Weredime Please either mark your approval of these guidelines (by approving the PR) or leave a review requesting changes.

All PRs:
- should have sound reasoning as to why they should be merged. This should be specified under the "Reason for changes" header when writing the PR description. Even if it seems obvious, others may need the additional context. PRs with little to no reason to be merged are likely to be delayed, ignored, or even closed.
- must support both the Chromium and Firefox browser engines. Avoid using new or experimental web technologies unless a fallback is implemented that preserves feature parity. View the [unsupported browser](https://scratchaddons.com/unsupported-browser/) page to determine the current minimum versions that must be supported.
- must be tested thoroughly. We have a very large userbase, so it's especially important that all possible use cases are considered. Every PR should be tested on a Chromium-based browser (Chrome, Edge, Brave, or another) **and** Firefox. Any tests done should be added to the "Tests" section of the PR description. **Org members, this is required in order to give approval.**
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if you don't have access to the other browser yourself? What should the PR author or reviewers do in that case?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps testing on both browsers could be a requirement for approving a PR but not for opening one.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I meant on this point was what Maximouse said.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewers can still give good feedback if they don't have access to both browsers, but full approval should require a thorough evaluation, and that can't happen if one of our supported browsers hasn't been tested.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

alr so i'm never approving prs again
got it 👍🏻

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed on making it a recommendation.

Copy link
Member

@DNin01 DNin01 Jan 20, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it can be helpful sometimes. For complex changes or changes to important parts of Scratch Addons like the settings page, I think we should request testing on Firefox before merging, but right now, we may not need to do that for everything.

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as resolved.

- should be reviewed by someone familiar with the aspects that the PR is changing. This isn't a hard requirement, but a person like this will help iron out edge cases and minor issues.

New addons:
- must have clear, concise, and easy-to-understand titles, descriptions, info notices (if any), and setting names (if any). English is required: the base addon manifest is used as a reference for our translators. The developers and members of the community should scrutinize and help with this. An effective meter for this is to test it **blindly** -- that is, download and try out the addon before reading the PR description.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Specify American English?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, IIRC we have a page somewhere for often used names of Scratch pages and features, can we link that here?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO, we should have a dedicated page about this, instead of linking to the "description" section of the addon manifest reference. In the meanwhile however, we could link to that.

- must have clear, concise, and easy-to-understand titles, descriptions, info notices (if any), and setting names (if any). English is required: the base addon manifest is used as a reference for our translators. The developers and members of the community should scrutinize and help with this. An effective meter for this is to test it **blindly** -- that is, download and try out the addon before reading the PR description.
- must be easy to use. The labels and design language used in any UI that the addon adds or modifies should be understandable by whoever will be using that addon. Again, testing blindly is an effective meter for this. Addons without an effective UI communicating its changes will be ranked lower than other addons in the settings page.
- must be compatible with our existing addons. This doesn't just mean avoiding bugs: addons should complement each other by supporting each other's features. For example, an addon that has a user interface should support our respective dark mode addon.
- must work without any other addons enabled.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- must work without any other addons enabled.
- must also work without any other addons enabled.

to avoid confusion with the line above

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding "also" seems okay to me

<!-- The following checklist items apply to all PRs. -->
[] Valid reason to merge
[] To the best of my knowledge, supports all browsers supported by the extension
[] I personally tested all features in both a Chromium-based browser and Firefox
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto from above
Many people, including me, do not have access to another browser for any number of reasons. if we make it a requirement to test on both, I know I for one will not be making or reviewing any more PRs, and I'm sure many others won't either.

Copy link
Member

@Hans5958 Hans5958 Oct 19, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather have this as a recommendation, and not a strict requirement. 90% of the case it will work on both browsers, so it is not something of a priority. At least that's on me.

See message on #219 (comment)

content/docs/reference/quality-guidelines.md Show resolved Hide resolved
[] I personally found the addon to be easy to use during my testing
[] I personally tested with all other addons and features enabled and did not find compatibility issues
[] I personally tested with no other addons enabled and did not find issues
[] The addon is well-integrated with other addons
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Most addons don't need special changes when other addons are toggled...I think the line two above covers this.

Suggested change
[] The addon is well-integrated with other addons

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe that could be clarified with "if appropriate".

@cobaltt7
Copy link
Contributor

cobaltt7 commented Oct 3, 2022

It may be a good idea to ask contributors to join the Discord server or at least create an issue for discussion about PRs before creating them -- often times people try to make rejected or very complex addons as their first PR.

@Hans5958
Copy link
Member

Hans5958 commented Oct 7, 2022

It may be a good idea to ask contributors to join the Discord server or at least create an issue for discussion about PRs before creating them -- often times people try to make rejected or very complex addons as their first PR.

I'd rather have a focus to create an issue compared to joining the Discord server.

@@ -8,7 +8,7 @@ Keep these guidelines in mind when creating or reviewing a pull request (PR). If
All PRs:
- should have sound reasoning as to why they should be merged. This should be specified under the "Reason for changes" header when writing the PR description. Even if it seems obvious, others may need the additional context. PRs with little to no reason to be merged are likely to be delayed, ignored, or even closed.
- must support both the Chromium and Firefox browser engines. Avoid using new or experimental web technologies unless a fallback is implemented that preserves feature parity. View the [unsupported browser](https://scratchaddons.com/unsupported-browser/) page to determine the current minimum versions that must be supported.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

View the unsupported browser page to determine the current minimum versions that must be supported.

I'd rather link https://scratchaddons.com/docs/getting-started/installing/ instead of that page.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed!

@WorldLanguages
Copy link
Member

We should try to get this merged sometime soon, even if it's not 100% perfect. We can always tweak it later.

Copy link
Member

@Hans5958 Hans5958 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Putting my early approval here. Changes may still made, but I won't merge it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe mention not affecting non-SA users here?

Copy link
Member

@WorldLanguages WorldLanguages Mar 19, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Related: ScratchAddons/ScratchAddons#5830

I'm not sure if a list of reasons to reject an addon belongs here. Would need to think about it

Copy link
Member

@WorldLanguages WorldLanguages Mar 21, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Update: ScratchAddons/ScratchAddons#5830 (comment)
I believe the list of reasons can become its own doc page. We could add a check/mention here that links to that page, after we create the page

This comment was marked as outdated.

@Hans5958
Copy link
Member

Hans5958 commented May 1, 2023

Bump to have fresh ideas

@Samq64
Copy link
Member

Samq64 commented May 1, 2023

https://scratchaddons.com/docs/develop/userscripts/best-practices/ exists now and there will probably be a similar page for userstyles in the future, so we should probably link those.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm glad that we have reviews from people like mxmou that are so thorough. I know, no one likes having PRs held back due to reviews, but having stricter guidelines for reviewers to follow would make thorough reviews more valuable and could result in more problems being fixed.

- should have sound reasoning as to why they should be merged. This should be specified under the "Reason for changes" header when writing the PR description. Even if it seems obvious, others may need the additional context. PRs with little to no reason to be merged are likely to be delayed, ignored, or even closed.
- must support both the Chromium and Firefox browser engines. Avoid using new or experimental web technologies unless a fallback is implemented that preserves feature parity. View the [unsupported browser](https://scratchaddons.com/unsupported-browser/) page to determine the current minimum versions that must be supported.
- must be tested thoroughly. We have a very large userbase, so it's especially important that all possible use cases are considered. Every PR should be tested on a Chromium-based browser (Chrome, Edge, Brave, or another) **and** Firefox. In addition, both LTR and RTL language modes should be supported. Any tests done should be added to the "Tests" section of the PR description. **Org members, this is required in order to give approval.**
- must have **all** code reviewed line-by-line. **Org members, this is required in order to give approval.**
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this would be ideal, but larger PRs already sometimes sit there for months because no org member wants to tackle reviewing a few thousand lines of code. I know large PRs can usually be split, but it's not always possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
scope: docs Related to the documentation (Scratch Addons Docs) type: enhancement New feature or request
Projects
Status: Long Term
Development

Successfully merging this pull request may close these issues.

8 participants