Friday September 16th by midnight.

NOTE: your Release 0.1 does not need to be completely finished before you do this lab.

So far your Release 0.1 has been an individual project. Lab 1 will change that so you begin working on the code in a community. This lab will help you practice the following:

• using Slack to network and collaborate with community members
• thoroughly test and review code you didn't write
• identify bugs, missing features, and other issues in a GitHub repository
• file useful GitHub Issues
• have the open source community test and review your own code
• collaborate with the wider open source community on GitHub

Use Slack to find a partner to review and test your Release 0.1 SSG code. You can work with anyone in the course, just let people know in Slack that you're looking for a partner.

Each student needs to:

1. find a partner in the class via Slack to collaborate with on this lab
2. review, test, and file GitHub Issues in your partner's project;
3. have another student review, test, and file issues in your project. You can review/test the code of the student who reviews/tests yours, or you can work with another student (i.e., you don't both have to be each other's partner). If someone has already reviewed/tested a particular repo, move on to one that hasn't been reviewed/tested yet.
4. fix and close all issues identified by your reviewer

NOTE: even if your Release 0.1 code isn't perfect (no code is every perfect!), or isn't finished, you can still have someone review and test it. Software is never done.

Each project needs to be reviewed and tested by another student. This means doing each of the following steps, and keeping track of what does and doesn't work, what is and isn't clear, etc:

1. find and fork the repo on GitHub
2. clone the fork locally (i.e., to your own machine)
3. follow the instructions in the project's README.md file to set up the project on your machine
4. follow the README.md instructions to run the project in various ways
5. read the code from start to finish, see below.

You are asked to do a detailed review of the project and its code. NOTE: this is not a review of the developer, only the code. Reviews should help us, and our software, get better, and aren't meant to be a tool to belittle or make people feel small or incompetent. Use this process to encourage and collaborate with one another.

Use Slack to discuss things as you work with your partner. For each problem, bug, or improvement you find, file an Issue in the original GitHub repo. Make sure your issues are clear and include enough information to be useful.

Here are some suggestions of steps to take and actions to test, but you are welcome to add more:

• Does the project have an appropriate open source License file? Is the copyright and license information done correctly?
• Was the README clear? Could any info be added to help improve the documentation? Was any of the information wrong? Was any information missing or assumed?
• Were there any mistakes in the README (typos, errors, formatting)? Was proper Markdown used?
• Did you have any problems installing the necessary dependencies (version issues, OS issues, etc)?
• Does the -v or --version flag print the tool's name and version?
• Does the -h or --help flag print a useful help message? Could the help message be improved?
• Does the -i or --input flag allow a file path to be processed?
• Does the -i or --input flag allow a folder path to be processed?
• Does a folder path find all the *.txt files? Does it properly skip/ignore other types of files?
• Is an .html file generated for each *.txt input file?
• Does the generated .html file have the expected name?
• Is the generated .html file located in a dist/ folder?
• Does the generated .html file contain the correct data?
• Is the formatting, markup, structure, etc. of the generated HTML file correct. Is it valid? Test it at https://html5.validator.nu/
• Do the paragraphs in the .txt file get converted to <p>...</p> tags in the .html? Does this process have any bugs (e.g., what if you modify the source .txt file, can you break it?)
• What happens if you run the tool twice, is the dist/ folder removed/recreated?
• Are at least 2 optional features implemented? Are they discussed in the README? Do they work as expected? Can you break them with various input or steps? List those steps/input in your issue.
• Does the program work the way you expect? Was anything surprising?
• Does the program work correctly? Could anything be improved?
• Was anything else missing?
• Did you notice any issues while reading the source code? Are there formatting issues? Could the code be cleaned up? Is it using any incorrect or inefficient methods? Are there better ways to write any of it? Make detailed suggestions in your issues to show how you'd improve it. Saying "this is not good" isn't helpful or enough. Explain why and make suggestions about how to improve.
• Was the code easy to understand? Could it be simplified?
• Are there any features that are missing that you think other users would need?
• Finally, what did you like about the code and/or project? Did you learn anything while reading and testing the code? Make sure your feedback discusses this along with any bugs.

If you get to the end of Step 3 and can't find any Issues to file, try harder! I expect each reviewer to file at least 5 issues for a project this size. Software is never finished, and can always be improved. Remember: an issue can (and ideally should) be very small.

The same way that you reviewed and tested another student's repo for Steps 2 and 3, have another student review and test yours. Support them as they do it, answering any questions they have as they work.

Remember: testing and code review is about helping us write the best software possible. Don't take criticism personally. Everyone gets their code reviewed in open source, and it's normal that you will make mistakes. There's nothing wrong with you if someone finds a bug in your code, or suggests ways to improve things. This is how we build high quality software. You're not a bad programmer if you make a mistake: we all make mistakes. Accept your reviewer's feedback as something meant to help your project get better.

After your code has been tested and reviewed, take some time to fix your issues before submitting Release 0.1. You are free to fix your code yourself, or submit fixes to the project you review. We'll focus on Pull Requests next week, so it's not necessary this week, if you're not feeling ready.

Once you fix the Issues your partner filed on your GitHub repo, comment on them and close.

When you're finished Steps 1-5, write a blog post. In your post, talk about the following:

• How did you go about finding someone to work with?
• What was it like testing and reviewing someone else's code? Did you run into any problems? Did anything surprise you?
• What was it like having someone test and review your code? Were you surprised by anything?
• What kind of issues came up in your the testing and review? Discuss a few of them in detail.
• Provide links to issues you filed, and discuss what you found
• Provide links to issues that were filed on your repo, and what they were about
• Were you able to fix all your issues? What was that like?
• What did you learn through the process of doing the testing and reviewing?

For this to work, you're going to have to leverage your community. Slack will be a critical tool for us all this week, as we try to find others to work with, run into problems, and need help. Be vocal on Slack and don't wait for people to find you.

When you have completed all the requirements above, please add your details to the table below.

NOTE: in order to edit this wiki, you must accept the GitHub invitation you were sent for this repository. If you don't have one, please talk to your professor.

Name	Blog Post (URL)	Repo you Reviewed (URL)	Your Repo (URL)	Name of Student Who Reviewed Your Repo
Example Name	https://example.com/blog/1	https://github.com/example/tool-name	https://github.com/example2/another-tool-name	Example2 Name
Denes Adam Dolhay	https://dev.to/dadolhay/osd600-lab1-2pm1	https://github.com/Ririio/ririio-ssg	https://github.com/dadolhay/dadolhay-ssg	Mario Leonardo
Neil An	https://dev.to/neilan99/working-with-a-partner-on-my-ssg-3j3j	https://github.com/rokaicker/StaticSiteGenerator	https://github.com/NeilAn99/nan1-ssg	Rohan Kaicker
Rohan Kaicker	https://dev.to/rokaicker/osd600-blog-3-lab-1-12l5	https://github.com/NeilAn99/nan1-ssg	https://github.com/rokaicker/StaticSiteGenerator	Neil An
Piotr Drozd	https://dev.to/pdr0zd/open-source-lab-1-4p57	https://github.com/liutng/SSGifier	https://github.com/P-DR0ZD/pdrozd-ssg	Tong Liu
Tong Liu	https://dev.to/liutng/release01-review-4lbl	https://github.com/P-DR0ZD/pdrozd-ssg	https://github.com/liutng/SSGifier	Piotr Drozd
Mario Leonardo	https://dev.to/ririio/how-it-felt-to-review-someones-code-1dnj	https://github.com/dadolhay/dadolhay-ssg	https://github.com/Ririio/ririio-ssg	Denes Adam Dolhay
Chan Dinh (Oscar) Phu	https://dev.to/lostbutton/open-source-basics-3g5	https://github.com/Genne23v/wk-ssg	https://github.com/LostButton/my-button-ssg	Wonkeun No
Rudy Chung	https://dev.to/rudychung/osd600-lab-1-1636	https://github.com/alexsam29/ssg-cli-tool	https://github.com/rudychung/SauSaGe	Alexander Samaniego
Alexander Samaniego	https://dev.to/alexsam29/dps909-blog-lab-1-code-review-33bn	https://github.com/rudychung/SauSaGe	https://github.com/alexsam29/ssg-cli-tool	Rudy Chung
Wonkeun No	https://dev.to/genne23v/first-time-my-code-is-tested-by-someone-else-39c6	https://github.com/LostButton/my-button-ssg	https://github.com/Genne23v/wk-ssg	Chan Dinh (Oscar) Phu
Chen-Yuan Chu	https://dev.to/cychu42/the-experience-of-debugging-a-project-6f7	https://github.com/SerpentBytes/siteit	https://github.com/cychu42/staticSiteCon	Taimoor Dawami
Stefan Frunza	https://dev.to/sfrunza13/collaborating-1mno	https://github.com/mnosov622/simple-ssg1	https://github.com/sfrunza13/SiteGenerationTool	Maxim Nosov & Ivan Gabrovsky
Batuhan Ipci	https://dev.to/batunpc/palpatine-and-rwar-4c3	https://github.com/saminarp/rwar	https://github.com/batunpc/palpatine	Samina Rahman Purba
Samina Rahman Purba	https://dev.to/saminarp/filing-issues-on-github-1jf6	https://github.com/batunpc/palpatine	https://github.com/saminarp/rwar	Batuhan Ipci
Artem Tanyhin	https://dev.to/devils2ndself/sharing-is-key-in-open-source-g1i	https://github.com/Eakam1007/rost_gen	https://github.com/devils2ndself/SSGo	Eakampreet Singh
Eakampreet Singh	https://dev.to/eakam/osd600-lab-1-working-with-a-partner-to-review-an-ssg-51bp	https://github.com/devils2ndself/SSGo	https://github.com/Eakam1007/rost_gen	Artem Tanyhin
Maxim Nosov	https://dev.to/mnosov622/open-source-development-release-01-16p1	https://github.com/sfrunza13/SiteGenerationTool	https://github.com/mnosov622/simple-ssg1	Stefan Frunza
Anshul Gandhi	https://dev.to/anshul137/dsp-909-open-source-lab1-1e2o	https://github.com/a-parris21/ap21-ssg	https://github.com/anshul137/ag-ssg
Arryell Parris	https://dev.to/aparris21/progress-on-release-01-2f5m	https://github.com/anshul137/ag-ssg/	https://github.com/a-parris21/ap21-ssg	Anshul Gandhi
Tymur Levtsun	https://dev.to/myrfion/izyum-not-only-a-wonderful-city-but-also-a-nice-ssg-tool-1ob3	https://github.com/SerpentBytes/siteit	https://github.com/Myrfion/izyum	Taimoor Dawami
Taimoor Dawami	https://dev.to/tdaw/siteit-can-turn-your-txt-files-into-html-3119	https://github.com/cychu42/staticSiteCon https://github.com/Myrfion/izyum	https://github.com/SerpentBytes/siteit	Chen-Yuan Chu, Tymur Levtsun
Ivan Gabrovsky	https://blogforwebdevelopment.blogspot.com/2022/09/lab-1-blog.html	https://github.com/sfrunza13/SiteGenerationTool	https://github.com/IvaniGabrovsky/text-ssg-tool	Stefan Frunza, Taimoor Dawami
Gulnur Baimukhambetova	https://dev.to/gulyapulya/my-first-code-review-and-issues-5i6	https://github.com/rokaicker/StaticSiteGenerator	https://github.com/gulyapulya/SSGulnur	Rohan Kaicker