Changes

You are tasked with building a command-line tool for finding and reporting dead links (e.g., broken URLs) in a set of filesfile. Users might use your tool to help locate broken URLs in an HTML page, for example. Your tool can be written in any programming language.

This first release is designed to expose you to the common workflows and tools involved in contributing to open source projects on GitHub. In order to give every student a similar learning experience, we will all be working on the same project.  This first release is also aimed at putting you in the role of "open source creator" and later "open source maintainer." You will use the code you write in this assignment in subsequent labs during the course to explore various aspects of open source work. NOTE: in subsequent releases, students you will have more freedom to work on different projects.

In addition to the actual code you will write, the ultimate goal of this first release is to help you gain experience in many aspects of open source development and contribution, specifically:

* One Issue filed for a bug fixGitHub Repo exists* One Issue filed for a new feature (on a separate repository from the bug fix)GitHub Repo contains LICENSE file* Professional and respectful interactions in your issue GitHub Repo contains a README.md file with clear information on how to use the maintainer.* Proper Pull Requests are completed for both Issues you filed** An Issue should be filed before your create your Pull Request. The Issue must have a complete subject tool and description all of the problem or change you believe needs to be made.** The Pull Request should reference the Issue Number in its description (e.g., "Fixes #7: Add feature to do ...")features** Changes must be made on a new branch (e.gGitHub README.md is free of typos, if you are fixing Issue 123spelling mistakes, use issue-123 as your branch name)formatting or other errors ** Proper code to fix your IssueGitHub Repo contains project's Source Code** Source Code follows style of the original repository author** Co-ordination with other student/community Pull Requests. Make sure you don't duplicate another fix or change that someone else has already done.** All review comments have been addressedimplements all Mandatory Requirements, and subsequent commits have been added to correct any problems. Ideally your Pull Request each one is merged.Complete and Working* Reviews Source Code implements 2 of Other Student's Pull Requests** Compare the Pull Request to the related Issue it is trying to fix. Has everything been covered?** Confirm that there Optional Requirements, and both are no other related Issues or Pull Requests that might conflict with this Pull RequestComplete and Working** Review Source Code is well written (consistent formatting, code and other changescomments, making comments and suggestions about any improvements you can seegood naming, or other issues that need to be addressedetc)* Blog Post** Discussion of documents the changes you made. What was your process? What did you learn? What would you do differently next timeproject, or what worked and you would do again?** Link how to the Issues you fileduse it, and discuss the bug/problem/addition you wanted to address.** Link to the Pull Requests you createdwhich features it includes, and discuss the fix.** Link to the Pull Requests you reviewed, and discuss what you did and found.** Discussion shows examples of what you did how to address your review comments.use it** Evidence of Community Involvement. Could be Issues you worked in Blog Post contains link to help others, help you gave people on Slack, mentoring or other help you gave people in person. How did you engage with the community of developers working on Filer?GitHub repo