2022-09-14 Maintainers Meeting notes

 Date

Sep 14, 2022

 Participants

• @Edward Zarecor

• @Ned Batchelder (Deactivated)

• @Feanil Patel

• @Kelly Buchanan

• @Felipe Montoya

• @Maria Grimaldi

• @Zach Hancock (Deactivated)

• @Zainab Amir (Deactivated)

 Goals

• Address outstanding questions posed in the pilot wiki.

• Collect Pilot Feedback:

  • What was hard?

  • What was unclear?

  • Where were impediments encountered?

• Agree on next steps

  • What would need to be true to roll maintainership out to another tranche of repositories?

  • Agree on owners for getting those things done.

Pilot Feedback

• What was good?

  • [Ned] Actually editing files helped force us to think about the guidance we had written

  • [Kelly] There’s a channel in slack! There’s a developing sense of “we”! I’m just excited about clearer lines of communication.

  • [Maria] Now we know what our repo is missing

  • [Felipe] having the DoneXblock implement things first so we could look at the expected result.

    • [Zach] +1

  • [Zainab] Updated things that were missing for a long time. Especially the owners for reviewing requirement bot PRs (this was not done at the time of ownership transfer from engage-squad to activate-squad)

• What was hard?

  • [Ned] Making time for the tasks

    • [Jeremy] +1

    • [Zainab] +1

    • [Piotr] +1

    • Notes: Doesn’t have an urgency that brings it to the top.

      • Long runway was possibly less efficient than a shorter one

      • Hand-offs didn’t always happen when maintainers changed.

      • Need a scrum type ceremony – but maybe lower pressure.

      • Open questions in the wiki felt like this process was “half baked” (Ed’s word)

      • Pilot has been focused on one-time tasks, we’ll see what happens when we move into the on-going tasks, reviewing PRs for example.

      • Pinned dependencies is a solution to problematic dependencies, but we don’t always go back to them until we are, say, updating Django and have to deal with all of them.

        • Can we create a report that captures how many dependencies a repository has and how old the pins are? Is creating an issue really the simpler answer here?

      • Options

        • Automate, automate, automate

        • Reduce work to what is absolutely necessary

        • Deprecate repositories we don’t need

      • Potential intervention: more frequent “deadlines,” smaller batches, more touch points.

  • [Felipe] figuring out the correct way to make the requirements bot work

    • [Jeremy] Would love to try to improve this

    • [Maria] +1

    • Notes

      • This was built for 2U internal first and docs were scant.

      • @Jeremy Bowman (Deactivated) is up for writing documentation, needs to know where to put it.

      • Error messages – whether the action worked or not – were lacking, unclear.

      • Permissions were also a problem

      • When actions fail the debugging info is not great.

      • Which workflows should we use?

      • Potential interventions:

        • Workflow documentation that is community-oriented

        • Continue terraform work to make repos standards consistently applied, and document in code.

        • Documentation of the repository standards – update of the repo standards OEP, how-to document as a companion.

  • [Maria] Lack of documentation for GitHub workflows that live in openedx/.github (eg. requirements bot)

    • [Feanil] +1

  • [Ed] Understanding the repositories I own, going in cold

  • [Zainab] understanding the repository. The ownership was transferred recently.

  • [Zainab] who should I ask for review? Do I need review from Ned/Feanil?

    • Specifically things like the README and catalog-info.yaml

    • Should this be internally reviewed or should Ned or Feanil review?

    • Not a requirement that anyone outside the team review

    • External review for assurance would be appreciated.

• What was unclear?

  • [Ned] Some details of the metadata (for example: what does a group name really mean?)

    • [felipe] +1

    • [Zach] +1

    • Notes:

      • We have a couple options for naming conventions

        • Teams are orgs already have names that they may still want to use

        • Standardize on naming convention

          • Produces lots of team

          • Easy to understand

          • We’ll move forward with this as there were no objections

  • [Ned] Clarifying the audience(s) for metadata, which would help decide some of the guidance for them (for example: is the “maintainer” name meant to be usable by the public for pinging?)

  • [Ed] Whether people had what they needed to make progress, whether progress was being made

    • [Feanil] +1

    • [Kelly] +1

    • Notes:

      • We agreed above we need more scrum like ceremony for this.

      • Folks – myself included – have been spotty about adding weekly standup notes in Slack.

  • [Ned] Some exemplars (DoneXBlock) were ahead of the written guidance, so diverged from it.

    • [Kelly] +1

  • [Kelly] I have a hard time keeping track of what the tasks even are, and I’m seeing some of the updates to the wiki page for the first time today.

    • Which ones? Maybe they were made today.

  • [Zainab] the deadline. I was onboarded after Waheed left edX and was not aware there was a deadline until yesterday. (Thank you Ned for checking in yesterday)

  • [Ned] What “requirements bot” do we mean?

• What impediments did you face?

  • [Ned] Review cycles as always can introduce delays

    • [Felipe] +1

    • Notes:

      • Classic problem

      • Please consider doing review before doing new things, don’t let the fruit spoil in the unloading dock.

 Discussion topics

 Action items

 Decisions