UNPKG

@onflow/flow-js-testing

Version:

This package will expose a set of utility methods, to allow Cadence code testing with libraries like Jest

126 lines (83 loc) 5.09 kB
# Contributing The following is a set of guidelines for contributing. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request. ## Table Of Contents [Getting Started](#project-overview) [How Can I Contribute?](#how-can-i-contribute) - [Reporting Bugs](#reporting-bugs) - [Suggesting Enhancements](#suggesting-enhancements) - [Your First Code Contribution](#your-first-code-contribution) - [Pull Requests](#pull-requests) [Styleguides](#styleguides) - [Git Commit Messages](#git-commit-messages) - [Styleguide](#styleguide) [Additional Notes](#additional-notes) ## How Can I Contribute? ### Reporting Bugs #### Before Submitting A Bug Report - **Search existing issues** to see if the problem has already been reported. If it has **and the issue is still open**, add a comment to the existing issue instead of opening a new one. #### How Do I Submit A (Good) Bug Report? Explain the problem and include additional details to help maintainers reproduce the problem: - **Use a clear and descriptive title** for the issue to identify the problem. - **Describe the exact steps which reproduce the problem** in as many details as possible. When listing steps, **don't just say what you did, but explain how you did it**. - **Provide specific examples to demonstrate the steps**. Include links to files or GitHub projects, or copy/pasteable snippets, which you use in those examples. If you're providing snippets in the issue, use [Markdown code blocks](https://help.github.com/articles/markdown-basics/#multiple-lines). - **Describe the behavior you observed after following the steps** and point out what exactly is the problem with that behavior. - **Explain which behavior you expected to see instead and why.** - **Include error messages and stack traces** which show the output / crash and clearly demonstrate the problem. Provide more context by answering these questions: - **Can you reliably reproduce the issue?** If not, provide details about how often the problem happens and under which conditions it normally happens. Include details about your configuration and environment: - **What is the version you're using**? - **What's the name and version of the Operating System you're using**? ### Suggesting Enhancements #### Before Submitting An Enhancement Suggestion - **Perform a cursory search** to see if the enhancement has already been suggested. If it has, add a comment to the existing issue instead of opening a new one. #### How Do I Submit A (Good) Enhancement Suggestion? Enhancement suggestions are tracked as [GitHub issues](https://guides.github.com/features/issues/). Create an issue and provide the following information: - **Use a clear and descriptive title** for the issue to identify the suggestion. - **Provide a step-by-step description of the suggested enhancement** in as many details as possible. - **Provide specific examples to demonstrate the steps**. Include copy/pasteable snippets which you use in those examples, as [Markdown code blocks](https://help.github.com/articles/markdown-basics/#multiple-lines). - **Describe the current behavior** and **explain which behavior you expected to see instead** and why. - **Explain why this enhancement would be useful** to users. ### Your First Code Contribution Unsure where to begin contributing? You can start by looking through these "Good first issue" and "Help wanted" issues: - [Good first issues](https://github.com/onflow/flow-js-testing/labels/good%20first%20issue): issues which should only require a few lines of code, and a test or two. - [Help wanted issues](https://github.com/onflow/flow-js-testing/labels/help%20wanted): issues which should be a bit more involved than "Good first issue" issues. Both issue lists are sorted by total number of comments. While not perfect, number of comments is a reasonable proxy for impact a given change will have. ### Pull Requests The process described here has several goals: - Maintain code quality - Fix problems that are important to users - Engage the community in working toward the best possible UX - Enable a sustainable system for the maintainers to review contributions Please follow the [styleguides](#styleguides) to have your contribution considered by the maintainers. Reviewer(s) may ask you to complete additional design work, tests, or other changes before your pull request can be ultimately accepted. ## Styleguides Before contributing, make sure to examine the project to get familiar with the patterns and style already being used. ### Git Commit Messages - Use the present tense ("Add feature" not "Added feature") - Use the imperative mood ("Move cursor to..." not "Moves cursor to...") - Limit the first line to 72 characters or less - Reference issues and pull requests liberally after the first line ### Styleguide We try to follow the coding guidelines: - Code should pass the linter: `npm run lint` - Code should be commented ## Additional Notes Thank you for your interest in contributing!