Skip to content

Latest commit

 

History

History
59 lines (37 loc) · 4.57 KB

CONTRIBUTING.md

File metadata and controls

59 lines (37 loc) · 4.57 KB

Contributing to Survey

🎉🎉 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.

Table of Contents

  1. Code of Conduct
  2. Getting Help
  3. Filing a Bug Report
  4. Suggesting an API change
  5. Submitting a Contribution
  6. Writing and Running Tests

Code of Conduct

This project and its contibutors are expected to uphold the Go Community Code of Conduct. By participating, you are expected to follow these guidelines.

Getting help

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.

How to file a bug report

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:

  1. What operating system and terminal are you using?
  2. An example that showcases the bug.
  3. What did you expect to see?
  4. What did you see instead?

Suggesting an API change

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.

Submitting a contribution

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

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.

Generating an autoplay test

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.