Date

14 Sep 2022

 Participants

List meeting participants using their @ mention names

• Edward Zarecor

• Ned Batchelder (Deactivated)

• Feanil Patel

• Kelly Buchanan

• Felipe Montoya

• Maria Grimaldi

• Zach Hancock

• Zainab Amir

• @ mention a person to add them as an attendee and they will be notified.

 Goals

List goals for this meeting (e.g., Set design priorities for FY19)

• 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

Add action items to close the loop on open questions or discussion topics:

• Feanil Patel generate teams for each repo in the maintainers pilot. Provide the list of teams to be generated for feedback before making them.

 Decisions

Type /decision to record the decisions you make in this meeting: