Roadmap Meeting October 30 2015 2pm AST

• Chair: Mark Jordan
• Notetaker: Melissa

Per: Schedule

• Attending: Mark Jordan, Melissa Anez, Donald Moses, Rosie LeFaive, Nick Ruest, Eric Koester, Dan Aitken, Jennifer Eustis, David Wilcox, Carell Jackimiek
• Apologies: Noah Smith, Mark Baggett, Mark Cooper, Caleb Derven, Gabriela Mircea

Old Business

• Previous meeting notes

• 7.x-1.6 release

  • Blocker issue may delay the release by a day or two
  • Documentation is nearly complete. A few red columns remaining
  • Thoughts on release process: we always have a few volunteers who don't report in promptly and have to be prompted a lot. This might be something for the next release manager to work on.

Interest Groups

• Preservation Interest Group (Donald)

  • Meeting next week. Agenda

• Fedora 4 Interest Group (Nick)

  • Last met during Hylandora Day at iCampCT
  • New Committers Diego Pino and Aaron Coburn
  • chullo and porkpie are new libraries for working with the Fedora API. Chullo = tuque for x.2, porkpie is for PCDM
  • future.islandora.ca sandbox is up. Thanks you UManitoba for sponsoring! Not publicizing widely until we sort out a user 1 issue
  • Community Sprint starts on Monday. Danny and Nick will give a demo of 2.x and then we go all in on the sprint. Focus is knowledge sharing and user docs. May not write any code, and that is FINE.
  • Hylandora Day went well. About a dozen attendees + virtual attendees. Much discussion about identifiers and how to mint them, linked data fragments, sharing services
  • Starting November 4th, there will be weekly Islandora 7.x-2.x tech Cals (similar to 1.x Committers Cals)

• Documentation Interest Group (Melissa)

  • Met last week. Notes
  • Focus on finishing up Release Documentation and on recruitment. Kelli will post to the listservs for more members and new convenors, after the release is out.

• Dev Ops Interest Group (Mark Jordan)

  • no update

• Metadata Interest Group (Jennifer)

  • Next meeting Nov 9. Agenda here
  • Looking through the listservs for use cases to turn into issues

• UI Interest Group (Rosie)

  • no update. Did not meet this month because of scheduling conflicts.

• IR Interest Group (Donald)

  • Met on Oct 22. Meeting notes
  • good discussion about a number of tickets
  • Going to have IG members vote on issues that are important to them.
  • Need to find out about work done in the community that has already been done. Information sharing is super helpful!
  • Migration Working Group and Metrics Working Group spun off

Islandora Camp updates

• iCampCT

  • 36 attendees. Budget neutral. Good group, folks seemed to enjoy it
  • Jennifer heard great feedback from attendees. A user group for New England may come into being as a result

• 2016 lineup: iCampFL in March, iCampEU3 (one day camp ahead of OR2016) in Dublin, possibly an iCampBC in August, and iCampMO in the fall

New Business

• 7.x-2.x GitHub organization
  • Islandora labs initially contained only 7.x-2.x, but now there is a lot in there. There is confusion in the community about what to use, what to clone, etc.
  • Putting it into its own GitHub and a codename while in production, to prevent confusion between the new stack and 7.x-1.x.
  • Some names to consider: SHIELD, Deux, or....(credit to dmo) CLAW. Mark is concerned about codenames that outlive their usefulness and asks that we take care not to ever use it in code. Carell suggests Islandora4 (how they have been referring to it).
  • Votes:
    • new git hub org: +1 from all present
    • operate under codename CLAW: + 1 from all present
      • Melissa to follow up with non=attendees by email to get their votes (open for 5 days)
• GitHub policies

  • Owners

    • Nick proposes that now that we have official Committers, we should formalize who is an "Owner" in our GitHub. Proposal: Islandora Foundation GitHub organization "Owners" should be Community Manger, Release Manager, Board of Directors Chair. Owners in this sense is the GitHub role that has administrative control over the GitHub org (can add and remove other members, teams, etc)
      • Orgs affected: Organizations: Islandora, Islandora-Labs, Islandora Interest Groups, Islandora Deprecated, Islandora CLAW
      • Donald proposes that this should be decided by the Foundation, as decided by the Board.
      • This is completely separate from Committers. It's an administrative role. Melissa: it's an ability, not a right. Owners should only be updating the list based on recommendations from other teams in Islandora, not under their own judgement.
      • Mark: Nick's proposal boils down to reducing the number of owners and using community processes to control who has push access, etc.
      • Carell asks what the result is for those who are no longer owners. Would they object?
      • Nick: wouldn't object to losing his role.
      • Melissa: we have already put in rules about what people can do and can't - technically Owners should not be doing anything without permission/request from another islandora group.
      • Eric: This is a positive step towards creating process and checks to ensure sustainable administration of the project. Whether Road Map or the Board assume the authority to designate repo owners, it is better than the current status quo.
      • Donald: we should post a note to the community about this work so that it won't surprise anyone
      • Vote called on: Nick Ruest Proposal: Islandora Foundation GitHub organization "Owners" should be Community Manger, Release Manager, Board of Directors Chair. Nick Ruest: Owners: The GitHub role that Melissa just described. Nick Ruest: Organizations: Islandora, Islandora-Labs, Islandora Interest Groups, Islandora Deprecated, Islandora CLAW. +0 from Dan and Melissa. +1 from all others. (Melissa to follow up with non-attendees and email the list summarizing the change if it is voted in)

  • Merging

    • Current policy is not to merge one's own commits. A few Roadmap's ago we floated the idea that we should also not merge commits from other members of our own institutions, because of potential conflicts of interest.
    • Add some formality around this so that there is more time for review (not a quick merge)
    • Mark Jordan: How do we decide when discussion is over. Should the CM call it?
    • Nick: CM should always be the one deciding when to merge. We do not have this formalized right now, but we should.
    • David: Having one person designated to sign off risks a bottleneck. Not sure he agrees that the CM needs to sign off on all discussion.
    • Mark: we need to build in a plan B for that kind of instance.
    • Nick: to keep on track: the current proposal is just for no internal merges. Defining how the CM fits in and what the process should be is a separate conversation. Ideally, the Committers would come to a common understanding and a process on how to merge. But above that, the Roadmap and/or Board should say "no internal merges" as an overarching policy.
    • David: this is another reason to formalize responsibilities of Roadmap, Board, etc.
    • Mark: let's proceed for now, assuming there are no major objections form stakeholders - and codify things going forward. We should discuss and vote and work out the details in the coming weeks.
    • Nick would like to vote today and believes Roadmap has the authority to decide this issue, leaving the Committers to work out the details. If the Board wants to overturn it, they can do so.
    • David: Is this proposal for all githubs orgs? Nick: yes David: Imposing this immediately may have some difficult consequences. Internal merges are practiced by some of our current committers, who will be immediately impacted. If we make this decision, we need to be cognizant of the practical consequences and the need to justify them.
    • Melissa: if the goal is to fix the conflict of interest, could we leave it to the Committers to come up with a proposal and see if there are other ways to address the underlying problem?
    • Mark: this seems like it requires more discussion than we have time left for. Can we defer to a later meeting to discuss this further? Nick: agreed
    • Donald: looking at the examples of where internal merges have caused issues, could we address the issue with procedures about giving community members or component mangers time to review/comment before merging? Wary of changing the system in reaction to a few incidents.
    • David: the top level discussion is just that people from the same institution should not merge each others code. We can decide if that is a good idea without looking to individual incidents. Fedora doesn't have this rule, and does have some Committers from the same institution - but they also have not had issues with it, and perhaps we have.
    • Nick: we are in a tricky spot where we are a community of both academic institutions and private services companies. This can create a conflict of interest if a service company is paid to make a change and they can insert that change without review. In the academic world, you recuse yourself if you have a conflict of interest - we should hold ourselves to a similar standard.
    • Mark: How can we continue this discussion productively, since we are out of time? Can we make this topic the first item of business on the next Roadmap Call?
    • David: How about a Special Topics Call? (Melissa will send out a Doodle poll for this special meeting).
    • At the end of that call we should plan to have a clear understanding of the implications of this decisions and how it will play out on a practical level. Because this will have an outsized impact on dgi, we ask that the dgi rep at the meeting come prepared to discuss.

Roundtable

• skipped because we are over time already

Closing Remarks

• Next meeting:
  • Chair: Rosie
  • Notes: David