-
-
Notifications
You must be signed in to change notification settings - Fork 96
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
Create a tracker issue for typos and paper cuts #9648
Comments
I think this is a great idea. I often come across typoed, weird or even misleadingly named variables, blocks of code which purpose needs a cup to coffee to understand what's its purpose (lacking helpful comments) etc. but don't bother doing anything with them. If there was a tracker for these small things maybe I would start collecting and submitting them. Maybe there could be a bot which would analyze incoming pull requests and automatically notify the author that there's small issues around the edited code if they are catalogued in the tracker. |
We shouldn't change code unrelated to PRs unless it's strictly non-functional, i.e. style Functional changes should always be in a dedicated PR to make it manageable to track issues from it |
I wonder if such a bot already exists. Creating one from scratch seems like more effort than it's worth I feel. Also Godot doesn't use any GitHub bots yet, so this would need a consensus by the maintainers first.
Do you consider any of the three things the issue should track to be functional changes? I could clarify the proposal wording. I wouldn't accept renaming public API as a change, but e.g. local variables or private fields would be fine. General "rename things for fun/consistency" should be forbidden too - it should explicitly be for things that are named wrongly. |
Even something as simple as reordering a loop would IMO be cause to make a dedicated PR, as it can cause unforseen issues |
@AThousandShips I updated the proposal to make it clear that changes should be limited to style changes. I totally agree that refactors should not count here, so I clarified "paper cut -> UI paper cut" as well. Let me know if the wording can be improved further. |
Since it generally seems like there is interest in this, I've created godotengine/godot#91521 as the tracker issue. Feel free to contribute typos/papercuts you're aware of, either by editing the issue directly (for maintainers) or by commenting. If the maintainers deem this unnecessary or want to tackle the problem differently, feel free to close the tracker issue. |
Describe the project you are working on
Godot Engine GitHub Issues
Describe the problem or limitation you are having in your project
Whenever a user finds a typo or a UI paper cut in the Godot code, they are told not to fix it as a standalone PR, since it would clutter the PRs. So instead they're told to bunch together a lot of issues, then fix them in one go - or fix them as part of a larger refactoring or feature.
However, as it's unlikely that many users are willing to do more work than intended, these issues just die out and the typo or UI paper cut persists.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Create a tracker issue in the Godot repository that keeps track of tiny issues which can easily be fixed and are not opinionated changes. This includes:
No functional changes are tracked here, so no refactoring, reordering code.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
Users can request entries by posting comments, where they will be collected in the tracker issue's description. A code location should be provided as well (not pointing to latest master, but rather to the currently latest commit hash).
Fixes from the list can be applied in following cases:
If this enhancement will not be used often, can it be worked around with a few lines of script?
N/A
Is there a reason why this should be core and not an add-on in the asset library?
N/A
The text was updated successfully, but these errors were encountered: