...
Status of In-Review tickets
Expand Jira server DuraSpace JIRA jqlQuery filter=14416 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5
Notes
- Migration to GitHub
We should move issues to VIVO repository first. From Dragan’s point of view it is logical to have issues in this repository. In other repositories it could be confusing for users.
Where should we open issues after that?
For the people it is hard to understand where the issue belongs - to VIVO, Vitro, Vitro-languages or VIVO-languages.
William: We could transfer issues to other repositories on Github later.
Dragan: The point is when a user reports some bug you should describe your environment. Can you check Github standard templates for bug reports and feature requests?
Brian: If there is no activity in issues of current repositories users could think that repositories are archived and not supported.
Conclusions:
- Migrate issues to VIVO
- Not open issues for other repositories for now (Vitro, VIVO-languages, Vitro-languages). For now keep issues in VIVO repository only.
- We should change wiki pages about issues
2. Side note about Vitro and VIVO relation
William: Why are VIVO and Vitro in separate repositories? The application shouldn’t define the dependency.
Dragan: Reengineering of VIVO is an interesting question.
VIVO is one application for Vitro in the research domain.
By and large most people don’t understand the distinction.
Questions from William:
How many people are using Vitro?
How many applications also depend on Vitro?
William: It is very difficult to coordinate the build of VIVO and Vitro.
Ontologies and templates should have their own library.
Instead, dependencies look strange.
3. Discussion about VIVO 2.X architecture.
We could shape the idea of new architecture in committers group for two weeks and then move discussion to the developers group.
Actions
- Dragan Ivanovic to run tool for migration of JIRA issues to GitHub issues correct wiki documentation
...