Contributing
The star-tex
projects eagerly accepts contributions from the community.
Introduction
The star-tex
project provides libraries and tools in Go to apply TeX typesetting quality algorithms, and we would like you to join us in improving star-tex
’s quality and scope.
This document is for anyone who is contributing or interested in contributing.
Questions about star-tex
or the use of its libraries can be directed to the star-tex mailing list.
Contributing
Working Together
When contributing or otherwise participating, please:
- Be friendly and welcoming
- Be patient
- Be thoughtful
- Be respectful
- Be charitable
- Avoid destructive behavior
Excerpted from the Go conduct document.
Reporting Bugs
When you encounter a bug, please open an issue on the corresponding repository.
Start the issue title with the repository/sub-repository name, like tex/dvi: issue name
.
Be specific about the environment you encountered the bug in (e.g.: operating system, Go compiler version, …).
If you are able to write a test that reproduces the bug, please include it in the issue.
As a rule, we keep all tests OK and try to increase code coverage.
Your First Code Contribution
If you are a new contributor, thank you!
Before your first merge, you will need to be added to the CONTRIBUTORS and AUTHORS files.
Open a pull request adding yourself to these files.
All star-tex
code follows the BSD license in the license document.
We prefer that code contributions do not come with additional licensing.
For exceptions, added code must also follow a BSD license.
Code Contribution
If it is possible to split a large pull request into two or more smaller pull requests, please try to do so. Pull requests should include tests for any new code before merging. It is ok to start a pull request on partially implemented code to get feedback, and see if your approach to a problem is sound. You don’t need to have tests, or even have code that compiles to open a pull request, although both will be needed before merge. When tests use magic numbers, please include a comment explaining the source of the number. Benchmarks are optional for new features, but if you are submitting a pull request justified by performance improvement, you will need benchmarks to measure the impact of your change, and the pull request should include a report from benchcmp or, preferably, benchstat.
Commit messages also follow some rules. They are best explained at the official Go “Contributing guidelines” document:
golang.org/doc/contribute.html
For example:
tex/dvi: add support for automatic DVI optimization
This CL adds support for on-the-fly optimization of DVI documents.
The DVI interpreter can now inspect the stack of DVI commands and automatically
Fixes #42.
If the CL
modifies multiple packages at the same time, include them in the commit message:
tex/{dvi,kpath}: implement DVI font lookup via Kpath
This CL adds the ability to lookup font informations for DVI documents via
the Kpath mechanism.
Fixes #66.
Please always format your code with goimports.
Best is to have it invoked as a hook when you save your .go
files.
Files in the star-tex
repository don’t list author names, both to avoid clutter and to avoid having to keep the lists up to date.
Instead, your name will appear in the change log and in the CONTRIBUTORS and AUTHORS files.
New files that you contribute should use the standard copyright header:
// Copyright 2021 The star-tex Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
Files in the repository are copyright the year they are added. Do not update the copyright year on files that you change.
Code Review
If you are a contributor, please be welcoming to new contributors. Here is a good guide.
There are several terms code reviewers may use that you should become familiar with.
LGTM
— looks good to meSGTM
— sounds good to meCL
— change list; a single commit in the repositorys/foo/bar/
— please replacefoo
withbar
; this is sed syntaxs/foo/bar/g
— please replacefoo
withbar
throughout your entire change
We follow the convention of requiring at least 1 reviewer to say LGTM before a merge. When code is tricky or controversial, submitters and reviewers can request additional review from others and more LGTMs before merge. You can ask for more review by saying PTAL in a comment in a pull request. You can follow a PTAL with one or more @someone to get the attention of particular people. Also note that you do not have to be the pull request submitter to request additional review.
What Can I Do to Help?
If you are looking for some way to help the star-tex
project, there are good places to start, depending on what you are comfortable with.
- You can search for open issues in need of resolution.
- You can improve documentation, or improve examples.
- You can add and improve tests.
- You can improve performance, either by improving accuracy, speed, or both.
- You can suggest and implement new features that you think belong in
star-tex
.
Style
We use Go style.
This “Contributing” guide has been extracted from our sister project Gonum. Its guide is here.