You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 20, 2023. It is now read-only.
During times of high commit volume like Hacktoberfest, or when the stars align against you, someone else may be working on updating the same pixel as you are. With a generic recommended commit message, you need to dig into every open PR to view the file changes in order to check what pixels were changed in the open PRs that are ahead of yours.
Proposed solution
The contributing guidelines give specific instructions to add your commit with the message feat(pixels): add my new pixel., following the Conventional Commits Standard. By adding your claimed pixel to the commit message (and, therefore, your automatic PR title), one can easily do a visual scan of the PRs waiting to be merged to make sure they aren't about to try to change a pixel that will soon be merged and cause a conflict. For example, feat(pixels): add my new pixel (8, 27). This solution would be loosely implemented by updating that section of the docs.
Thank you so much for opening your first issue for this project! We'll try to get back to it as quickly as possible. While you are waiting...here's a random picture of a corgi (powered by dog.ceo)
The Issue
During times of high commit volume like Hacktoberfest, or when the stars align against you, someone else may be working on updating the same pixel as you are. With a generic recommended commit message, you need to dig into every open PR to view the file changes in order to check what pixels were changed in the open PRs that are ahead of yours.
Proposed solution
The contributing guidelines give specific instructions to add your commit with the message
feat(pixels): add my new pixel.
, following the Conventional Commits Standard. By adding your claimed pixel to the commit message (and, therefore, your automatic PR title), one can easily do a visual scan of the PRs waiting to be merged to make sure they aren't about to try to change a pixel that will soon be merged and cause a conflict. For example,feat(pixels): add my new pixel (8, 27).
This solution would be loosely implemented by updating that section of the docs.Somewhat related to #340
The text was updated successfully, but these errors were encountered: