richard
/
doccano
mirror of https://github.com/doccano/doccano.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1443 Commits
14 Branches
32 Tags
77 MiB
Tree: 2cbd0cb914
Branches Tags
${ item.name }
Create branch ${ searchTerm }
from '2cbd0cb914'
${ noResults }
doccano/CONTRIBUTING.md

73 lines
4.6 KiB
Raw Normal View History

Create CONTRIBUTING.md
4 years ago
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
  1. # Contributing
  3. When contributing to this repository, please first discuss the change you wish to make via issue with the owners of this repository before making a change.
  5. Please note we have a code of conduct, please follow it in all your interactions with the project.
  7. ## How to contribute to doccano
  9. ### Reporting Bugs
  11. #### Before submitting a bug report
  13. * Check the [FAQs](https://github.com/doccano/doccano/blob/master/docs/faq.md) for a list of common questions and problems.
  14. * Ensure the bug was not already reported by searching on GitHub under [Issues](https://github.com/doccano/doccano/issues).
  15. * [Open a new issue](https://github.com/doccano/doccano/issues/new/choose) if you're unable to find an open one addressing the problem.
  16. * Use the relevant bug report templates to create the issue.
  18. #### How do I submit a good bug report?
  20. Explain the problem and include additional details to help maintainers reproduce the problem:
  22. * Use a clear and descriptive title for the issue to identify the problem.
  23. * Describe the exact steps which reproduce the problem in as many details as possible.
  24. * Provide specific examples to demonstrate the steps.
  25. * Describe the behavior you observed after following the steps and point out what exactly is the problem with that behavior.
  26. * Explain which behavior you expected to see instead and why.
  27. * Include screenshots and animated GIFs which show you following the described steps and clearly demonstrate the problem.
  28. * If the problem is related to performance or memory, include a CPU profile capture with your report.
  29. * If the problem is related to network, include a network activity in Chrome/Firefox/Safari DevTools.
  30. * If the problem wasn't triggered by a specific action, describe what you were doing before the problem happened and share more information using the guidelines below.
  32. ### Suggesting Enhancements
  34. #### Before submitting an enhancement suggestion
  36. * Ensure the suggestion was not already reported by searching on GitHub under [Issues](https://github.com/doccano/doccano/issues).
  37. * [Open a new issue](https://github.com/doccano/doccano/issues/new/choose) if you're unable to find an open one addressing the suggestion.
  38. * Use the relevant issue templates to create one.
  40. #### How do I submit a good enhancement suggestion?
  42. Explain the suggestion and include additional details to help developers understand it:
  44. * Use a clear and descriptive title for the issue to identify the suggestion.
  45. * Provide a step-by-step description of the suggested enhancement in as many details as possible.
  46. * Provide specific examples to demonstrate the steps.
  47. * Describe the current behavior and explain which behavior you expected to see instead and why.
  48. * Include screenshots and animated GIFs which help you demonstrate the steps or point out the part of doccano which the suggestion is related to.
  49. * Explain why this enhancement would be useful to most doccano users.
  50. * List some other annotation tools or applications where this enhancement exists.
  51. * Specify which version of doccano you're using.
  52. * Specify the name and version of the OS you're using.
  54. ### Pull Request Process
  56. Please follow these steps to have your contribution considered by the maintainers:
  58. 1. Open a related issue before making a pull request as much as possible.
  59. 2. Follow all instructions in [the template](PULL_REQUEST_TEMPLATE.md)
  60. 3. Follow the [styleguides](#styleguides)
  61. 4. After you submit your pull request, verify that all [status checks](https://help.github.com/articles/about-status-checks/) are passing <details><summary>What if the status checks are failing?</summary>If a status check is failing, and you believe that the failure is unrelated to your change, please leave a comment on the pull request explaining why you believe the failure is unrelated. A maintainer will re-run the status check for you. If we conclude that the failure was a false positive, then we will open an issue to track that problem with our status check suite.</details>
  62. 5. You may merge the Pull Request in once you have the sign-off of the project members([@Hironsan](https://github.com/Hironsan) or [@icoxfog417](https://github.com/icoxfog417)).
  64. While the prerequisites above must be satisfied prior to having your pull request reviewed, the reviewer(s) may ask you to complete additional design work, tests, or other changes before your pull request can be ultimately accepted.
  66. ## Styleguides
  68. ### Git Commit Messages
  70. * Use the present tense ("Add feature" not "Added feature")
  71. * Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
  72. * Limit the first line to 72 characters or less
  73. * Reference issues and pull requests liberally after the first line