-
Notifications
You must be signed in to change notification settings - Fork 119
TAG August 28
- Bryan Brown
- Joanna DiPasquale
- Danny Lamb
- Rosie Le Faive
- Bethany Seeger
- Jared Whilko
- The version support timeline has been approved
- Welcome new members Seth Shaw and Joanna DiPasquale
-
Survey results are in! Now we need a Technical Roadmap.
- How do we define roadmap? Version support timeline + "Strategic Initiatives"?
- Luring in documenters with a special team on islandora/documentation
Need to develop a roadmap, reviewing survey to help set priorities. Questions around - how to evaluate options for one or a set of modules, documentation that is better than Drupal's but doesn't particularly relate to Islandora, developing what is becoming a knowledge base. How do we keep track of alternatives? How do we surface community evaluation of different modules?
- Failures section of the Islandora Cookbook?
- Different use cases would highlight different features.
- Surfacing language / terminology and features: e.g., tombstoning = this is how we define it, this is what modules use it, this feature can be found in this module.
Goal: to get us to Islandora 8.x.1.1 to 8.x.1.2 Develop a timeline for how often 8.x will have a release / min-max guarantee. What things do we need to complete in a block of time, and map this to the roadmap? Separating out: code vs not code, implementations of the same thing (e.g., embargoes vs. locking down items). Evaluation by the community: do you like it, does it meet your needs, and what can improve? User feedback on existing functions and features could be useful, too. Could focus on this between now and next release.
Obstacle: software is disjointed, less coherent than it could be. Priority is to organize this and disseminate, communicate features out (so you don't need to be fully involved in the community to know what Islandora does). Balancing flexibility and turnkey.
Need to:
- Categorize
- Note code vs documenting (so we can have parallel paths) ** Documenting loops back into coding; how to make this process smoother?
Priorities for committers important as well. But the roadmap might help channel everyone's energies.
What do we need to do to make Islandora feel like a DAMS?
- Basics (upload your files / here are your files)
- Categories of functionality
- Categories of objects
- Features centralized (e.g., in Islandora menu)
- Tours implementation of how to configure in 8, or have links to documentation right away (bridging gap from old to new) ** But easier to edit documentation is desirable goal ** Tours might be better for wizard-based work
- Dashboards could be useful
- Descriptions for fields could also be incredibly useful
- Getting 7.x people more comfortable with 8.x includes UI, documentation, migration
Priority: get 7.x users to 8.x -- the roadmap should first reflect this
- Metadata modeling for users that are going to then ingest items into 8.x
- Hierarchical metadata
- Getting feedback on what are pain points: issue tracking, network of dependencies for work that is still outstanding Then: items that are DAMS-focused (batch upload, batch editor), excellent and organized documentation
MODS XML as a high priority?
Should we sketch out migrator and implementor personae / user profiles for what these users need? May be more information coming from the project that will help. But focusing a big part of the roadmap to 7.x users is going to be really important. (High percentage of respondents were 7.x users.)
More people getting on board for 8.x -- getting migration settled will help. Then: features for people using now that would be also beneficial for others / new adopters.
- Improve migration paths
- Improve UI for people using it
- Improve documentation
- Write out use cases
Categorize items to begin this work.
You may be looking for the islandora-community wiki · new to islandora? · community calendar · interest groups