Due: Sunday, February 19 at 11:59 pm
For the next set of deliverables, our project will need to have some content. Part 2 of this homework is simply work on the project. But as we discussed in class, as we get our project off the ground we’re going to focus on getting a minimum functional product, rather than something perfect and bug-free. So we will accrue technical debt by making deliberate choices to take shortcuts and add hacks rather than trying to do everything the “right way” from the start.
As we do this, we will want to track the debt by creating and scheduling tickets for us to do later. These tickets will include features we might add, bugs we find and will want to fix later, etc. With a collection of tickets, we can then start to plan out the work for our library and have a better view into what major hurdles or deliverables are ahead of us.
In this part, we will setup the following tools on our library repository:
We will then start to use these tools to lay out the next few projects for the course.
By default, GitHub sets your repository up with some default labels. Feel free to adjust the colorscheme to your liking, then add the following three labels:
Then add the following milestones:
Once you’ve setup these labels and milestones, add 5 initial issues:
With a larger project, a team of people, or at a company, we might want to build a kanban-style work management board around our GitHub repo. For this course, I don’t care if you use this tool or not, but I think its useful to know how to set one up. For your repository, setup a basic kanban board and add the 5 issues you opened previously to the “Todo” column.
To make it easier for users and contributors to submit bug reports and request features, let’s setup some issue templates. Use GitHub’s builtin suggestions to setup two templates.
Finally, let’s add an issue badge to our README.md. Using shields.io, setup a new badge and open a Pull request againts your repository adding it to the README.md after the license.
Work on the project. For this part, you should aim to do about 5 hours worth of work, and to have at least 5 testable things. This is relatively loosely defined because projects will vary, but you should aim to have at least something you can show as a proof-of-concept. As an example, if you were building a library to do some form of web scraping in python, a good first cut would be:
At this stage, the data could still be messy, the parser might not handle edge cases, and the functionality might only extend to a single page out of N total other pages you’d like to scrape. But this will be enough to demonstrate the viability of the project and enough for us to build out static analysis, testing, packaging, and documentation. For any outstanding bugs, features, or parts of the codebase to rework or rewrite, just create issues for now and we will deal with the technical debt at a later date.