Skip to content

September 8, 2021

Jump to bottom Edit New page
Jared Whiklo edited this page Sep 8, 2021 · 10 revisions

Time/Place

This meeting is held virtually via Zoom, with an open channel for chatter on Slack. Anyone is welcome to join. Here is the info:

Attendees

  • Too many to count and I started minutes late.

Agenda

  1. Sprint planning

    1. UPEI, UTSC, DGI, Born-Digital have committed resources 👍
    2. process for prioritizing goals
      1. Issue queue
      2. Features survey from last fall
      3. 7.x/2.0.0 feature parity list
      4. ICG report
    3. determining sprint leader, timeframe, roles, etc.

  2. Issue Roundup

    1. https://github.com/Islandora/documentation/issues/37
    2. https://github.com/Islandora/documentation/issues/273
    3. https://github.com/Islandora/documentation/issues/30
    4. https://github.com/Islandora/documentation/issues/352
    5. https://github.com/Islandora/documentation/issues/385
    6. https://github.com/Islandora/documentation/issues/1893

  3. PR Roundup

    1. https://github.com/Islandora/islandora_pdfjs/pull/39
    2. https://github.com/Islandora/islandora_pdfjs/pull/40
    3. https://github.com/Islandora-Devops/islandora_install_profile_demo/pull/2

  4. Feature Parity Document - Lets do a few more rows together!

  5. ... Please feel free to add more...

(Last 10 Minutes): Roundtable

Minutes

  • Sprint requirements
    • UTSC volunteering 3 (Kirsta, Kyle and Nat) fulltime for 2 weeks.
    • DGI would have to know what the timeline is, could have up to 6 people but would depend on business requirements as well as sprint requirements.
    • UPEI would be Alex fulltime
    • Born Digital would have Don up to 15 hours across 3 weeks, perhaps Danny as well.
    • The goal is this group is defining the goals and some volunteers to run the sprint. Running the sprint would be a larger commitment of time/resources for that/those person(s). Perhaps co-leaders?
    • What is this sprint is doing? Who is calling for this sprint?
      • We come to what the goal is by going through the issue list, the 7.x feature parity list, feature survey from last fall, ICG report.
      • The email actually referred to it as a feature parity sprint. Leadership felt we needed to get closer to feature parity and a sprint would be the best way to do it.
      • Feature parity might be a misnomer as every feature in Islandora 8 would be to get features that existed in Islandora 7 translated to the new stack.
      • The issue queue might have a large number of old issues, some could be closed but seemingly only Danny has the experience/knowledge to do that. Would depend on Born Digital.
    • How we can take features/fixes from all three lists to build a sprint list.
    • Perhaps this was a good place to start but we don't need to create the actual list in this meeting (could be done off-line)
    • Feature parity has the implication of making Islandora 8 act like Islandora 7, where as things in the new system will act completely differently. We need to be confident in the architecture we have chosen and work through the more core issues needed. (ie. Access Control).
    • Defining what the product is, there are the IR features that are lacking but can we move to specific implementations before we have a strong general DAMs.
    • When talking about access control, just want to make sure we are considering future needs like IR.
    • Defining what Islandora is supplying out of the box might help to define sprint needs.
    • Doesn't make sense to have two methods of deployment as this reduces resources available to each process.
    • Islandora 7 was clear, it was modular, you enable a module and do stuff. This (Islandora 8) is a framework which is less clear.
    • Do we need to change our philosophy, can we have a system that is turn-key for the small institutions but also extendable for those with that need.
    • Can we have a sprint to plan for the future development and create a roadmap.
    • For greenfield installations there is no use for a feature parity document. Better to define tasks that can be worked.
    • Access Control might not be a good place for sprint as it might not be sub-dividable. Better to have one person dive in an figure out the hard stuff. However this is a very important feature and having one person decide how to do it might lead to problems for other peoples needs.
    • Roadmap as the first activity seems less tangible, would be preferable to just a planning sprint.
    • Could we not just roadmap before the sprint (in the next month)?
    • To open this conversation to the larger community, what would be a way to get that input? Interest groups? Get the ICG involved?
    • We need to clean the issue list.
    • If the goal is to get the community to "up vote" certain issues, then perhaps a tag/label to identify those issues would be a good start.
    • How do we upvote? Reactions?
    • Are we looking to ensure there is an issue for each of the other documents requirements (ie. is there an issue for every feature from the feature parity document)?
    • Kirsta is happy to start the process of checking the various inputs and map them to existing issues.
    • Need to start writing up a process for defining issues and how they are "up-voted" by the community.
    • Next week's meeting to finish defining this process?
    • Kirsta is creating a document to draft a process to get the wider community to help clean up the issue queue through review and assigning importance.
    • Next week we finalize this process and hopefully send it out to the wider community to get them involved.

Additional notes from David (thanks!)

fyi: there may be some duplication of notes from above.

  • Github Issues list

  • An attempt to try to capture many people's thoughts per Roadmap Sprint...

    • Roadmap Sprint: "Islandora: From Existential to Reality"
      • Develop Roadmap
      • Can we rally around one single deployment method (ie ISLE or playbook) to conserve resources, unify installation and simplify documentation efforts and maintenance?
      • Where does IR development sit on our Roadmap? DAMS first, second?
      • Where does the importance of implementing/improving turnkey solution sit on our Roadmap?
      • UX
      • How would an improved base box serve small and large institutions
      • How does the roadmap speak to Greenfielding or Migrating Institutions? How do we ensure it speaks to both groups?
      • Which are the top Github Issues that need to be resolved?
      • How do we prioritize development of the above in the roadmap?
      • How to improve the migration experience?
      • [More questions like these...]

You may be looking for the islandora-community wiki · new to islandora? · community calendar · interest groups · roadmap

This is an archive. For new Tech Call notes, click here

⚠️ ARCHIVED Islandora Tech Calls

⚠️ ARCHIVED Islandora User Calls

Clone this wiki locally