Add more support materials for contributors #924
+867
−59
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This adds much more information about this project's conventions, development process, and contributor workflow.
This sets the default style (to Google style), so that `clang-format` can be invoked with the style argument.
This sets the default style (to Google style), so that `yapf` can be invoked with the style argument.
The content here is currently all about adjusting GitHub's file type statistics. (IMHO it's weird that GitHub doesn't list Markdown files.)
This configures the linter program `actionlint` for this project. It helps to have this when making changes to the GitHub Actions workflows.
These help improve visibility of errors in CI.
mhucka
added
area/docs
In preparation for a separate PR to do nothing but reformat a few files, this adds information telling developers how to configure git to ignore specific commits. (This is the same approach used in Cirq.) This also adds a placeholder `.git-blame-ignore-revs` file for now, so that running the git config command does not result in an error.
Thanks to Pablo Samano Elton for catching that.
MichaelBroughton
requested changes
Dec 12, 2025
Collaborator
MichaelBroughton
left a comment
MichaelBroughton
left a comment
There was a problem hiding this comment.
Thanks for working on this. I don't think we can merge this PR as is. There are too many changes at once in a single PR. I see the git-blame-ignore-revs stuff is in here again, which I don't think we want. It looks like there is a whole bunch of other linting and styling changes going on here that are hard to track where they come from and how it all fits together on top of all of the changes to .md files. Could you please split this into smaller focused PRs ?
Would also recommend reading go/prefer-small-cls for some general guidelines when splitting things up.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds information about project conventions and workflows to
CONTRIBUTING.md, and in support of that, also adds configuration files for more linters and formatters.The biggest change is to
CONTRIBUTING.md, which is now greatly expanded. It includes more "getting started" type guidance, plus developer processes, and coding conventions. Where possible, this references other documentation in TensorFlow or TensorFlow Quantum.The remaining changes are to help developers get the right settings for some commonly-used programs, add GitHub problem matchers for more of the programs used in CI, and add a couple of files that are standard these days:
Add configuration files for some linters and formatters relevant to this project. Not only can users run, e.g.,
clang-format /path/to/some/fileand it will use the correct format without the user having to remember to add a style parameter; program config files are recognized by some editing tools to help developers get immediate feedback while they're editing. (E.g., Emacs has such tooling.)Add more problem matchers to help surface errors in CI by taking advantage of the GitHub problem matchers feature
Add a code of conduct and a standard project
SUPPORT.mdfile.