🎉🎉 First off, thanks for the interest in contributing to survey
! 🎉🎉
The following is a set of guidelines to follow when contributing to this package. These are not hard rules, please use common sense and feel free to propose changes to this document in a pull request.
- Code of Conduct
- Getting Help
- Filing a Bug Report
- Suggesting an API change
- Submitting a Contribution
- Writing and Running Tests
This project and its contibutors are expected to uphold the Go Community Code of Conduct. By participating, you are expected to follow these guidelines.
Feel free to open up an issue on GitHub when asking a question so others will be able to find it. Please remember to tag the issue with the Question
label so the maintainers can get to your question as soon as possible. If the question is urgent, feel free to reach out to @AlecAivazis directly in the gophers slack channel.
Bugs are tracked using the Github Issue tracker. When filing a bug, please remember to label the issue as a Bug
and answer/provide the following:
- What operating system and terminal are you using?
- An example that showcases the bug.
- What did you expect to see?
- What did you see instead?
If you have an idea, I'm more than happy to discuss it. Please open an issue labeled Discussion
and we can work through it. In order to maintain some sense of stability, additions to the top-level API are taken just as seriously as changes that break it. Adding stuff is much easier than removing it.
In order to maintain stability, most features get fully integrated in more than one PR. This allows for more opportunity to think through each API change without amassing large amounts of tech debt and API changes at once. If your feature can be broken into separate chunks, it will be able to be reviewed much quicker. For example, if the PR that implemented the Validate
field was submitted in a PR separately from one that included survey.Required
, it would be able to get merge without having to decide how many different Validators
we want to provide as part of survey
's API.
When submitting a contribution,
- Provide a description of the feature or change
- Reference the ticket addressed by the PR if there is one
- Following community standards, add comments for all exported members so that all necessary information is available on godocs
- Remember to update the project README.md with changes to the high-level API
- Include both positive and negative unit tests (when applicable)
- Contributions with visual ramifications should be accompanied with an
autoplay
recording that will get verified on every PR. For more information on generating these recordings, see Writing and Running Tests
When submitting features, please add as many units tests as necessary to test both positive and negative cases.
Given the current implementation of the library, functionality that is part of the prompt's output needs to be tested by recording an interaction and replaying that interaction with every change. The script and its recording should be committed to the tests
directory. Bugs that are reported and reproduced should also get copied into this directory and recorded for future validation. This recording is done with a package called autoplay
, created by one of survey
's maintainers.
Autoplay
will record an interaction with the terminal and generate a script which executes the recording against the current terminal session. To install autoplay
, run: go get github.com/coryb/autoplay github.com/kr/pty
.
Once you have everything installed, navigate to the tests/
directory and add a file with your test. I suggest running it first manually to ensure it behaves as you expect. Then, run autoplay -n autoplay/<test name>.go go run <test name>.go
. Once the script is running, you should be greeted with whatever prompt you are testing. Interact with the terminal like normal, performing any sort of interaction that you want to verify. When the process ends, so will the recording and you should find a new file in tests/autoplay/
with the recording. Commit this to the project alongside your PR.