Page History

...

• Story: A user-visible requirement which ought to be achievable by a single developer in a couple of days. These are captured in a consistent format, "As a [user type] user, I should <feature description> so that <value to user>". For instance, "As a user, I should be able to log in so that I may access information saved with my account."
• Epic: Groups similar stories into less granular pieces of functionality.
• Bug: A user-visible implementation problem that causes clearly broken behavior. Examples: a button that does not work, severely degraded performance, a security hole.
• Improvement: A user-visible implementation problem that, while not clearly broken, poses usability challenges. These are almost exclusively reserved for interface design issues since we often have a backlog of features which have been implemented but need UI polish. Improvements are optional and we could ship without them. Examples: a button that looks out of place, text that needs styling.
• Task: Necessary work that is not user-visible. Examples: Setting up a CI environment, research to make a recommendation, documentation.
• Vulnerability: A security vulnerability reported by code scans (e.g. Snyk).
• New Feature: Not used.

Estimation

...

1. The developer chooses a JIRA issue from among those in the active sprint, assigns it to himself, and moves it to the "In Progress" column of the agile board
2. The developer implements the change in a new git branch named after the issue number, e.g. EDSC-123. Commits are also prefixed with the issue number, e.g. "EDSC-123: Add user accounts page".
3. (Optional) When in need of collaboration or input, the developer pushes the branch and opens a new pull request without assigning a reviewer. Collaborators may pull the branch or view and comment on the diff in Github.
4. When the change is complete, the developer pushes the branch and opens a pull request (without assigning a reviewer), triggering a TravisCI build for that branch, and ensures the build is green.
5. Once the build is green, the developer assigns the pull request for the branch to each member of the development team and moves the issue into the "Pending Review" column in JIRA.
6. The reviewer looks at the code, ensuring passing tests, adequate test coverage, code quality, and correct/complete implementation. He also runs the code and manually tests it, paying close attention to usability and consistency of like-features or interactions throughout the rest of the application.
7. The original developer fixes items brought up during review until the reviewer is satisfied and has approved the pull request. In most cases, we like to have 2 approvals. In some cases that is not needed. The team lead will have a good idea as to what needs additional review. Use your best judgement.
8. Once sufficient approvals have been granted via Github, the original developer merges the branch. At this point the remote branch can be deleted.
9. Once master has built and deployed to SIT, the original developer verifies the new functionality/fix is working and assigns , moves the JIRA issue to the EDSC QA team member for testing "Ready for SIT Testing" column, and creates a JIRA issue test session for QA and verification.
10. If the QA process reveals updates need to be made, the QA team member works with the original developer directly to resolve any issues, following the process outlined above, until QA approves the changes.
11. The QA team member moves the JIRA issue into the "Done" column, typically with a resolution of "Verified Internal"Ready for Test."
12. Once deployed to the UAT environment, the QA team member executes a regression testing protocol ensuring new features work correctly and that the build/release is stable. They also reach out to a primary stakeholder for the issue (for instance, the person requesting the change) so that they may test the implementation. If satisfied, the ticket is transitioned into Product Owner adds "Verified Internal" (in the case of EDSC QA approval) or in UAT" as a comment in the issue or the issue is moved to "Verified External" (in the case of an external reviewer).

...

It is typically very difficult to extract complexity from front-end code. All new components should be focused on reuse, versitilityversatility, and extensibility. When possible, do not add new components at all, but reuse or extend existing components, which can be found in the Pattern Portfolio.

...