|
ℹ️
|
If you’re starting to read this guide, well thanks for willing to contribute to this project! Your effort will be very much appreciated. If you need help, take a look at our dedicated document. |
After you’ve read the relevant sections of this document, you can open a ticket through Github here: github.com/archriss/react-native-render-html/issues/new/choose. Make sure you follow the appropriate template.
|
ℹ️
|
The art of filling good reports is as important and valued as the art of producing readable, maintainable code. Developers tend to rush when filling reports because their initiative stems from a place of frustration. This is very well understandable, but ineffective regarding the goal of solving one’s problem. Consider the time investment / benefits ratio: by filling a detailed bug report, you might have committed a chunk of your valuable time. But your chances of having a fix merged rapidly have considerably increased. |
|
|
By not following our guidelines and templates, you risk having your ticket closed without notice. Sorry about that… our time is also valuable, and we cannot help you if you don’t help us in the process! |
|
🔥
|
If you would like to report a problem, take a look around and see if someone already opened an issue about it (see HELP document). If you a are certain this is a new, unreported bug, you can submit a bug report by opening a new issue. |
The most important quality of your bug report is reproducibility. It means we can easily reproduce and investigate the bug to fix it as quickly as possible. If you’ve never heard of a “minimal reproducible example”, take a look at this guide: stackoverflow.com/help/mcve. Bellow is a table of different types of reproductions:
|
💡
|
If you add screencasts, screenshots, debugging information, or any insights that can help us identify the failure as quickly as possible, you can consider each a bonus ⚡. |
| Reproduction | Efficiency | Information |
|---|---|---|
Regression Test |
⚡⚡⚡⚡ |
Offering a PR with a Test which reproduces the issue is the most efficient way to have your bug fixed rapidly. More details on the dedicated section. You are still required to open a bug report ticket, but you will be able to skip many steps. |
Snack |
⚡⚡⚡ |
A Snack is very convenient for you and for us. You can start from our template. Make sure you set the appropriate version of this library. |
Git |
⚡⚡⚡ |
A Git reproduction is as efficient as a Snack, albeit it might be a little extra work for you. |
Code Snippet |
⚡ |
A snippet is better than nothing, but we don’t consider it high quality and might take more time to investigate. Please consider put your snippet into a Snack. I will take you 2 minutes to configure. |
Second important thing: try-out the latest version, including pre-releases! For
more information on this topic, read the
Versions section
of the README. If you can try master branch, that would be even better, but
we don’t require it because it could contain breaking changes. To do
so, simply run the following command:
npm install "github:archriss/react-native-render-html#master"We’re not having big requirements on those kind of submissions, apart from following the associated template. The more you elaborate though, the better the chances are your proposition will be implemented in the future. You can, in addition, consider writing a RFC and offering it as a PR.
|
🔥
|
You should never start a Pull Request prior to having the bug, feature or enhancement described in a separate issue. It is also highly advised that you deliberate about your intention to provide a PR in the aforementioned issue. |
|
ℹ️
|
We require some criterion to accept a pull request. But don’t worry, we’re also willing to help. You’re encouraged to start a Github draft and we will be glad to help you build it and make it comply with our requirements. If you have any question or need advise regarding your contribution, you can also ping us in our our Discord #contributing channel. |
If your PR fixes a bug, you are required to implement a regression test to prove your fix is effective, but don’t worry, we will help you. The simplest way is to look at our test folder and copy/paste an existing regression test to get inspiration. You must name your file test after the pattern described in this folder README. If you know what the test should do, but don’t know how to implement the test, you can add a "Testing Plan" section in the body of your PR.
When you submit a bug ticket, the fastest path for us to resolve the issue is by providing a bug reproduction. Take a glance at our test folder and get inspiration by looking at regression tests. You must name your file-test after the pattern described in this folder README. The PR is ready when the test fails.
|
ℹ️
|
We recommend you use the draft Github option when you start a Feature PR! |
If you PR provides new features, it means that the API of this library will likely change. If that is the case, you will be required to update typescript types (we can help you if you’re not familiar with Typescript) and documentation in the README. Also, you will be required to test the new feature. Take a look at our test folder and follow the test folder README for more details. If you’re lost, we will be glad to help you, either on discord or within the PR on Github.
|
ℹ️
|
RFC are propositions for new methods, behaviors and other API capabilities, or the exploration of an algorithmic challenge that is specific to this library. These are not Internet Society’s RFCs! We don’t have a rich multi-stage process. A RFC is either a draft, in discussion, or adopted (merged). We thereafter use versioning to polish and enhance those specifications. |
RFC purpose is to offer drafts for new ideas which goes relatively in depth regarding the issues, consequences and caveats of a peculiar feature. We don’t have strict requirements, but the structure should loosely resembles the following:
-
Problem Frame (what is the context and which issues this enhancement or feature will address).
-
Requirements (what are the behaviors required for this feature to be supported?).
You can take a look at drafts in
the rfc
folder for inspiration.
|
ℹ️
|
We require RFCs to be written in AsciiDoc. If you know markdown, it is very easy to pick and it ends-up much more powerful and versatile. Their documentation is of excellent quality, as proven by their writer’s guide. |