How to Contribute
We'd love to accept your patches and contributions to XLS. We recommend filing an issue for back-and-forth discussion on implementation strategy before sending a PR. Also, note the community guidelines below.
This project follows Google's Open Source Community Guidelines.
Contributor License Agreement
Contributions to this project must be accompanied by a Contributor License Agreement (CLA). You (or your employer) retain the copyright to your contribution; this simply gives us permission to use and redistribute your contributions as part of the project. Head over to https://cla.developers.google.com/ to see your current agreements on file or to sign a new one.
You generally only need to submit a CLA once, so if you've already submitted one (even if it was for a different project), you probably don't need to do it again.
When writing code contributions to the project, please make sure to follow the style guides: The Google C++ Style Guide and the Google Python Style Guide. There are a few small XLS clarifications for local style on this project where the style guide is ambiguous.
All submissions, including submissions by project members, require review. We use GitHub pull requests for this purpose. Consult GitHub Help for more information on using pull requests.
Pull Request Style
We ask contributors to squash all the commits in the PR into a single one, in order to have a cleaner revision history.
Specifically, when you initially send a PR, please ensure it has a single commit. If you'd like to address review comments by adding commits,1 please be sure to squash them into one again once the PR is approved (though squashing continuously is also acceptable).
Generally, squashing to a single commit can be accomplished by:
proj/xls$ # Here we assume origin points to google/xls. proj/xls$ git fetch origin main proj/xls$ git merge-base origin/main my-branch-name # Tells you common ancesor COMMIT_HASH. proj/xls$ git reset --soft $COMMIT_HASH proj/xls$ git commit -a -m "My awesome squashed commit message!!!1" proj/xls$ # Now we can more easily rebase our squashed commit on main. proj/xls$ git rebase origin/main
Rebased branches can be pushed to their corresponding PRs with
See also this Stack Overflow question.
proj/xls$ mkvirtualenv xls-mkdocs-env proj/xls$ pip install mkdocs-material mkdocs-exclude mdx_truly_sane_lists proj/xls$ mkdocs serve
This will start a local server that you can browse to and that will update the documentation on the fly as you make changes.
Note that the
mkvirtualenv command assumes you're using
to manage your Python environment. You'll need to adjust these instrutions if
you're doing something different. That can include explicitly adding
your path, if locally installed Python binaries aren't available by default.
DSL snippets in documentation
There are a few different language annotations we use in different circumstances in the Markdown docs:
dslx: A full code block that should be parsed/typechecked/tested.
dslx-snippet: A fragment that should be syntax highlighted, but not parsed/typechecked/tested.
dslx-bad: An example of something that we expect to produce an error when parsing/typechecking/testing.
GitHub issue google/xls#378 tracks a script that does the parse/typecheck/test that ensures our documentation is up to date and correct.
GitHub Issue "T-Shirt Size" Estimate Labels
We attempt to employ some lightweight processes for task size estimation for the GitHub issues in the XLS repository, as a way of making tasks available that fit for available development time as well as gut checking, if something takes longer than we expected, why and can we do things to mitigate the surprising amount of time required going forward.
There's a practice of marking issues with "t-shirt sizes" for development tasks. An issue can be XS, S, M, L, XL, these are given in the "estimate" labels:
|eXtra Small||XS||~few hours|
These are not "load bearing", just to note expectation. Generally the assumption is "time expected for a person familiar with this matter / part of the code base", so developers that would ramp on an issue would require more time than is indicated by the label. Feel free to change the label at will, ideally by providing a helpful explanation for why/how the estimate came to change.
Adding commits preserves the GitHub code review history and makes it easier to review incremental changes, but causes an additional "round trip" with the reviewer for the final squash after approval, so there is a small procedural tradeoff. ↩