Summary of Week 4
In class we were shown how to work on GitHub repositories through our local machines using git. Using this knowledge, I was able to edit my blog post for Week 3 through my local machine’s command line. I also contributed to OpenStreetMap adding the names to a couple of pathways in a cemetery. This week I edited a peer’s blog post using the procedure in Collaborative Editing. I fixed spelling mistakes and changed a sentence for clarity. The work flow that is described in the Collaborative Editing Procedure differs from the one described in GitHub Workflow Activity because we spoke about in class that it is smart to reach out to the maintainers of the repository to let them know you are changing a certain aspect, to reduce the risk of merge conflicts.

Comment on your experience with the Git activity that you did in class today. Was it useful? Was it confusing Did you have time to finish? Did you have merge conflicts? Were you able to resolve them?
I enjoyed the activity that we did in class because I got to practice using Git commands a little more and become more familiar with them. I now know what each of the commands mean and feel more comfortable using them, so this activity was very useful. I did not find it confusing and I was able to finish the activity in time. I did have to merge conflicts because my teammates and I were trying to edit the same line of a file. We had to resolve these issues by manually editing which lines we wanted in the file.

What are your reactions to the above on-line readings. Pick one or two that made an impression on you and articulate your thoughts about them.
I really enjoyed reading the article 7 Things That Make a Great Open Source Contribution because it brought attention to things that might get overlooked when you dive into contributing. One thing that I thought was a good tip for contributing to open source projects was to submit one issue at a time instead of combining tasks. This is something that I had not given much thought to but is very beneficial to any kind of project. Before reading this article I would have combined two tasks together thinking that I was hitting two birds with one stone. However, it now makes sense to tackle one task at a time and submit the pull requests separately to make changes easier to understand. Another tip I thought was helpful from this article was to have your pull request reviewed by someone else before you submit it. I found this to be a good tip because it is always good to have a second pair of eyes to proofread any work that you do.