Skip to main content

Featured

Week 12: Release 0.4 Part: 3

Release 0.4 Part 3 This is going to be my final post for this class which covers my final update on my Release 0.4. Earlier this week I made a PR that ports SearchBar to NextJS but I'm still waiting for it to be reviewed some more. I've had some feedback that I have implemented and have also requested a review again. Overall this Release went pretty smoothly for the actually GitHub side of things like setting up the issue, making the PR, and so on. In Release 0.3 I wasn't so certain on how this process happened with Telescope, but now I never had these issues for 0.4. Issue #1470 Fix #1470: Port SearchBar from Gatsby -> NextJS #1503 Did I Meet My Goals? Going into this release I had two main goals: 1. Setup the Issue/PR with no issues 2. Learn about NextJS I feel like I meet both of these goals at the end. I had no issues setting up my branch, updating my master, making the issue, making the PR, and following through on review comments so far. When it comes to learning m
Post a Comment
Read more

Week 4: PR#1

 Release 0.2: Pull Request #1

Going with release 0.2 for this class we have to take part in Hacktoberfest to make four pull requests in different repo's. I decided to start with a simple issue to resolve this week so I could get used to the whole system of finishing a pull request.

I ended up adding a .editorconfig file to a project that had been asked to be implemented. A .editorconfig file defines the styling rules developers need to follow for different kinds of files in a project. This really helps in a larger project since everyone codes differently.

The project I worked on was a library that implements a Directed Acyclic Graph (DAG) and some related functionality. Here's the repo:  DAG's and here's the issue: Add .editorconfig #6

To start I commented that I would like to work on this issue. A few hours later I got a reply that gave me the go ahead to work on it and I was assigned to the issue. The maintainer then gave me some more information on what exactly he wanted. Spaces instead of tabs, two spaces for main indentation, and double quotes for string literals.

I then replied and got to work. Since I'm working in visual studio code I had to install a plugin to allow me to create and view .editorconfig files. From there I researched how to set these up as I've never worked on this type of file before. Once that was done I looked at the contributing rules again to see how to properly submit my pull request the way he wants. All pull requests followed a certain pattern for the name of  "type: commit", so my pull request was titled: "feat Added .editorconfig file. Fixes Issue #6". Normally I would make my own branch but the contributing rules stated I must work on my master so I followed that rule.

root = true

[*]
charset = utf-8
end_of_line = crlf
trim_trailing_whitespace = true
insert_final_newline = true
indent_style = space
indent_size = 2
quote_type = double

[*.md]
trim_trailing_whitespace = false

Here's the pull request: PR

The maintainer accepted my PR without suggesting any changes and said it was suitable.

What Did I Learn

From this I learned how to create and edit a .editorconfig file. I now understand the purpose and need for these files in any project with multiple developers working on it. Actually working on a real world project and submitting a pull request was a challenge because I was not used to the whole process but now I feel more confident with the process. 

Extra

I actually worked on 2 different repo's. The first I never had the maintainer reply to me, but I did make a pull request for the issue following their rules. Here's the issue. The second repo was the one I talked about above.

Comments

Post a Comment

Popular Posts