Contributing 1: Researching and documenting my first contribution


Before I contribute to my chosen project I want to test out my knowledge in a smaller contribution project to clarify I understand the process. 

I surfed through sites recommended to us in this unit, such as “first timers only” and goodfirstissues.com

First- timers: first ever contribution 

I discovered the “first ever contribution” GitHub repo from the “first timers only” site. 

Here the contributors are encouraged to write their name on a file known as contributors.md

Link to GitHub repo: https://github.com/firstcontributions/first-contributions#first-contributions

Understating more about the project:

I noticed this project has encouraged over 24,000 contributors to take part in the project, which shows how large the community for this project is, as it only seems to grow. Since this is for users who have never contributed before this demonstrates how impactful open source is and how willing people are to take part in it, no matter what level.

To guide my contribution, with step-by-step instructions, which eases the process, making this more motivational and leading to a more efficient and productive approach. The instructions are accessible in multiple languages, accommodating participation from a diverse global community online.

Another important thing to note is this particular project involved an MIT License, which grants the user freedom to use, modify or share software. This licensing choice shows how open and inclusive this project is for new contributors. Which is very beneficial for someone like me who is very new to open source contributions.

I am very excited about this project as I believe it will help me understand more about contributions, as it can help me identify my strengths and weaknesses in open source contributions before I begin my main contribution for this unit.

Link to code of conduct: https://github.com/firstcontributions/first-contributions/blob/main/CODE_OF_CONDUCT.md

My Project:

I began by forking and setting up the GitHub repo, I used GitHub desktop to open the file onto my computer. I used my HTTPS key to clone my fork. 

I attempted this all on GitHub desktop previously and found it much easier using the terminal. 

I created a new branch called “Annies_branch” in the directory of the cloned repo by using “cd first-contributions” and then “git checkout -b Annies_branch”. I also cloned the repo in my GitHub desktop and opened the documents in my VSCode.

I first read the code of conduct and instructions given in the readMe.md file. 

I added my name as a link to my GitHub profile link.  

I added the changes to the staging area and committed them before pushing them to the forked repository on GitHub. 

As you can see in the pictures, on the browser my contribution would not merge automatically, this doesn’t happen to affect me though and my pull request was successfully sent through and passed all checks.

Link to pull request: https://github.com/firstcontributions/first-contributions/pull/83822

This did teach me more about the different between merging and pull requests:

To summarise….

  1. Automatic Merge: The automatic merge attempts to merge changes from one branch into another without any manual meddling. However, if there are conflicting changes between the two branches, GitHub cannot automatically determine what keep and what to neglect.
  2. Pull Request: A pull request proposes changes from one branch (usually feature) to another branch (usually main) in the repository. When GitHub says it can create a pull request after it can’t automatically merge, you can still request your changes. But often a manual checkup is needed to review and approve your contribution changes.

This has helped me gain insight on the difference between merging and pull requests, and understanding which is needed uncertain scenarios for contributors, which is something I will take into account next time I decide to contribute to an open source project.

Overall I learnt a lot from this first contribution, I gained a direct understanding on the protocol in open source code for contributors to follow, including forking, creating branches, and attempting a pull request. I also discovered the difficulties in merging and the difference between merging and pull requests when contributing. This has helped bring confidence for my next or final contribution. However, communication was not necessary due to the step-by-step guide and the simplicity of the task, I wanted to be able to understand the community of an open source project, this is something that will be considered for my next contribution.


Leave a Reply

Your email address will not be published. Required fields are marked *