I finished my Static Site Generator called OpenSSG. I tried to give it to someone to test with high quality. At least I wish it would not have a bug. But it had to be given to my partner for testing.
How did I find my review partner? I chose Java for my project, and I saw someone was making SSG with Java on Slack channel. I felt that it's a great opportunity to see someone else's object-oriented programming and how to use Java methods! So we teamed up to review each other's code. Later I found out that he changed Java to Javascript. But it doesn't matter. It is still a good opportunity to see the same project written in a different language. He also told me it's a win-win for both of us. I was happy to hear that!
I was a tester in my first 4 month co-op in Kobo. It's important to understand the scope and the code in a higher level. So that I can set a plan to how to test it. Since we both implemented a similar feature set, it isn't difficult to what to test. So I created some files and folder to test it. The other thing is to try to find some edge cases by looking at the code. There may be a logic that is missing or error case that I experienced while developing.
Next step was to fork the project and installed it on my local. It didn't take so long but I encountered a problem that one of the npm package was not installed. It wasn't a big deal to handle it. Instruction was npm -i yargs, but I had to input npm i yargs. I think it was just a typo. And I actually found same issues on my README! I realized that my poor documentation could confuse many people, and they get frustrated and go somewhere else. So writing precise documentation and organizing nicely are really important for open source project.
Issues that I need to fix for my OpenSSG...
- https://github.com/Genne23v/wk-ssg/issues/1
- https://github.com/Genne23v/wk-ssg/issues/2
- https://github.com/Genne23v/wk-ssg/issues/3
- https://github.com/Genne23v/wk-ssg/issues/4
- https://github.com/Genne23v/wk-ssg/issues/5
I guess it wasn't a good feeling for anybody that someone raised an issue on my board. Maybe because it's just a beginning of this open source project. Like we get so nervous when we go on a stage in front of many people for the first time. Later we handle this situation much better when we get used it. Eventually issues and comments are all valuable to my project. I was aware of some issues like translating non txt files, but my partner could find more such as insufficient documentation, hard-to-read command guide when entering java OpenSSG -h, spaces in href link, and some edge cases as well. --version, --help are not core features, but it is pretty embarrassing to provide such a poor version and help information.
And I did the same thing for my partner. Here are issues that I posted.
- Unavailable option can be taken
- server.js ... didn't work for me
- --output option doesn't work
- html formatting is difficult to read
- npm -i yargs doesn't work for me
I tried to give him enough details of each issue, and format nicely to read easily. Because that's what my colleagues do in my co-op! I hope my issues helped him too.
I think me and my partner all had very valuable experiences. I think this lab is simulating what we actually do in open source development or in real work. I never used issues tool on GitHub. But it's a great way to manage and discuss issues. In addition, I'm getting more comfortable to write markdown document. I always had to look for how to format markdown. Now I don't have to search that much which is another improvement to write a README faster!
Top comments (0)