|
1 | 1 | # Contributing to NVDA |
2 | | -There are several ways in which you can contribute to the NVDA project: |
3 | | -- By testing NVDA |
4 | | -- Issue triage and investigation |
5 | | -- Code or documentation contributions |
6 | | - |
7 | | -## Testing |
8 | | - |
9 | | -Testing alpha / beta / and release candidates help to ensure the quality of the NVDA. |
10 | | -User / community testing is particularly important for languages other than English. |
11 | | -There are several approaches you may take for this: |
12 | | -- Unfocused usage: Just use NVDA as you normally would, and try to complete everyday tasks. |
13 | | -- Recent change focused testing: By following the changes that are being made to NVDA and purposefully testing these changes and looking for edge-cases. |
14 | | -- Regression testing: Testing older features and behavior to look for unintended regressions in behavior that don't seem related to recent changes. |
15 | | - |
16 | | -Forming a group can help you to get good coverage, brainstorm on what should be tested, and perhaps learn new ways to use NVDA. |
17 | | - |
18 | | -## Issue triage and investigation: |
19 | | -You can also make non-code contributions by helping process incoming GitHub issues. |
20 | | -For information on this please see the [triage process](../projectDocs/issues/triage.md). |
21 | | - |
22 | | -## Code/Docs contributions |
23 | | - |
24 | | -If you are new to the project, or looking for some way to help take a look at: |
25 | | -- [label:"good first issue"](https://github.com/nvaccess/nvda/issues?q=label%3A%22good+first+issue%22) |
26 | | -- [label:component/documentation](https://github.com/nvaccess/nvda/issues?q=label%3Acomponent%2Fdocumentation) |
27 | | -- [label:closed/needs-new-author](https://github.com/nvaccess/nvda/issues?q=label%3Aclosed%2Fneeds-new-author) |
28 | | -- [label:Abandoned](https://github.com/nvaccess/nvda/issues?q=label%3AAbandoned) |
29 | | - |
30 | | -### Guidelines: |
31 | | -- For anything other than minor bug fixes, please comment on an existing issue or create a new issue providing details about your proposed change. |
32 | | -- Unrelated changes should be addressed in separate issues. |
33 | | -- Include information about use cases, design, user experience, etc. |
34 | | - - This allows us to discuss these aspects and any other concerns that might arise, thus potentially avoiding a great deal of wasted time. |
35 | | -- It is recommended to wait for acceptance of your proposal before you start coding. |
36 | | - - A `triaged` label is an indicator that an issue is ready for a fix. |
37 | | - - Please understand that we very likely will not accept changes that are not discussed first. |
38 | | - - Consider starting a [GitHub discussion](https://github.com/nvaccess/nvda/discussions) or [mailing list topic](https://groups.io/g/nvda-devel/topics) to see if there is interest. |
39 | | -- A minor/trivial change which definitely wouldn't require design, user experience or implementation discussion, you can just create a pull request rather than using an issue first. |
40 | | - - e.g. a fix for a typo/obvious coding error or a simple synthesizer/braille display driver |
41 | | - - This should be fairly rare. |
42 | | -- If in doubt, use an issue first. Use this issue to discuss the alternatives you have considered in regards to implementation, design, and user experience. Then give people time to offer feedback. |
43 | 2 |
|
| 3 | +Please note: the NVDA project has a [Citizen and Contributor Code of Conduct](./CODE_OF_CONDUCT.md). |
| 4 | +NV Access expects that all contributors and other community members will read and abide by the rules set out in this document while participating or contributing to this project. |
44 | 5 |
|
45 | | -### GitHub process: |
46 | | -#### 1. "fork" the NVDA repository on GitHub |
47 | | - When you fork the repository, GitHub will create a copy of the master branch. |
48 | | - However, this branch will not be updated when the official master branch is updated. |
49 | | - To ensure your work is always based on the latest commit in the official master branch, it is recommended that your master branch be linked to the official master branch, rather than the master branch in your GitHub fork. |
50 | | - If you have cloned your GitHub fork, you can do this from the command line as follows: |
51 | | - ```sh |
52 | | - # Add a remote for the NV Access repository. |
53 | | - git remote add nvaccess https://github.com/nvaccess/nvda.git |
54 | | - # Fetch the nvaccess branches. |
55 | | - git fetch nvaccess |
56 | | - # Switch to the local master branch. |
57 | | - git checkout master |
58 | | - # Set the local master to use the nvaccess master as its upstream. |
59 | | - git branch -u nvaccess/master |
60 | | - # Update the local master. |
61 | | - git pull |
62 | | - ``` |
| 6 | +The NVDA project is guided by a [product vision statement and set of principles](./projectDocs/product_vision.md). |
| 7 | +The vision and principles should be always considered when planning features and prioritizing work. |
63 | 8 |
|
64 | | -#### 2. Use a separate "topic" branch for each contribution |
65 | | - All code should usually be based on the latest commit in the official master branch at the time you start the work unless the code is entirely dependent on the code for another issue. |
66 | | - If you are adding a feature or changing something that will be noticeable to the user, you should update the User Guide accordingly. |
67 | | - |
68 | | -#### 3. Run unit tests and lint check |
69 | | - - Run `rununittests` (`rununittests.bat`) before you open your Pull Request, and make sure all the unit tests pass. |
70 | | - - If possible for your PR, please consider creating a set of unit tests to test your changes. |
71 | | - - The lint check ensures your changes comply with our code style expectations. Use `runlint nvaccess/master` (`runlint.bat`) |
72 | | - |
73 | | -#### 4. Create a Pull Request (PR) |
74 | | - When you think a contribution is ready, or you would like feedback, open a draft pull request. |
75 | | - Please fill out the Pull Request Template, including the checklist of considerations. |
76 | | - The checklist asks you to confirm that you have thought about each of the items, if any of the items are missing it is helpful to explain elsewhere in the PR why it has been left out. |
77 | | - When you would like a review, mark the PR as "ready for review". |
78 | | - |
79 | | -#### 5. Participate in the code review process |
80 | | - This process requires core NVDA developers to understand the intent of the change, read the code changes, asking questions or suggesting changes. |
81 | | - Please participate in this process, answering questions, and discussing the changes. |
82 | | - Being proactive will really help to speed up the process of code review. |
83 | | - When the PR is approved it will be merged, and the change will be active in the next alpha build. |
84 | | - |
85 | | -#### 6. Feedback from alpha users |
86 | | - After a PR is merged, watch for feedback from alpha users / testers. |
87 | | - You may have to follow up to address bugs or missed use-cases. |
88 | | - |
89 | | -## Code Style |
90 | | - |
91 | | -Refer to [our coding standards document](../projectDocs/dev/codingStandards.md) |
| 9 | +There are several ways in which you can contribute to the NVDA project: |
| 10 | +- [Reporting issues](../projectDocs/issues/readme.md) |
| 11 | +- [Issue triage and investigation](../projectDocs/issues/triage.md) |
| 12 | +- [Testing](../projectDocs/testing/contributing.md) |
| 13 | +- [Translating NVDA](https://github.com/nvaccess/nvda/wiki/Translating) |
| 14 | +- [Code or documentation contributions](../projectDocs/dev/contributing.md) |
| 15 | +- [Creating add-ons](../projectDocs/dev/addons.md) |
0 commit comments