Date: Fri, 29 Mar 2024 07:24:04 -0400 (EDT) Message-ID: <2115386822.30294.1711711444217@lyrasis1-roc-mp1> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_30293_688205483.1711711444217" ------=_Part_30293_688205483.1711711444217 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The VIVO Roadmap process is a key strategic element of the proje= ct, and a key enabler of VIVO value. The VIVO strategic plan and in particu= lar, the VIVO value proposition,
VIVO provides an integrated view of th= e scholarly work of an organization,
drive consideration of the work to be proposed for the roadmap. The proc= ess involves identification, refinement and prioritization of =E2=80=9Cfeat= ures=E2=80=9D -- high level improvements to VIVO that provide value to VIVO= users, maintainers, and developers. A feature could be large (reporting su= ite) or small (improvements in the API). A feature may involve multiple use= cases. A feature may be software, architecture, ontology, documentation, o= r 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. Refinem= ent of the roadmap will lead to description of features to be released in f= uture 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 co= ntribute 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 t= welve weeks available to produce a roadmap prior to the conference. A propo= sed duration for each step is indicated below.
The project director presented a draft of this process to the Steering G= roup at their May 22 meeting, along with a the initial list of features fro= m 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, a= dding some, removing others, sharpening the definition or rationale for eac= h, and discussing proposed level of effort.
Project director took feedback and assistance and revised list for prese= ntation and discussion at the May 29 meeting which included the workgroup c= hairs. An overview of the process was shared with the leadership group at t= heir 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 =E2=80=9Cthis feature includes xyz. T= his feature does not include abc.=E2=80=9D
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 =E2=80=9Cbudget=E2= =80=9D of person months. For example, 18 features are listed with a total p= erson months requirement of 60 person months. Each person is asked =E2=80= =9CIf you had 30 person months to =E2=80=9Cbuy=E2=80=9D features on this li= st, which would you choose?=E2=80=9D Leadership, Steering+WG leads, Communi= ty members will be surveyed separately so that results can be tallied by gr= oup.
Community is surveyed from July 3 to July 13. Results of surveys are dis= cussed 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 roadma= p recommendation of the form =E2=80=9COver the next 15 months, add feature = 2 and 3, then 7, then 9, 11 and 14, then 18.=E2=80=9D That is, features are= sequenced to optimize value proposition and development effort. A balance = of features -- end user, development, ownership -- are expected. The task f= orce will include the tech lead and project director as well as at least on= e member of the leadership group, the steering + WG leads, and the communit= y 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 a= s 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 assessme= nt of strategic value of proposed steps.
Following discussion, the roadmap is revised for the Steering Group meet= ing of August 7. Steering Group draft is distributed to Leadership in advan= ce of their meeting at the conference on August 12.
As with Steering, Leadership may choose to modify the recommendation bas= ed on their assessment of strategic value. The best venue for this discussi= on is the annual conference, where leadership has a half day meeting to set= strategic direction. The technical roadmap is a major element of the strat= egic direction. Following adoption at the conference, the roadmap is presen= ted to the members.
The roadmap should describe work to be done over the course of a year. C= ompletion of the work depends on the effort contributed by the community. I= tems not completed over the course of a year may be considered for inclusio= n in the roadmap for the following year. Any group of community members can= contribute effort to a feature at any time.