For Hacktoberfest 2024, I worked on four pull requests.
Pull Request 1 - intel/cve-bin-tool
My first pull request wasn't even actually part of Hacktoberfest - I got a bit too eager and made my pull request too early (Made up for it later with another PR). This was a small contribution to the documentation for a project called cve-bin-tool by Intel - I updated the release notes page of the documentation to add notes for the latest few releases by copy pasting the changelogs from GitHub.
CVE Binary Tool Release Notes page hasn't been updated for v3.3 and now v3.4 was just made
#4458
The CVE Binary Tool Release Notes page wasn't updated for v3.3 and now v3.4 has been released.
Steps to reproduce the behavior:
- go to https://cve-bin-tool.readthedocs.io/en/latest/RELEASE.html
- see the last version to be documented is v3.2
Expected behavior: that v3.3 release would have been documented Actual behavior: release notes are missing for v3.3 ( and please also add in v3.4 now)
N/A
I was asked to do some v3.4r* preliminary testing and found the options/parameters were changed since v3.3 so please make sure when the documentation is updated for 3.4 that the change in parameter/options for the tool command are documented and also the fact that with the move to *.json triage files -previous users can just copy their *.vex triage file to *.json and it will work. Thanks so much!
This was a very relaxed introduction to the world of open source. I was able to get accustomed to the GitHub flow - forking, branching, creating a pull request, getting it reviewed, iterating on it, and getting it merged. I also learned I shouldn't forget to read the contributing docs.
docs: add missing release notes to RELEASE.md
#4464
Fixes #4458. I removed the GitHub changelogs and any references to them, since the notes for the previous releases don't include them. I also added a brief release note for release 3.4rc3 which didn't have one. Please let me know if you'd like anything changed.
I also completely screwed up the Git history while working on this issue and exploring the rebase command and had to learn how to fix my mess, and the fact that I was able to taught me how incredible Git really is.
For my next pull request I wanted to start contributing actual code. I signed up for adding a feature, which I'll talk about later in this post, but I ended up putting this off for a while. Instead, after realizing I should gradually work my way up to a feature, I reined in my ambitions and signed up for a bug fix.
Pull Request 2 - planetarium/libplanet
This second pull request was to a project called libplanet. The project had a script that would generate a tag for their releases based on the date, but the date wasn't zero padded, leading to the tags not being chronologically sorted. I'd solved this kind of problem in my previous courses so I figured this would be a good place to start contributing actual code.
Invalid order of NuGet dev releases
#3955
When I looked at Libplanet's NuGet dev releases, they were not well ordered by release date.
It is because the version suffix is generated without zerofill. (20240901 with zerofill, 202491 without zerofill)
To resolve this issue, you can amend scripts/determine-versions.js file. You can see the logic to determine a version suffix at the below lines:
You should update the part to declare ts variable.
You can test the script easily by running the node scripts/determine-version.js command.
$ node --version
v20.4.0
$ node scripts/determine-version.js
VersionPrefix: 5.3.0
VersionSuffix: dev.202491004320+f6cd63d
PackageVersion: 5.3.0-dev.202491004320
VersionType: dev
If you amended well, it expects to generate VersionSuffix: dev.20240910010203+xxxxxxx for the date (year: 2024, month: 9, day: 10, hour: 1, minutes: 2, seconds: 3)
This issue wasn't hard, but there was a little bit of discussion regarding improving my code's formatting.
fix: add zero padding to version timestamp
#3957
Fixes https://github.com/planetarium/libplanet/issues/3955. I declared variables to store each formatted portion of the date for readability. Please let me know if you'd liked anything changed.
In hindsight, my code was pretty ugly, so this was exactly the kind of feedback I was hoping to receive from maintainers.
Pull Request 3 - ghostfolio/ghostfolio
My third pull request was for that feature I'd signed up for before my second pull request. The feature was to add a tooltip to a treemap chart representing the user's investment portfolio. The tooltip would show the value of the element being hovered on.
[Feature] Set up tooltip in treemap chart component
#3808
The goal of this issue is to set up a tooltip in the treemap chart component which is based on chart.js.
- Pass
[baseCurrency]="user?.settings?.baseCurrency"to<gf-treemap-chart />in home-holdings.html - The tooltip should display
valueInBaseCurrencyfromholdingsif available along with the user's currency (baseCurrency) - Try to use getTooltipOptions() for the style
This issue was in a huge monorepo and involved several technologies I'd never used before like Angular, Docker, Chart.js, and Nx. This was much larger in scope and the amount of effort required compared to my previous issues, and really required me to dig in and dedicate time to it. I got scared off from working on it a couple times, but I really wanted to get it done and I managed to persevere and finish the job.
Feature/Set up tooltip in treemap chart component
#3897
Fixes #3808.
I based my implementation off of the tooltip in portfolio-proportion-chart.component.ts. Please let me know if you'd like any changes.
This issue taught me a lot about reading code in large repositories, understanding how they're structured, and how I can leverage the existing code to work on my issue. It also gave me a huge confidence boost - I was very proud to be able to close this issue even though it took me weeks.
The maintainer also let me know of a follow-up issue, which ended up being my third "official" pull request for Hacktoberfest, but since it was smaller in scope than the last one I've chosen not to count it as part of my four main pull requests.
[FEATURE] Extend tooltip in treemap chart component by name
#3904
The goal of this issue is to extend the tooltip in the treemap chart component by adding the name (or symbol as a fallback):
return [
// `${name ?? symbol}`,
// value or percentage as before
];
Get inspired by the GfPortfolioProportionChartComponent.
The maintainer for this project actually ended up finding and liking my blog post for this PR, which was pretty cool.
Pull Request 4 - bytechefhq/bytechef
For this final issue, I worked on a low-code API integration platform called ByteChef which used components to connect various APIs to each other to create a control flow and pass data between them. My task was to add an action (a method) to a database component that would update a row in a table.
Baserow - Update Row action
#1645
Implement the Update Row action for the Baserow component to allow users to modify specific rows within a table in their Baserow database.
Action properties:
- table id - id of the table for which you want to update a row
- row id - id of the row you wish to update
- user_field_names - A boolean indicating whether the field names returned by this endpoint should be the actual names of the fields
- fields - a map of fields and their new values for the table. This property specifies the data to be updated in the row, allowing users to change multiple fields in a single operation.
Ouput:
- row - updated row object containing all the data fields and values associated with the row in the specified table
Documentation Reference: https://baserow.io/api-docs
The reason I picked this issue is because the project was in Java. I've wanted to work with Java for a while because despite it's popularity I haven't had much exposure to it. Meaning with this issue, I was working in a completely new language ecosystem. Luckily, the very week before, I'd started learning a bit of Java on the side. I still had to learn some tricks, like managing installations of different versions of Java and Gradle - SDKMAN! really came in clutch here, but to use this tool I had to work in WSL, because it only supports Linux, which meant I did have to figure out how to set up IntelliJ in WSL, but that was fine with me because my existing development setup for JavaScript is already entirely WSL-based.
For this issue, I was able to lift most of my code from existing source code, so implementing the actual feature wasn't very challenging. I did have to write an accompanying unit test, but again, I was able to copy most of it and just modify it to work with my newly added action. I thought about it a little, and my speculation is that it's because the issue was marked a "good first issue", and making new contributors go dig through similar code and just apply it somewhere else is a good way of giving new contributors valuable insight into the project's inner workings without overwhelming them.
Create Update Row action for Baserow component
#1656
Fixes #1645
- New feature (non-breaking change which adds functionality)
- This change requires a documentation update
- Tested with BaserowComponentHandler definition test, which was updated to accommodate the new action.
- Manually tested action through client:
- [x] My code follows the style guidelines of this project
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- No comments deemed necessary since the existing action doesn't include comments either
- [x] I have made corresponding changes to the documentation
- [x] My changes generate no new warnings
- [x] I have added tests that prove my fix is effective or that my feature works
- [x] New and existing unit tests pass locally with my changes
For this issue I'd say the challenge largely came from having to get accustomed to an unfamiliar language ecosystem more so than the actual programming. It was cool to be able to experience the process of working with Java and Gradle and seeing how unit testing is handled in Java.
Closing Thoughts
One of my goals for Hacktoberfest starting out was to contribute to large repositories, and I think I succeeded - I'm satisfied with the scale of the projects I was able to contribute to, but as a result I think my contributions ended up being less significant in scope than some of my peers who chose to work on smaller projects.
I also got a chance to work with some technologies I've wanted to check out for a while but haven't had the opportunity to - namely Angular and Java. I got some helpful feedback on my code formatting too - I've learned to use whitespace and blank lines instead of squishing everything together. But more than anything, I'd say these last four(-ish) weeks really demonstrated to me how much stuff you can just pick up and work on if you're willing to wrestle with it for a bit. You don't need to go and read the entire Angular documentation and go do an Angular side project to be able to work on an issue with Angular.
Go out there and just start working on stuff and you'll be surprised just how quick you can learn and how much you can accomplish.
Top comments (0)