*Deprecated* This material is for historical purposes only See https://wiki.duraspace.org/display/VIVODOC/All+Documentation for current documentation
*Deprecated* See https://wiki.duraspace.org/display/VIVODOC/All+Documentation for current documentation
The VIVO Roadmap process is a key strategic element of the project, and a key enabler of VIVO value. The VIVO strategic plan and in particular, the VIVO value proposition,
VIVO provides an integrated view of the scholarly work of an organization,
drive consideration of the work to be proposed for the roadmap. The process involves identification, refinement and prioritization of “features” -- high level improvements to VIVO that provide value to VIVO users, maintainers, and developers. A feature could be large (reporting suite) or small (improvements in the API). A feature may involve multiple use cases. A feature may be software, architecture, ontology, documentation, or more likely, a combination of each.
The roadmap will describe work to be performed over the course of a year. It may result in one or more releases of the software. The roadmap is not a description of a particular anticipated version of the software. Refinement of the roadmap will lead to description of features to be released in future software and ontology versions.
The roadmap is a description of prioritized effort to enhance the value of VIVO. Effort comes from the community. Community members who chose to contribute effort to a particular feature will always be able to do so.
The proposal below describes a process for creating a roadmap for review and adoption by the leadership group at the annual conference. There are twelve weeks available to produce a roadmap prior to the conference. A proposed duration for each step is indicated below.
The project director presented a draft of this process to the Steering Group at their May 22 meeting, along with a the initial list of features from the community documents in the wiki and other VIVO assets. See checklist below for a list of the sources used to identify possible features.
Following discussion, the Steering group revises the list of features, adding some, removing others, sharpening the definition or rationale for each, and discussing proposed level of effort.
Project director took feedback and assistance and revised list for presentation and discussion at the May 29 meeting which included the workgroup chairs. An overview of the process was shared with the leadership group at their meeting June 2. The project director took feedback and assistance and made a final presentation with adoption by Steering at the June 5 meeting. Features are shared with community immediately following.
Discussion may lead to refinement of the description of the feature, or addition of new features. For example “this feature includes xyz. This feature does not include abc.”
Community discussion of features continues from June 5 to July 3.
Community members on the VIVO listservs will be surveyed regarding their preferences for features, choosing features based on a “budget” of person months. For example, 18 features are listed with a total person months requirement of 60 person months. Each person is asked “If you had 30 person months to “buy” features on this list, which would you choose?” Leadership, Steering+WG leads, Community members will be surveyed separately so that results can be tallied by group.
Community is surveyed from July 3 to July 13. Results of surveys are discussed and summarized at the steering group meeting of July 17 (information item, no action required).
This group collects all feedback -- structured feedback from surveys, as well as listserv comments and notes in meeting minutes, and makes a roadmap recommendation of the form “Over the next 15 months, add feature 2 and 3, then 7, then 9, 11 and 14, then 18.” That is, features are sequenced to optimize value proposition and development effort. A balance of features -- end user, development, ownership -- are expected. The task force will include the tech lead and project director as well as at least one member of the leadership group, the steering + WG leads, and the community at large.
The roadmap will consist of a presentation with overview, timeline, and proposed order for the work. The presentation will includes slides for each feature. An accompanying document will include additional detail as well as describe community feedback regarding the features.
Task force works from July 13 to a report including the draft roadmap to be presented to Steering on July 31.
Steering may choose to modify the recommendation based on their assessment of strategic value of proposed steps.
Following discussion, the roadmap is revised for the Steering Group meeting of August 7. Steering Group draft is distributed to Leadership in advance of their meeting at the conference on August 12.
As with Steering, Leadership may choose to modify the recommendation based on their assessment of strategic value. The best venue for this discussion is the annual conference, where leadership has a half day meeting to set strategic direction. The technical roadmap is a major element of the strategic direction. Following adoption at the conference, the roadmap is presented to the members.
The roadmap should describe work to be done over the course of a year. Completion of the work depends on the effort contributed by the community. Items not completed over the course of a year may be considered for inclusion in the roadmap for the following year. Any group of community members can contribute effort to a feature at any time.