Sprint 2 Expectations

This sprint is about arriving at a well implemented, tested, and thoughtful production-quality feature.

Expectation 1: Polish for End-user Stories

The interactions designed for your primary persona should be smooth and polished. This includes user-friendly interactions and form design, friendly error messages (or, even better, designing away the ability for there to be errors!), and thoughtful user experience considerations such as clear user instructions and being sure everything visible works. If there are features you added user interface elements for that are not yet implemented, you should remove them by the end of this sprint. Everything visible should be functional.

Additionally, polish should be added to the implementation wherever possible. You are encouraged to move through each story of your feature from end-to-end, including docs and tests, and improve your implementation wherever possible.

Expectation 2: Improve the Information Design of your Technical Specification Doc

Take another pass at your team’s technical specification documentation in docs/ and be sure it is written for a developer to read. You should avoid language such as, “we would direct new developers to X and give them…”. Your documentation is written directly addressing a developer, not the course staff. If it helps, imagine you are writing for a future COMP423 student working to understand and extend your feature.

Choose plain language where possible.

Improve the formatting of your document to be sure it is easy to read and understand. Make appropriate use of paragraph text, versus merely bulleted lists, where needed. Choose heading text that is appropriate for your feature and the audience. If information would better be represented with a table, use a table instead of a list. This list is not exhaustive. Use your best judgement to make your documentation a great artifact you can be proud of and share with future employers.

Finally, include screenshots of your feature from the end user persona’s perspective with narrative of what is being shown. To add an image to your project, place it in the docs/images directory.

Include an authors section toward the top of the document listing the names of everyone in the group with links to their GitHub profiles.

Expectation 3: Project Management & Standards

These remain the same as in the previous sprint.

Issues are kept up-to-date on project boards and closed out when completed. Changes are merged into stage exclusively via pull requests with meaningful code reviews. Commits merged into stage are descriptive following best practices of commit messages.

Angular Material components are used anywhere there are inputs, tables, tabs, etc. If there is an Angular Material component that achieves what your user interfaces need, you should use it in the frontend rather than standard, or bespoke, native HTML controls.

Backend service classes should be tested using Pytest with mock data. Backend service classes and methods should be documented using docstrings following the Google Python Style Guide. Your final backend service code files must maintain 100% passing test coverage on stage.

Careful attention to permissions and access control should be paid to adhere to the principle of least privilege. Users should only be able to perform the necessary actions on the permitted resources for their legitimate purpose.

Stories merged in to stage should be of usable, production quality.

Extra-Credit (1 point) - Catch Your stage Branch up with csxl.unc.edu Production

The TAs are not permitted to assist with this extra credit opportunity in or outside of Office Hours.

Some PRs have landed in production at csxl.unc.edu since you began Sprint 2: https://github.com/unc-csxl/csxl.unc.edu/commits/main

To earn this point of extra credit, you should catch your stage branch up to upstream/main such that you have commit ea620d4, or later, in your stage branch. You may need to resolve conflicts. When creating a PR for this catch-up branch, rather than squashing and merging into your stage in this instance you should use the “Create a Merge Commit” strategy. This strategy will retain the history from production’s main branch.

This is good practice, and easier to achieve, if it’s done semi-regularly. Additionally, this serves as a prerequisite to being considered for merging your team’s features into production after the semester ends.