In order to solidify the Data.gov Brand, the Data.gov Release Team wants to implement a process to audit work at a specified time interval (monthly or quarterly) to have better insight into what's changing at Data.gov and provide users a way to parse through the changes.
Acceptance Criteria
[ ] GIVEN research is done \
WHEN I look at this ticket happens \
THEN there is documentation on release strategies/options
Background
This came out of the retro on 3/17. The sentiments were about working more on the big picture roadmap to the future and how to plan for 1-2 years out. As part of this thought, the best way to gain traction into the future is knowing where you've been which can be used to highlight possible paths and trajectories (in the absence of an external vision or goal). Right now, after we close issues, we forget about them and only look for them if there's an issue we feel like we've seen before. Often times, we forget 95%+ of the work that's already been done.
The release strategy from this work could be used in multiple folds:
It could audit the past to see how much work has been done in particular areas. Have we spent too much or not enough resources on areas that may or may not be important to us?
It could be a form of changelog that shows the evolution of Data.gov and how we've tackled different problems historically.
It could highlight areas that we want to develop further as next steps.
It could highlight areas that we want to step back from and par down resources.
It could serve as a basis for determining if certain areas have been good investments and can effect that area's priority in future development.
Not all of these points need to be addressed. They are just different aspects we can explore in the scope of this work.
User Story
In order to solidify the Data.gov Brand, the Data.gov Release Team wants to implement a process to audit work at a specified time interval (monthly or quarterly) to have better insight into what's changing at Data.gov and provide users a way to parse through the changes.
Acceptance Criteria
Background
This came out of the retro on 3/17. The sentiments were about working more on the big picture roadmap to the future and how to plan for 1-2 years out. As part of this thought, the best way to gain traction into the future is knowing where you've been which can be used to highlight possible paths and trajectories (in the absence of an external vision or goal). Right now, after we close issues, we forget about them and only look for them if there's an issue we feel like we've seen before. Often times, we forget 95%+ of the work that's already been done.
The release strategy from this work could be used in multiple folds:
Not all of these points need to be addressed. They are just different aspects we can explore in the scope of this work.
Security Considerations (required)
None.
Sketch
TBD