-
Notifications
You must be signed in to change notification settings - Fork 39
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
base: master
Are you sure you want to change the base?
Conversation
I think |
This PR should be for new docs content related to the overhauled PR merge system in ScratchAddons/ScratchAddons. |
- Navbar - Editor (general) - Stage header
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 |
It will get its own PR
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. |
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.** |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 👍🏻
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
- 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Specify American English?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- must work without any other addons enabled. | |
- must also work without any other addons enabled. |
to avoid confusion with the line above
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)
[] 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 |
There was a problem hiding this comment.
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.
[] The addon is well-integrated with other addons |
There was a problem hiding this comment.
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".
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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed!
We should try to get this merged sometime soon, even if it's not 100% perfect. We can always tweak it later. |
There was a problem hiding this 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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
This comment was marked as outdated.
Sorry, something went wrong.
Bump to have fresh ideas |
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. |
There was a problem hiding this comment.
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.** |
There was a problem hiding this comment.
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.
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.