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.

1. Project Director will assemble a list of features identified by the community (Completed)

  1. The list will be very high level. For example: “Add a visualization suite to VIVO replacing the existing visualizations.
  2. The list should include “end user” features -- very visible to faculty, staff and students who use VIVO in their daily work, as well as “owner” features that are designed to make VIVO a better citizen in a constellation of applications at an institution, as well as “technical” features that are designed to make VIVO easier to develop.
  3. Features may include any kind of activity necessary to deliver value to the community. Generally features involve development as well documentation, but feature may also include training or other activities necessary to enhance the value of VIVO.
  4. Each feature should have an estimated number of person months to complete. This is a preliminary estimate based on preliminary, high-level scope. Work on a feature will involve use case development, design, and technical specifications. The work may revise the initial estimate of the effort required, or required changes in scope based on available effort.
  5. Sources of features will include meeting notes including leadership, steering, workgroup and task forces, listserv discussions, JIRA issues, summaries of previous “requirements” and “use case” materials in the wiki, and previous roadmap presentations.
  6. All features should be consistent with the value proposition and with the strategic plan.
  7. Features will be briefly described -- 2-3 sentences -- what is the feature, and possibly why is it important to the VIVO community.

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.

2. Steering Group revises the list of features (Completed)

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.

3. Community discussion of features (4 weeks)

  • Discussion at workgroup meetings
  • Discussion at Steering
  • Discussion at Leadership
  • Discussion in Task Force meetings
  • Discussion in listservs

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.

4. Community survey regarding features (1 week)

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).

5. A Task Force reviews community feedback and makes a roadmap recommendation to Steering (3 weeks)

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.

6. Steering reviews the recommendation and modifies as needed (1 week)

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.

7. Leadership reviews the recommendation and modifies as needed (at the conference)

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.

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.