LSAP and Committers - Proposed Changes and Consultation Process

[Kirsta Stapelfeldt]

Hello Islandora, 

 

As part of the Foundation’s ongoing work over the last year to update Islandora’s governance, the Islandora Foundation is proposing strategic changes to the Licensed Software Acceptance Procedure (LSAP) and Islandora committers.

 

• (Proposed) Revised Islandora Committers Page 
• (Proposed) Revised LSAP process and workflows 

 

Some additional content is pasted below to describe the major changes introduced in this documentation. Feedback channels are multiple and varied: Respond here, comment on the docs, reach out on Slack, send me a personal email (I am in charge of wrangling feedback), or come to January 11th’s tech call to discuss any feedback with Rosie. 

 

The Foundation is working toward a consensus decision for these changes. This means that the governance arms of Islandora can agree, when communicating openly and in good faith, that these are changes that should be made. These documents first went to  the Technical Advisory Group (TAG)  in November, and then to the Leadership Group (LG) and the Coordinating Committee (ICC) in December. All have agreed that it is ‘ready’ for your review and comment. Please provide your feedback directly in the documents below and in the tech call on January 11th: https://github.com/Islandora/islandora-community/wiki/January-11,-2023

 

Best,

 

Kirsta Stapelfeldt (P/T Director, Strategic Operations, Islandora Foundation)

 

Modifying the LSAP

Components can have maintainers.

• As we move the Islandora codebase back in a more modular direction,  we wish to develop a mechanism that allows for but doesn’t require software contributors to name a maintainer. We have heard that providing this flexibility for how people contribute software is desirable. 

o    Contributors that want to stay on as maintainers of their submitted modules would have to become committers (be considered to become committers).

TAG reviews incoming contributions

• Based on a recognition that the existing LSAP has the ICC vote on the contribution of code, but includes code-level requirements that ICC cannot independently verify, we propose that code contributions are first assessed by TAG, who will then provide a recommendation to the ICC based on a shared checklist of requirements, prior to the ICC voting on repository inclusion. 

“Used at three independent institutions” no longer required

• Based on a recognition that a lot of new code rebuilds the features provided in Islandora Legacy (Islandora 7) and recognizing the current level of institutional involvement in the community, we think we should loosen the requirement (at least in the next phase) that software be independently implemented by at least three institutions. We are proposing language to replace this explicit requirement, but hopefully preserve the spirit of the requirement.

 

Modifying the Committers program

TAG becomes a subset of the Committers

• Based on the idea that we are moving the stack in a more modular direction, we propose loosening the requirement that all code committers be responsible for the entire stack. If a global responsibility for the codebase needs to exist, we propose that TAG take on this responsibility, and that TAG be granted enhanced permissions via a newly created Committers/TAG team in the Foundation repositories to do so. 

Clear way to retire Committers

• Based on the outdated existing committers list, we would like to develop a clearly defined mechanism for retiring committers (removing from the committers team) based on set criteria (for example, an unexplained year without activity in Islandora Foundation repositories). 

Committers from same institution can merge 

• We are proposing to lift the requirement that two committers from the same organization cannot commit each other's code. If code is irresponsibly merged, we believe this is a reflection on a committer and not on an institution and should be managed at that level without implicating the organization. 

Modifying GitHub structures to support these changes

 

Based on a recognition that Islandora’s GitHub pages are increasingly a source of truth not only for code, but also for user documentation and community meeting notes, we would like to use GitHub teams to organize the Committers list. To further equip all committers, we wish to provide permissions for other non-code channels in the Islandora Foundation (such as Slack and the website). Note: This is meant to empower existing work, particularly for non-developers, not create requirements or expectations for committers to do more. The logistics of how best to achieve this in GitHub’s current feature set are still being discussed. 

 

 

[Kirsta Stapelfeldt]

Dear Islandora,

 

To follow up on the email below,  I am pleased to report that we have made key changes for  Islandora Committers and LSAP. These changes, articulated below, are now available live at the following pages:

 

• “Committers”: https://islandora.github.io/documentation/contributing/committers/
• “How to Contribute”: https://islandora.github.io/documentation/contributing/contributing-workflow/
• “Contributing” at the header “New Modules” https://islandora.github.io/documentation/contributing/CONTRIBUTING/#new-modules (now links to the revised LSAP)

 

Summary of changes

 

LSAP:

 

• Components can now have maintainers!
• TAG will support ICC by reviewing incoming code prior to ICC’s vote on inclusion!
• Code need not be used at three institutions!
• In case you missed it, Isabella has significantly streamlined the LSAP process. It is now a form-based workflow.

 

Committers:

 

• To serve on TAG requires that you have committer status!
• Clarity about when committers are retired!
• Committers from same institution can merge!
  
  

Thank you to all the governance groups and community members that participated in these changes.

 

Best,

 

Kirsta