This week in my open source development course I practiced creating and managing pull requests to another person's project and my for my project textml.
For my part, I was working on the Waypoint project located here at https://github.com/rabroldan/Waypoint which is a text-to-HTML converter that allows for custom CSS styling and allows live creation and editing of files submitted to the program.
Adding a Feature
My task was to add support for converting markdown/.md files to HTML and this started with creating a Issue. After receiving approval I then forked the repo and created an issue branch to add my changes located here: Forked Issue branch.
I then began making the changes. My main goal was to not overly change the design of the code that was already there so I made sure that any changes were similar to how the project owner's code was made. I ended up creating a new function that would process any .md files that were passed to the program or created by the program.
After creating the function I had to find examples of when the program was checking the file type and have it also check for a markdown file which made me edit multiple points around their code so that it would correctly convert .md and .txt files to HTML in there respective locations.
Making a Pull Request
Once this was done I tested the program under different scenarios (folder, single file, creating a new file, and a new folder) with markdown files and made sure that it would properly be converted and then pushed all the changes to my branch and submitted a pull request which can be seen here.
As can be seen, it was reviewed by the owner and merged into the project after we had a small chat about some of the features on Slack.
Handling a pull request
My project on my GitHub here which is a text to HTML converted also received a pull request to add markdown file/folder support.
Just like my previous process they:
- Forked the repo
- Created an issue branch
- Added changes to the branch
- Submitted the branch as a pull request
Pull requests can be found here
After receiving the pull request I went to work on testing if it would work and found that it had a lot of problems:
It had some oversights that caused the program to crash, it wasn't saving files to the correct location, and it would only convert a single .md file and had no directory support.
I opened a thread on the pull request explained some of the issues that were present with their implementation and then asked them to fix them before I could merge.
Later, they updated their commit branch with changes that fixed their previous issues. After a couple more fixes that I required from them, I merged the new code into my repo.
Overall I liked the whole process I just would have preferred if the contributor stuck to how my code was formatted and operated but their additions were solid and they kept most of the continuity of my program intact.
Final Thoughts
Overall this process was interesting. At first, I had a couple of problems understanding how best to implement the code for the project I was working on as I found the program to be written very uniquely and different from what I was used to.
After running and testing the different outcomes I understood where I needed to add something. I also wanted to make sure that I didn't interfere with the original design of the code too much
Being new to Python I learned a good amount from reading the code. I saw a very good use of the argparse Python library which has a much more efficient way of handling command line arguments and I plan to implement it into a future version of my program.
I also learned a good amount about creating and managing pull requests including linking issues that automatically close when pull requests are complete.
If I were to do something differently next time I would ask for more info on how the maintainer would like me to modify their program so I could know how much I could drift away from their design.
Top comments (0)