This document describes how to write a good Weex bug report. Good bug reports help developers to classify the priority and severity of a bug properly, which helps the bug get fixed as soon as possible. The more specific information you provide, the better your bug gets understood.
A good bug report should include the following information:
The goal of title is to make the report searchable and uniquely identifiable.
A bad example: List Crash
A good Example: List Crashes when deleting a header
Weex Version: Please identify the version of WeexSDK or Weex Playground or weex-toolkit you were using when the bug occurred
Device environment: Please identify the device model, platform and OS version. e.g. , iPhone 6, iOS 10.3.
The overview or description of a bug report is to explain the bug in detail, including:
The aim to provide the reproducible steps is to enable developers to reproduce the bug in their own environment. Here's an example:
Step 1: Load the demo using Weex Playground
Step 2: Scroll to the bottom of the list
Step 3: Click the red button to delete a header
The test results, including Expected Result and Actual Result, will tell developers what's wrong. Expected Result describes what should happen, and Actual Result describes what actually happens.
This document is a modified version of [1].