Do Not Fix Bugs Reported in Your Open Source Projects
Related
More from code.dblock.org | tech blog
Should you work on week-ends? tl;dr Only 2% of my paid work was accomplished on weekends, which matches my opinion that you should not. Collecting Data First, let’s try to use data and find out whether I actually work on week-ends. I’ve contributed to the open-source OpenSearch since 2021 as part of my day job, so I tried looking through my...
Most paying customers expect a certain level of (paid) support. One opens a ticket, gets a response, and any issue can be resolved. How does “support” work in open-source? My rule of thumb is to meet users where they are. GitHub projects have issues, but opening an issue to ask a question is generally frowned upon. Therefore, in JNA, we have a...
I found it annoyingly non-trivial to add a spell checker to this blog. For now, I settled on GitHub Spellcheck Action that uses PySpelling on files changed in the commit or pull request as described in this blog post. name: Check Spelling on: [push, pull_request] jobs: check: runs-on: ubuntu-latest steps: - uses:...
Since my first day in AWS 5 1/2 years ago, I’ve been experimenting with keeping a CHANGELOG of everything I do, available for everyone at the company to see. I wrote about it here. If you work at AWS, use the URL in the screenshot below to find it. I wrote a little script to try and classify where I spent my time. Here are some quick, very...
Every active open-source project grows a lot of low hanging fruit. Encouraging project users to harvest some of the yield can be a great way to engage and retain new contributors. Here are some ideas, mostly borrowed from Barani, for low-hanging work items that you can propose to anyone engaging in your project. Help Wanted, Good First Issue and...