| 15 | | * Also, it's a good idea if you take some time to review patches yourself as well. Not only will this help speed things up as bugs and ways to improve your code can be found before a team member has had time to look at the patch, it's also a chance for you to become more familiar with the code and the coding conventions. Even just downloading/applying the patch and compiling it and testing if it does as it's supposed to is highly valuable. (Maybe the developer only has access to Linux, and you're on Windows or Mac, so even just testing to see if it compiles can be a good thing.) You don't have to know all the code to be able to review patches. |
| 16 | | |
| | 15 | * Also, it's a good idea if you take some time to test patches yourself as well. Even just downloading/applying the patch and compiling it and testing if it does as it's supposed to is highly valuable. (Maybe the developer only has access to Linux, and you're on Windows or Mac, so even just testing to see if it compiles can be a good thing.) You don't have to know all the code to be able to test patches. |
| | 16 | * Once you get more familiar with the code you're encouraged to help review patches yourself. Not only will this help speed things up as bugs and ways to improve your code can be found before a team member has had time to look at the patch, it's also a chance for you to become even more familiar with the code and the coding conventions. |
