Feature release 0.48.0 of the GitHub Action for Checking Spelling

This is a rewrite of the change log for the release of the GitHub Action for checking spelling. The action is used to check spelling in various files in a GitHub repository. I had a small backlog of PRs, but was lacking both time and motivation to review and process. The problem was not with the PRs, but with me. They had some complexities and a lot of things I had to digest. At the same time my work was and is busy and also filled with complexity, decisions and high workload. Then I received another PR, which was pretty basic. It was a small change, but it was a change I could understand and process without much effort. That PR was #234 from @brooke-hamilton. The other day I was explaining a mental trick I some time use when my TODO list or workload is overwhelming: Pick something light and easy to do. Something that is not too complex and does not require too much effort. It can be a small task, get it done and then pick the next and all of sudden you are changing gears and are gaining momentum. This was actually exactly what happened here. The original PR from @brooke-hamilton was introducing the tool version information output for: aspell pyspelling I knew that for PR #224 from @funkill in the backlog, hunspell would be introduced. PySpelling supports both aspell and hunspell, I had just never got around to implementing it in the GitHub Action and it's Docker image. So I commented on the PR from @funkill to include the version information on hunspell and and started my review of the other parts of the PR. The PR was very basic and straightforward, so I could easily understand it and with it could come support for hunspell and two new languages: Russian Ukranian Also for aspell so no matter the spell checker used, the language support would be aligned. English German Spanish French Russian Ukranian I sent some feedback to @funkill for updating the documentation with an example on how to use the new parameter: spell_checker and moved on to the next PR. The last PR was a proposal to improve the automated building in regards to the Docker image. Something I have been wanting for a long time and this is described in issue: #80. The PR: #218 from @shyim addresses a request raised by @shyim via #193, for arm64 support for the Docker image. I sent some feedback to @shyim and he complied quite fast with the requested changes and I was able to merge the PR. There is was sad thing about the PR and it's merge and that was that is resulted in me closing PR: #108 from @sxd was closed. He really tried to help me with the automation and addressing issue #80, but unfortunately the process got stuck. The contribution from @sxd was and is highly appreciated since it helped to understand the problem area and hopefully a possible solution, since we are not completely there, but we are closer to fully automated build and release and closing of issue: #80. I do not like to close PRs like that, I always think a lot about the human behind the PR (Dependabot I like your PRs just as much), but somebody put effort into proposing a change, not matter how big or small, they took the time and they shared, which is the essence of the open source community IMHO. I hope I will be able to pick up on issue #80 and with a combination of the contents of PR: #218 and #108 will be able to get the build and release process fully automated. After this minor emotional slide ride, I went back to the PR for hunspell and the extended language support. I started to do some reviewing and testing and merged the recent changes into the branch. After a lot of tests I decided to address the requested changes myself and merged the PR. Lessons learned: Stale PRs is not a good thing, since the author might have lost context, interest or motivation, so reviewing after months and months os not a good idea Unmerged, but closed PRs might does not feel good, but they are still valuable in regards to the content and perspective, I do however prefer to merge proposals and changes Small and targeted changes are easier to review and process than big and complex changes and is a good way to get started and they do not go stale as easy Thanks to: @brooke-hamilton for the PR @funkill for the PR @shyim for the issue and PR @sxd for the PR and attempt to address an issue and @mitelg for the ping Release 0.48.0 of the GitHub Action for checking spelling is now available, still via DockerHub. Next step via issue #80 is to get GitHub packages to work and then migrate away from DockerHub.

Apr 2, 2025 - 16:02

Feature release 0.48.0 of the GitHub Action for Checking Spelling

This is a rewrite of the change log for the release of the GitHub Action for checking spelling. The action is used to check spelling in various files in a GitHub repository.

I had a small backlog of PRs, but was lacking both time and motivation to review and process. The problem was not with the PRs, but with me. They had some complexities and a lot of things I had to digest. At the same time my work was and is busy and also filled with complexity, decisions and high workload.

Then I received another PR, which was pretty basic. It was a small change, but it was a change I could understand and process without much effort.

That PR was #234 from @brooke-hamilton.

The other day I was explaining a mental trick I some time use when my TODO list or workload is overwhelming:

Pick something light and easy to do. Something that is not too complex and does not require too much effort. It can be a small task, get it done and then pick the next and all of sudden you are changing gears and are gaining momentum.

This was actually exactly what happened here.

The original PR from @brooke-hamilton was introducing the tool version information output for:

aspell
pyspelling

I knew that for PR #224 from @funkill in the backlog, hunspell would be introduced. PySpelling supports both aspell and hunspell, I had just never got around to implementing it in the GitHub Action and it's Docker image.

So I commented on the PR from @funkill to include the version information on hunspell and and started my review of the other parts of the PR. The PR was very basic and straightforward, so I could easily understand it and with it could come support for hunspell and two new languages:

Russian
Ukranian

Also for aspell so no matter the spell checker used, the language support would be aligned.

English
German
Spanish
French
Russian
Ukranian

I sent some feedback to @funkill for updating the documentation with an example on how to use the new parameter: spell_checker and moved on to the next PR.

The last PR was a proposal to improve the automated building in regards to the Docker image. Something I have been wanting for a long time and this is described in issue: #80.

The PR: #218 from @shyim addresses a request raised by @shyim via #193, for arm64 support for the Docker image.

I sent some feedback to @shyim and he complied quite fast with the requested changes and I was able to merge the PR.

There is was sad thing about the PR and it's merge and that was that is resulted in me closing PR: #108 from @sxd was closed. He really tried to help me with the automation and addressing issue #80, but unfortunately the process got stuck.

The contribution from @sxd was and is highly appreciated since it helped to understand the problem area and hopefully a possible solution, since we are not completely there, but we are closer to fully automated build and release and closing of issue: #80.

I do not like to close PRs like that, I always think a lot about the human behind the PR (Dependabot I like your PRs just as much), but somebody put effort into proposing a change, not matter how big or small, they took the time and they shared, which is the essence of the open source community IMHO.

I hope I will be able to pick up on issue #80 and with a combination of the contents of PR: #218 and #108 will be able to get the build and release process fully automated.

After this minor emotional slide ride, I went back to the PR for hunspell and the extended language support. I started to do some reviewing and testing and merged the recent changes into the branch. After a lot of tests I decided to address the requested changes myself and merged the PR.

Lessons learned:

Stale PRs is not a good thing, since the author might have lost context, interest or motivation, so reviewing after months and months os not a good idea
Unmerged, but closed PRs might does not feel good, but they are still valuable in regards to the content and perspective, I do however prefer to merge proposals and changes
Small and targeted changes are easier to review and process than big and complex changes and is a good way to get started and they do not go stale as easy

Thanks to: