- Switch from activity specific (SDI/XCI) to component specific planning, design, and testing discussions threads
- Consider in the future a new component user community discussion thread
- Consider in the future a new component operator discussion thread
Component documentation should be kept up-to-date as agile changes happen. Many changes may not affect documents.
- Design/security description
- Testing plans
- Operations documentation
- User documentation
- Production change log
As the design/security description changes the dev-ops team should evaluate whether a (mini) design/security review "DSR" would be valuable for important design or security changes.
To trigger a DSR:
- Dev-Ops team posts a revised design/security description to the component design thread listing which specific sections and changes need review
- Dev-Ops team notifies RACD management to request a mini-DSR and suggests reviewers
- RACD management will prepare and manage the mini-DSR
- Reviewers will provide feedback and the dev-ops team will reply thru the component design thread
- At the end of the DSR the dev-ops team will post a brief DSR summary to the component design thread
As functionality changes the development team should evaluate whether a change specific integration test would be beneficial.
To trigger the testing:
- Dev-Opts team posts the revised testing plan to component testing thread and lists which tests need to be run
- Dev-Ops team notifies RACD management to start integration testing
- Testers will post issues and results and developers will reply thru the component testing thread
- Testing lead will summarize the testing results with the pass/fail to the testing thread
As functionality goes production:
- Operator will post changes to the production change log
- There is no launch review and the dev-ops team decides which changes to implement (they can request input if they want).
- Dev-ops team can trigger a mini-DSR when useful
- Dev-ops team can trigger a mini-integrated testing when useful
- Dev-ops team deploys in production when ready and publishes changes to the change log
Recording Bugs and Improvements
- Bugs or improvements that need to be tracked should be recorded in JIRA, whether we receive them thru tickets, from our own testing, thru direct e-mails, or thru any other channel.
- Small bugs or improvements should have Issue Type = Task, Bug, or New Feature
- Small bugs or improvements may be linked as sub-tasks to planned larger Upgrade or Incremental Improvement issues if it makes sense, but they may also remain independent if an appropriate Upgrade or Incremental Improvement issue doesn't exist.