1# How To Contribute 2 3There are several ways to contribute to the development of ReactOS. The most often encountered problem is not knowing where to begin or what to do. If you are able to program or understand the technical information that is pertinent to this project, helping the development can be easy. 4 5- [What To Do?](#what-to-do) 6- [How To Contribute?](#how-to-contribute) 7- [Where To Start?](#where-to-start) 8 9**Legal notice:** If you have seen Microsoft Windows source code, your contribution won't be accepted because of potential copyright violation. Before contributing, you must affirm that the following is true: 10>I hereby swear that I have not used nor seen the source code to any version of the Windows operating system 11>nor any Microsoft product that may be related to the proposed project that is under a license incompatible 12>with contribution to ReactOS, including but not limited to the leaked Windows 2000 source code and the Windows Research Kernel. 13 14## What To Do? 15 16### Fix bugs 17 18You can try to fix a few bugs that are already listed in [JIRA]. Squashing bugs is not a simple task. It requires a lot more skill than simply searching for them, and can be time consuming; however, by doing that you greatly help ReactOS become a stable system. 19 20_NOTE: patches related to 3rd party code such as Wine or BtrFS should be sent to upstream of the said projects. See [3rd Party Files.txt], [README.WINE] and [README.FSD] in [media/doc](media/doc) for details._ 21 22### Fix tests 23 24Tests are used to check the functionality and correctness of APIs on ReactOS compared to Windows implementations. There are some unit tests that you could help ReactOS pass, which can be found [in the Web Test Manager][testman] and some that are broken or yet to be written. 25 26### Fix Coverity scans 27 28[Coverity] is enhanced static analysis that uncovers leaks, buffer overflows, security issues and other. We do such scans on ReactOS codebase pretty often. You can [request][request-coverity] to see Coverity 'defects' and help to fix them. 29 30### Test ReactOS 31 32By localizing bugs, developers can identify what causes the bug and which part it affects. There are a variety of methods to [debug] ReactOS while testing it. After identifying a bug, check if it is already known about by searching on JIRA and adding any additional information to the report. If you think that it is an unidentified bug, consider [filing a bug report]. 33 34### Implement new things 35 36Considering ReactOS is alpha quality software, there is a lot of [missing functionality] that Windows operating systems have. Before starting a project to implement something, find out whether another person is working on the same thing. If you find that someone is already working on it, ask if any assistance is needed for what specifically is being worked on or a related project. More often than not, someone will start to implement something and move onto something else before it's complete. Make sure you stay committed to what you are going to implement, and do not be afraid to ask for assistance if you need help with something. 37 38### Write documentation 39 40There are some important points if you would like to help document ReactOS: 41 421. Make sure the documentation does not exist yet (if it does, help improve it). 432. Respect [clean room reverse engineering] practices. 443. Add your knowledge to a place where the other developers can find it. 45 46## How To Contribute? 47 48Your contribution can be of numerous forms. We currently accept two ways to contribute - Pull Requests and Patches. 49 50### Pull Requests 51 52Since our [migration to GitHub] we gladly accept __[Pull Requests]__. Pull requests let you tell others about changes you have pushed to a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before the changes are merged into the repository. __Pull request is a preferred way to submit your work__ - it makes reviewing and merging your contribution much easier. 53 54### Patches 55 56A __[patch]__ is a set of changes to existing source code. The changes in a patch can be merged into existing source code. This process is referred to as applying a patch (to source code). Which changes a patch contains and the way the patch is structured can have significant impact on the consequences that can happen from applying the patch. 57 58See [Submitting Patches] for details. 59 60### Commit style 61 62Our commit style is defined in a __[commit template]__. Use it as a reference or turn it on using `git config commit.template .gitmessage`. This will set this template as an initial commit message for the new commits in your local repository. 63 64### Rules and Recommendations 65 66- *Use your __real name__ and __real email__.* We do not accept anonymous code contributions! 67 - Every commit that changes code or translations should have author's full legal name (in latin letters, diacritics allowed). 68 - It's recommended to have the same full name set in GitHub profile (in the [Name field here][GitHub Profile Settings]) that matches one specified in commits. 69- There is an exception for media changes, such as changes of art (wallpapers, themes, icons, sounds) and out-of-code documentation. 70 - In these specific cases it's allowed to use a nickname or alias as author's name, and it's recommended to have the same name set in GitHub profile (in the [Name field here][GitHub Profile Settings]) matching one specified in commits. 71- In any case the author must use a real e-mail address, this includes git commits (`user.email` setting) and GitHub [e-mail settings][GitHub Email Settings] - the checkbox "Keep my email addresses private" must be unchecked there. 72 - In order to *keep your privacy*, select appropriate "Primary email address" that will be applied to your commits in GitHub [e-mail settings][GitHub Email Settings]. 73- *Ensure your contribution is properly described.* Include the relevant issue number if applicable. 74- *Put only related changes.* It will make reviewing easier as the reviewer needs to recall less information about the existing source code that is changed. 75- *Search for similar pull requests/patches before submitting.* It may be that a similar pull request or issue was opened previously. Comment and review on that one instead. 76- *Keep your contribution small and focused on the topic.* It can be tempting to fix existing issues as you come across them while reading the source code. Resist the temptation and put in a note in the source code instead, or (even better) put the issue in the issue tracking system. 77- *Respect our __[Coding Style]__ and __[Programming Guidelines]__.* 78- *Do not be afraid to ask questions.* Ask our developers in the [chat]. 79 80To amend your commit with your name and e-mail (in any case you've forgot to set your name/e-mail) please take a look at this [guide](https://reactos.org/wiki/ReactOS_Git_For_Dummies#Amending_your_commit_with_name.2FE-mail). To set your name/e-mail globally for future commits that you push, [read this](https://reactos.org/wiki/ReactOS_Git_For_Dummies#Assign_commits_with_your_name_.26_E-mail_automatically). 81 82## Where To Start? 83 84Finding a good project to start with can be a challenge, because when starting out you are (usually) not aware of all the possibilities. To help you find a project, here are some ideas to try: 85 86- Find a test that fails, and try to make it succeed: <https://reactos.org/testman/> 87- Look around in JIRA, and if you have problems finding nice projects to start with, there is a label for this: <https://jira.reactos.org/issues/?jql=labels%20%3D%20starter-project> 88- Ask for help in the [chat] 89- Additionally, there are some tests that cause crashes/hangs, but these might be slightly harder: <https://jira.reactos.org/browse/ROSTESTS-125> 90 91 [clean room reverse engineering]: https://en.wikipedia.org/wiki/Clean_room_design 92 [debug]: https://reactos.org/wiki/Debugging 93 [JIRA]: https://jira.reactos.org/ 94 [filing a bug report]: https://reactos.org/wiki/File_Bugs 95 [testman]: https://reactos.org/testman/ 96 [migration to GitHub]: https://reactos.org/project-news/reactos-repository-migrated-github/ 97 [humans are terrible at tracking large amount of information]: https://www.eurekalert.org/pub_releases/2005-03/aps-hmc030805.php 98 [Pull requests]: https://help.github.com/articles/about-pull-requests/ 99 [GitHub Profile Settings]: https://github.com/settings/profile 100 [GitHub Email Settings]: https://github.com/settings/emails 101 [tips for reviewing patches]: https://www.drupal.org/patch/review 102 [missing functionality]: https://reactos.org/wiki/Missing_ReactOS_Functionality 103 [patch]: https://git-scm.com/docs/git-format-patch 104 [Submitting Patches]: https://reactos.org/wiki/Submitting_Patches 105 [Coding Style]: https://reactos.org/wiki/Coding_Style 106 [chat]: https://reactos.org/wiki/Mattermost 107 [Programming Guidelines]: https://reactos.org/wiki/Programming_Guidelines 108 [3rd Party Files.txt]: /media/doc/3rd_Party_Files.txt 109 [README.WINE]: /media/doc/README.WINE 110 [README.FSD]: /media/doc/README.FSD 111 [Coverity]: https://scan.coverity.com/projects/reactos 112 [request-coverity]: https://scan.coverity.com/memberships/new?project_id=reactos 113 [commit template]: .gitmessage 114 115# See Also 116 117- [Rules for managing Pull Requests](PULL_REQUEST_MANAGEMENT.md) 118