Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

\uD83D\uDDD3 Date

\uD83D\uDC65 Participants

\uD83E\uDD45 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.

\uD83D\uDDE3 Discussion topics







Edward Zarecor

  • Initial pilot phase ends on Friday, September 16th

  • Reminder of our expected outcomes for this phases


Outstanding Questions

Edward Zarecor

  • Questions yet answered on the wiki:

    • What are maintainers expected to do vis-a-vis notifications on Discourse.

    • What does monitoring GitHub issues mean in practice

    • Should GitHub notifications be person oriented, team oriented, or at the discretion of the maintainers?

    • Is a week for merging or closing a PR reasonable and sustainable?

    • Cadence for merging security updates from the requirements bot.

    • What GitHub permissions should a maintainer have for a repository that they maitain?


Collect Pilot Feedback

Edward Zarecor

Highlights from Retro Above

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

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


Terraform Repo Config

Feanil Patel


Agree on Next Steps

Edward Zarecor

✅ Action items

  •  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