Goal
- Make development of VIVO minor releases time-based
- Organize regular sprints to speed up process of VIVO development
Approach
- Make development of VIVO minor releases time-based
- Two minor releases per year, the first one in April, the second one in October
- If some blocking issue/bug is detected which ruins normal work of VIVO, a patch might be released (it is not time-based, it is “detected blocking issue”-based).
- Organize regular sprints to speed up process of VIVO development
- Topic-based
- There should be a topic for the sprint which defines wider goal of the sprint
- Wider goals or objectives could be converted to milestones and have a project board for themselves. An issue can be on multiple project boards to add to sprints and still be on a wider goal project board.
- However, some bugs out of the selected topic for a sprint might be fixed.
- Moreover, some new features out of the topic might be implemented as well.
- We also need to be very conscientious of each new feature and how much technical debt it is adding due to existing designs.
- 4 sprints per year
- February
- May,
- August,
- November
- 3 weeks in length
- Main topic of the sprint and list of issues should be defined before beginning of sprint
- The first week - assignment, discussion, deeper analysing issues, organizing of work and finding good patterns, implementation
- The second week - Implementation
- The third week - testing, validation, reviewing, code change/correction (as a response to review), merging pull requests
- Daily meetings - short, what you did yesterday, planning for today, blocking issues
- Regular developers IG can be organized - Tuesday
- Preparation for a sprint
- We have around 2 months between sprints
- Noticed there might be a preparation for a minor release between two sprints!!!
- Vacation or New Year period
- Selection of the topic for the next sprint is the first task
- We can’t plan topics for all sprints for the next year, because if one topic is not completed at the end of a sprint, it should be probably a topic for the next sprint
- However, we can order a list of topics, and simplify the process of selecting the topic for the next sprint (if the previous sprint completed a topic, for the next sprint we are selecting the next one in the list, otherwise the next sprint will have the same topic).
- Selection of issues already reported at GitHub issues and defining new issues
- Consolidation of issues
- Duplication
- Overlapping
- Clarification of issue description
- Detecting dependencies between issues
- Blocking issue for some other issues’ implementation
- Making a preliminary plan
- Who is planning to participate
- Assignment (self-assignment)
- There is a risk - the last minute cancelation of participation in a sprint, but we have a first week in which we can reschedule a plan
- Infrastructure
VIVO release schedule
VIVO sprint schedule
2022
- February
- Dynamic API based on an ontology
- February 21st - March 11th
- May
- Dynamic API based on ontology
- + Front-end reengineering
- + GUI custom form builder
- August
- November
2023
- February
- Decoupling VIVO ontology and VIVO platform
- + Semantic web features and bugs
- May
- August
- VIVO cross site linking and searching
- November
- Integration with repositories
- + Exporting data in different formats
Appendix
- Additional topics/issues which should be taken into account within 2022-2023 plan or implement after that
- Simple theming
- Improving technical documentation
- Testing
- VIVO-in-a-box
- Expert Finder