Roadmap Meeting Special Topic Nov 6 2015

• Chair: Mark Jordan

• Notetaker: Donald Moses

• Attending: Melissa Anez, Mark Jordan (Chair), Will Panting, Rosie Le Faive, Jennifer Eustis, Gabriela Mircea, Nick Ruest, Carell, Donald Moses (notes), Mark Baggett

• Apologies: Caleb Dervin, David Wilcox, Kirsta Stapelfeldt, Mark Cooper, Noah Smith, Eric Koester

Topic: Internal Merges

The proposal is: Anything that is merged, can only be merged by committers, and that committers at the same organization or institution cannot merge their colleague's code. They can review the code, they can provide feedback, but they can't merge code that is coming out of the same organization or institution.

• Concern with conflict of interest.
• Community review should be clear and transparent review

Committer composition

• 18 Committers. 9 from dgi, 3 from UPEI, all others from different institutions
• https://github.com/Islandora/islandora/wiki/Islandora-Committers#responsibilities

Will

• concerned about the proposal itself.
  • will potentially create a second class of committers.
• An abnormal approach. Proposal is non-standard.
• The code is openly posted and is open to feedback. DGI is part of the community.
• Concerned that there will be less rights.
• Wants to provide more information to the community.
• Documentation is for the committers ... should written for all contributions and not targeted at Organizations.
• practical concerns include:
  • timelines - can be solved with discussion and follow through
  • merging code that doesn't meet the standards should be addressed with the committer/coder
  • WP had another concern ... more pressure on the community of committers
• The tools already facilitate the practice.
• How DGI committers handle merging internally:
  • in the interest to act in the interest in the community
  • if issues have happened has been an honest mistake
  • code is developed using best practice
  • encourage clients to create code in a sustainable compliant
  • for custom code it is done in a custom module and not committed to core
    • reflected in DGI github org
  • many hooks are added to allow for customization.
  • hooks written to follow best practices.

Nick

• Contributions from community are stopped ... no conversation.
• Pull requests are merged without discussion.
• Concerned with the impact on the community.

Melissa

• While this does have a disproportionate effect on dgi in the short term, we need to look at this as a general policy - and look ahead to other potential committers.
• DGI has put out some great work and have share well (eg. recent templates)

Gabriela

• was a DSpace community member for a while
• Doesn't remember having to put the check in place.
• Is for a transparent process.

Rosie

• shouldn't be able to push their own code.
• No doubt that DGI has been the major contributor and developer of the codebase.
• A desire to have a disinterested third party for merging.
• Wants to ensure the community has a chance to review the code.
• Wants to create a collaborative working practice.
• Concerns with a single institution steering Islandora in a particular direction.

Carell

• wondering about probation/term period to trial to see if process/communication improves.

The Proposal:

• The proposal is: Anything that is merged, can only be merged by committers/developers and that committers at the same organization not be allowed to merge code. They can review the code, they can provide feedback, but they can't merge code that is coming out of the same organization.

Votes on the proposal:

• Mark Baggett: +1
• Nick Ruest: +1
• Jennifer Eustis: +1
• Mark Jordan: +1
• Gabriela M: +1
• William Panting: 0
• Donald Moses: +1
• Melissa: 0

Melissa will email those not in attendance.