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.

131 lines
8.1 KiB

  1. # Contributing
  2. 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.
  3. Please note we have a code of conduct, please follow it in all your interactions with the project.
  4. ## How to contribute to doccano
  5. ### Reporting Bugs
  6. #### Before submitting a bug report
  7. * Check the [FAQs](https://github.com/doccano/doccano/blob/master/docs/faq.md) for a list of common questions and problems.
  8. * Ensure the bug was not already reported by searching on GitHub under [Issues](https://github.com/doccano/doccano/issues).
  9. * [Open a new issue](https://github.com/doccano/doccano/issues/new/choose) if you're unable to find an open one addressing the problem.
  10. * Use the relevant bug report templates to create the issue.
  11. #### How do I submit a good bug report?
  12. Explain the problem and include additional details to help maintainers reproduce the problem:
  13. * Use a clear and descriptive title for the issue to identify the problem.
  14. * Describe the exact steps which reproduce the problem in as many details as possible.
  15. * Provide specific examples to demonstrate the steps.
  16. * Describe the behavior you observed after following the steps and point out what exactly is the problem with that behavior.
  17. * Explain which behavior you expected to see instead and why.
  18. * Include screenshots and animated GIFs which show you following the described steps and clearly demonstrate the problem.
  19. * If the problem is related to performance or memory, include a CPU profile capture with your report.
  20. * If the problem is related to network, include a network activity in Chrome/Firefox/Safari DevTools.
  21. * 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.
  22. ### Suggesting Enhancements
  23. #### Before submitting an enhancement suggestion
  24. * Ensure the suggestion was not already reported by searching on GitHub under [Issues](https://github.com/doccano/doccano/issues).
  25. * [Open a new issue](https://github.com/doccano/doccano/issues/new/choose) if you're unable to find an open one addressing the suggestion.
  26. * Use the relevant issue templates to create one.
  27. #### How do I submit a good enhancement suggestion?
  28. Explain the suggestion and include additional details to help developers understand it:
  29. * Use a clear and descriptive title for the issue to identify the suggestion.
  30. * Provide a step-by-step description of the suggested enhancement in as many details as possible.
  31. * Provide specific examples to demonstrate the steps.
  32. * Describe the current behavior and explain which behavior you expected to see instead and why.
  33. * Include screenshots and animated GIFs which help you demonstrate the steps or point out the part of doccano which the suggestion is related to.
  34. * Explain why this enhancement would be useful to most doccano users.
  35. * List some other annotation tools or applications where this enhancement exists.
  36. * Specify which version of doccano you're using.
  37. * Specify the name and version of the OS you're using.
  38. ## development workflow
  39. 1. **Fork the project & clone it locally:** Click the "Fork" button in the header of the [GitHub repository](https://github.com/doccano/doccano), creating a copy of `doccano` in your GitHub account. To get a working copy on your local machine, you have to clone your fork. Click the "Clone or Download" button in the right-hand side bar, then append its output to the `git clone` command.
  40. $ git clone https://github.com/YOUR_USERNAME/doccano.git
  41. 1. **Create an upstream remote and sync your local copy:** Connect your local copy to the original "upstream" repository by adding it as a remote.
  42. $ cd doccano
  43. $ git remote add upstream https://github.com:doccano/doccano.git
  44. You should now have two remotes: read/write-able `origin` points to your GitHub fork, and a read-only `upstream` points to the original repo. Be sure to [keep your fork in sync](https://help.github.com/en/articles/syncing-a-fork) with the original, reducing the likelihood of merge conflicts later on.
  45. 1. **Create a branch for each piece of work:** Branch off `develop` for each bugfix or feature that you're working on. Give your branch a descriptive, meaningful name like `bugfix-for-issue-1234` or `improve-io-performance`, so others know at a glance what you're working on.
  46. $ git checkout develop
  47. $ git pull develop master && git push origin develop
  48. $ git checkout -b my-descriptive-branch-name
  49. At this point, you may want to install your version of `doccano`. It's usually best to do this within a dedicated virtual environment; We recomment to use `poetry` with Python 3.8+:
  50. $ cd backend
  51. $ poetry install
  52. $ poetry shell
  53. Second, set up the database and run the development server. Doccano uses Django and Django Rest Framework as a backend. We can set up them by using Django command:
  54. $ python manage.py migrate
  55. $ python manage.py create_roles
  56. $ python manage.py create_admin --noinput --username "admin" --email "admin@example.com" --password "password"
  57. $ python manage.py runserver
  58. In another terminal, you need to run Celery in `backend` directory to use import/export dataset feature:
  59. $ celery --app=config worker --loglevel=INFO --concurrency=1
  60. The doccano frontend is built in Node.js and uses Yarn as a package manager. If you haven't installed them yet, please see Node.js and Yarn documentation.
  61. First, to install the defined dependencies for our project, just run the install command.
  62. $ cd frontend
  63. $ yarn install
  64. Then run the dev command to serve with hot reload at :
  65. $ yarn dev
  66. Now, you can access to the frontend at <http://127.0.0.1:3000/>.
  67. 1. **Implement your changes:** Use your preferred text editor to modify the `doccano` source code. Be sure to keep your changes focused and in scope, and follow the coding conventions described below! Document your code as you write it. Run your changes against any existing tests and add new ones as needed to validate your changes; make sure you don’t accidentally break existing functionality! Several common commands can be accessed via the Poetry task:
  68. $ poetry run task mypy
  69. $ poetry run task flake8
  70. $ poetry run task black
  71. $ poetry run task isort
  72. $ poetry run task test
  73. For the frontend, you can execute the following commands:
  74. $ yarn lintfix
  75. $ yarn precommit
  76. $ yarn fix:prettier
  77. 1. **Push commits to your forked repository:** Group changes into atomic git commits, then push them to your `origin` repository. There's no need to wait until all changes are final before pushing — it's always good to have a backup, in case something goes wrong in your local copy.
  78. $ git push origin my-descriptive-branch-name
  79. 1. **Open a new Pull Request in GitHub:** When you're ready to submit your changes to the main repo, navigate to your forked repository on GitHub. Switch to your working branch then click "New pull request"; alternatively, if you recently pushed, you may see a banner at the top of the repo with a "Compare & pull request" button, which you can click on to initiate the same process. Fill out the PR template completely and clearly, confirm that the code "diff" is as expected, then submit the PR. A number of processes will run automatically via GitHub Workflows (see `.github/workflows/`); we'll want to make sure everything passes before the PR gets merged.
  80. 1. **Respond to any code review feedback:** At this point, @Hironsan will review your work and either request additional changes/clarification or approve your work. There may be some necessary back-and-forth; please do your best to be responsive. If you haven’t gotten a response in a week or so, please politely nudge him in the same thread — thanks in advance for your patience!
  81. ## Styleguides
  82. ### Git Commit Messages
  83. * Use the present tense ("Add feature" not "Added feature")
  84. * Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
  85. * Limit the first line to 72 characters or less
  86. * Reference issues and pull requests liberally after the first line