LoFi diagram for making final graduate application decision

LoFi diagram for approving new Faculty Accounts

LoFi diagram for replying to a message

LoFi diagram for page template

LoFi diagram for form boxes

LoFi diagram for info boxes

LoFi diagram for tables

LoFi diagram for Application Evaluations

Sprint3 Summary

At the end of our sprint 3, we completed almost all of the features that we set out to do, minus two. One of these is a sorting feature that we simply did not have enough time to finish, and the other was 3rd Party Authentication, which was a bit more complicated. Development of that feature was planned and began, but due to Twitter restrictions with retrieving emails requiring a privacy policy as well as another document, it meant we would not be able to request their email. This was something we had not foreseen in the original creation of our accounts table, and trying to change the account model so that we could allow an account not to have an email would be too difficult given our implementation. It would not make fundamental sense to change that either, as there are no other uniquely identifying features of an account when it is created.

Overall, there were no significant issues during this sprint and the process is quite more fleshed out than it was previously. We did encounter a couple of minor errors, however. One where a pull request was made on a branch, which had no errors, but was behind the main branch and once it merged had caused select functionality to break. We thought that GitHub branch protection would require branches to be fully up to date and we did have the option selected, although it still seemed to slip by somehow. It was later fixed as we were able to revert the branch and create a new one. Another minor issue was we noticed that previously we had some views that did not have login as a requirement that should have from sprint 2, so we created chores to go through and fix each issue individually.

One of the major process improvements we made this sprint was implementing commit templates. Previously, we implemented a pipeline, main branch protection, and pull request templates, but decided it would make sense to take it another step to implement a commit template to improve the quality of our commit message, especially after feedback given during class stated commit messages were of poor quality, which ours were. We decided to have different commit message tags, Feat and Fix. Feat would be used when we were updating a feature with functionality, and Fix would be used when any preexisting functionality would be changed so that it would function as intended.

Finally, at the end of the project, there were still a few features, but not a lot, that we left in the icebox. They were features that originally were laid out during the beginning week of our project, but as we had created a lot of features, it was inevitable that not all of the functionality could be implemented due to the short timespan of our project.