committedteam / commitcanvas Goto Github PK

• I have searched the issues of this repo and believe that this is not a duplicate.
• I have read the README.md and believe that my question is not covered.

Issue

To make CommitCanvas more flexible for the users, it should have a feature that lets the users add their own checks or disable the existing checks.

• I have searched the issues of this repo and believe that this is not a duplicate.
• I have read the README.md and believe that my question is not covered.

Issue

CommtiCanvas should have a feature that also supports conventional commits syntax. Conventional commits are quite popular as they help with creating explicit commit history, therefore the users of CommitCanvas would benefit from the feature that also enforces conventional commits rules. (please see the link for more information.)

• I have searched the issues of this repo and believe that this is not a duplicate.
• I have read the README.md and believe that my question is not covered.

Issue

The current version of the documentation mentions that CommitCanvas operates in
both a project-specific and a project-agnostic mode. However, the distinctions
between these two modes is not clear after reading the documentation. As such,
it would be beneficial for the README file to include more details about when a
developer would pick one mode over the other. If possible, the README should
also include some information about the performance of the different modes.
Finally, the documentation should reflect the correct model that is used in the
project-agnostic mode for CommitCanvas.

• I have searched the issues of this repo and believe that this is not a duplicate.
• I have read the README.md and believe that my question is not covered.

Issue

It is great that this project already has a CONTRIBUTING.md file. However, it
would be great if we can extend this file so that it includes details about the
development workflow that we follow on this project. For instance, it would be
helpful to contributors if they knew that we followed the GitHub flow model. It
would also be helpful if the CONTRIBUTING.md file gave more details about the
commit message standard that is followed by the developers of CommitCanvas.

• I have searched the issues of this repo and believe that this is not a duplicate.
• I have read the README.md and believe that my question is not covered.

Issue

The current version of the Installation section does not explain that
CommitCanvas uses Python to perform the operations of the pre-commit hook. As
such, the README file should be enhanced by first explaining the dependency on
Python. Second, the README should provide basic instructions on how to install
Python, providing references to external documentation when appropriate. While I
acknowledge that the existing documentation does include this:

minimum_pre_commit_version: 1.21.0
repos:

# check with commitcanvas.
- repo: https://github.com/CommittedTeam/CommitCanvas
  rev: the revision or tag to clone at
  hooks:
    - id: commitcanvas
      language_version: python3.7
      language: python
      stages: [prepare-commit-msg]

and that does mention python3.7 I think that this dependency needs to be made
more explicit.

• I have searched the issues of this repo and believe that this is not a duplicate.
• I have read the README.md and believe that my question is not covered.

Issue

Although the README does include the following list of features:

• Separate subject from body with a blank line
• Do not end the subject line with a period
• Capitalize the subject line and each paragraph
• Use the imperative mood in the subject line
• Wrap subject line at 72 characters
• automatically attach the conventional commit label to the commit message

The documentation does not give an example of a commit message that does not
satisfy the standard and then another commit messages that does satisfy the
standard. Providing this type of data would make it easier for a developer to
see the benefits associated with using CommitCanvas.

• I have searched the issues of this repo and believe that this is not a duplicate.
• I have read the README.md and believe that my question is not covered.

Issue

The README file should also refer to
https://github.com/CommittedTeam/commitcanvas-models and explain that this
repository also includes details about the experiments conducted with
CommitCanvas, the results of those experiments, the details about the training
pipeline, and the instructions for downloading and using trained models. This
type of information will be valuable to researchers who want to extend the tool
or replicate an experimental analysis of CommitCanvas.

• I have searched the issues of this repo and believe that this is not a duplicate.
• I have read the README.md and believe that my question is not covered.

Issue

Other than checking the syntax of the commit message, it would be very helpful for the users if CommitCanvas had a feature that predicts if the commit is likely to break the build before the commit gets pushed to Github.

• I have searched the issues of this repo and believe that this is not a duplicate.
• I have read the README.md and believe that my question is not covered.

Issue

CommitCanvas uses a pre-trained Spacy language model, which may not be very successful with detecting non-imperative mood. Specifically, it sometimes takes a verb in imperative mood as a noun. To resolve this issue it might be helpful to train or update the Spacy language model with commit messages. So that model is trained specifically for the commit message language.

• I have searched the issues of this repo and believe that this is not a duplicate.
• I have read the README.md and believe that my question is not covered.

Issue

It would be easier and more "predictable" if the README included an example of
how to install and run CommitCanvas as a pre-commit hook for an existing
repository. This would make it possible for a person who wants to learn how to
use the tool to try it out and to produce the expected labels for commits and to
see the rule violations for the commits. Without this type of documentation in
the README file, each individual will have a different experience when they
first try out the tool, perhaps leading them to decide that it does not work
well. While I acknowledge that the ultimate success or failure of the tool
depends on whether it runs well for a person's own repositories, it is worth
having a comprehensive example showing how it works on a specific repository.