TAG: November 9, 2022 - Islandora/islandora-community GitHub Wiki

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

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 -
    • 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.

Other

  • Amy: Still recruiting for dev-types to help field Q&A at upcoming open meetings. Is there availability from anyone for the Nov 29th Open Meeting?