During last two weeks of Seneca OSD600 Assignment 0.3, I reviewed some of PRs inTelescope project. Also my PRs were reviewed not just by maintainers, but also by other students in the course. Including my experiences from Hacktoberfest and co-op, I would like summarize what I learned as following.

1. Make sure to check contributor document before submitting a PR

Usually proper open source projects have detailed documentation about how to set up local dev environment and what to do before submitting. Usually contributors are asked to check unit test, lint error check and formatting. You don't want to talk about additional empty lines in your code with maintainer. We are all busy and we want to spend time on discussing something important in the code. Especially it happens more when you quickly push something that is almost done. Yeah, at least it's true for me. And maintainers are probably annoyed by pushes that are not ready for review. And it will delay your code to get merged. We can show more professionalism when we care about details.

2. Check git log and amend unnecessary history

Git traces every commits that you make. We don't need to show every minor commit in the history. We should only include the history that is necessary. I always had to look it up but now I'm very comfortable usinggit rebase main -i and squash my unnecessary commits into one meaningful commit.

3. Use code, picture, or detailed steps to make code review smooth

I gave someone confusing review feedback for a pull request. I should have shown the code to explain my feedback. And I get confused sometimes. So it's very effective when we use code, picture to highlight where to look at. GitHub provides a very easy way of attaching code lines to PR. Discussion can be easy with the code since we are programmers.

At the same time, I found reviewing someone else's code is very hard as I reviewed other's code for the first time during the assignment. Unless I know the features and code base very well, it's hard to give a good feedback. However this is what I felt while all members in the course reviewed other's code.

1. UI changes are not easy to tell whether it's ok or not ok. But I should give a candid feedback what I think about the change and what needs to be improved. Especially it's open space. We can share opinions and make it better.

2. Although it's working code, I should ask contributors to follow the coding convention, remove dead code and unnecessary comments and not to use hard-coded values or repeated code. Whether it works or not, any open source project should continue to grow. Some of legacy code can be error-prone which make it difficult to grow.

3. I should always thoroughly review contributor's code. Pull the new commit and run it in local machine to check changes in detail. Not necessarily all the time, but I should try to avoid that 'oh, I didn't see this. Please make another change.'

It's a lot of learning with open source this month again. It is also good to see many talented people in open source project. It gives me motivation and insight.