TAG: November 9, 2022

Time: Every second Wednesday of the month, 3:00pm Eastern Time US
Zoom link: https://us02web.zoom.us/j/968367412

Host key can be found in the description of the TAG Slack channel.

Attending:

Rosie Le Faive (Chair)
Willow Gillingham
Luke Taylor
Don Richards
Amy Blau
Kirsta Stapelfeldt
Isabella Nikolaidis (notes)

Agenda

💀 Deprecation updates (Rosie)
- Deprecation of carapace 🦞 and lessons learned
- Deprecation "policy"/document
Proposed revisions to Committers and LSAP processes:
- Committers page document
- Licensed Software Acceptance Procedure document
For communications between TAG members and non-TAG, create an email alias or google group?
- #tag Slack channel is private

Minutes

Deprecation Cycle

Deprecating carapace update from Rosie
- Wasn't able to update it on Drupal.org because only Danny has the credentials for that.
- Islandora project on Drupal -
  - https://www.drupal.org/project/islandora/ecosystem
- Carapace project members revised - originally just Danny as maintainer.
  - Now Rosie and Kirsta added as maintainers.
- Awaiting confirmation of community-islandora account.
Rosie: Feedback on deprecation checklist/how do we communicate deprecation?
Luke: Once something is deprecated, what is the message? e.g. "you shouldn't use, but you can use until X" where X is a major version change?
Luke: Ideally deprecation policy is public
- If it's code, we should have something in code that would notify people, comment or notify that something is deprecated.
Rosie: if it's a Drupal component, there's a place in the info.yml to mark it as deprecated.
- You can also mark it as obsolete, which is more severe - means don't use this right now.
- You can also mark it as abandoned in Packagist.
If it's a function, it would be moved to obsolete, removed from code altogether?
Don: Are there time limits set? Ex. so something isn't introduced, then removed at 6 months.
Luke: If it's a function that's a big part, you'd want to remove it at a major version release. We don't have a tight schedule around versioning like Drupal.
Don: Carapace is used as base theme and this base theme is now being deprecated. If things are getting deprecated too quickly it undermines trust.
Kirsta: It's going to happen over time. If something is getting deprecated, the decision is made by TAG based on the fact that either it's unsecure or not being maintained.
- Maybe we can tackle this in the LSAP process when modules are accepted?
- There may be more deprecation in the short run.
Luke: To that point, the challenge is - if somebody says they want to maintain it, and are active it can continue. If something is not being maintained after X period of time then it will get deprecated.
Rosie: Usually what happens with deprecation, is that you have until X time to stop using it. It doesn't mean it's not working.
- We could tie it to Drupal versions. For example, we don't have intention of moving this to 10.
- When we've deprecated something - we're not saying get rid of this immediately. This means we're still on the hook for security fixes?
Luke: This goes back to all maintainers maintaining all modules.
Kirsta: Going to a modular stack, you're not going to be able to make all the committers maintainers for everything.

Committers, LSAP

Committers revision aims for a more transparent way of assigning and managing people in the community.
Luke: Do we want to have a maintainer on a particular module, allowing for scenario where they want to be a maintainer but they may not be a full fledged committers?
- Maintainers in islandora must first pass the bar to be considered committers. AKA all maintainers must be islandora committers.
Rosie: Right now, all committers are both able to and responsible for making issues, making PRs, merging PRs, writing documentation.
- It would be a good thing for modules and components to have an assigned person of a little bit more responsibility.
- So it's difficult to expect all committers to actively maintain all components in this scenario.
Kirsta: Introducing a committers review to keep the committers list updated based on member activity.
Don: Committers were always nominated, you don't ask to be a committer. You had to gain trust of the community.
Kirsta: Committers review and monitoring activity can find these opportunities for nomination.
Luke: There are specific maintainer duties for a module that should exist:
- Enable and monitor dependabot security alerts for your module.
- Ensure your module is prepared for minor/major releases
- Apply security fixes in a timely manner.
- If there's broken functionality, there will be issues opened up in modules. If you're module doesn't work and is broken because of something, this is a maintainer responsibility to address the issue.
- This is a minimum list of requirements. A lot of folks might not be able to setup full auto tests etc but committers might be able to help with that as time allows.
Kirsta: If you're proposing yourself as a maintainer, then these are your responsibilities. If you leave the committers list, you can no longer be a maintainer.
Luke: Another blocker from contributing back to islandora -
- Rule around: you can't have 2 people from the same institution merge code. Can this be reconsidered?
- Now that we have more framework around pulls, is this rule still relevant?
Kirsta: I think so - this can get resolved with the evaluation of committers also.
- Maintainers are still maintainers of the code even if it's not to a specific module.
Next step is to bring up this amendment in the private committers email.