DOCS: Stop requiring every commit to reference an issue
See original GitHub issue@jbrockmendel mentioned in #4885 that this requirement is painful. @vnlitvinov asked here whether we should keep the requirement.
Similar projects pandas, vaex, dask, and polars do not seem to have this requirement.
I vote for relaxing this requirement but still requiring commits to start with one of an allowed set of prefixes, currently {"FEAT", "DOCS", "FIX", "REFACTOR", "TEST", "PERF"}
. The contributing guidelines should say that if the PR fixes an existing relevant issue, the commit message should include that issue’s number.
@modin-project/modin-contributors @modin-project/modin-core please share your thoughts.
Issue Analytics
- State:
- Created a year ago
- Comments:7 (7 by maintainers)
Top Results From Across the Web
Push rules - GitLab Docs
This push rule requires a Signed-off-by: trailer in every commit message, and rejects any commits that lack it. Validate branch names. To validate...
Read more >Events that trigger workflows - GitHub Docs
Runs your workflow when someone deletes a Git reference (Git branch or tag) in the workflow's repository. For information about the APIs to...
Read more >Dockerfile reference - Docker Documentation
A Dockerfile is a text document that contains all the commands a user could call on the command line to assemble an image....
Read more >git-commit Documentation - Git
by listing files as arguments to the commit command (without --interactive or --patch switch), in which case the commit will ignore changes staged...
Read more >Best practices for Cloud Firestore - Firebase
Keep the rate of documents the database pushes to all clients under 1,000,000 documents/second. This is a soft limit. Cloud Firestore does not...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
What I would like to actually do is to keep the same logic we were doing as regular contributors (i.e. creating issues for tracking purposes etc), but do not require these issues to be created by external contributors.
In my opinion, accepting some random external contribution should be as frictionless as possible.
I agree with @vnlitvinov - that way we don’t have to have a complicated set of rules for whose commits are formatted in a specific way for which people, but our commits (on master) are still nicely formatted!