Versions Compared

Version Old Version 123 New Version Current
Changes made by

Sarina Canelake

Feanil Patel

Saved on

Key

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

These are playbooks for on-call tasks. Feel free to add more!

...

  1. Set the Account Name to the relevant Institution(2U/edx, OpenCraft, etc.)

  2. The contributor's first and last name

  3. The contributor's GitHub username (case sensitive - it should match what you see on their profile at https://github.com/<username>)

  4. Ideally, their email address

  5. Locate the field Contributor Covered Under Entity and select it

  6. Locate the Role field and add the Entity Contributor role to the user.

...

  • Look them up in Salesforce. Notice which roles they have. Notable roles include.

    • Core Contributor - a member of the CC program

    • Entity CLA Coverage Approver - someone who we trust to confirm new members of an entity. In the case of 2U, this means someone that we trust to provide names of new hires, such as a manager or trusted IT personnel.

    • Known managers and leaders - If the requestor is a known people manager or , staff engineer, or system administrator at 2U, we can accept the request from them. If they are not marked as an Entity CLA Coverage Approver, add this role to their account in Salesforce.

      • If you’re not sure if they are “known” ask the team or check with @georgebabeyJeremy Ristau.

  • If they don’t have an entry, ask about them.

    • Do they claim to be from 2U? Ping @georgebabey Jeremy Ristau and ask if they’re a 2U employee.

    • For anyone else, just ask in #axim-engineering.

  • If their identity can be confirmed, add the requester to Salesforce, as described above. Give them the Entity CLA Coverage Approver role if appropriate.

  • If not, reject the request.

...

  • First, confirm the provenance of the request, as described in Handling requests from unknown users. If you can’t, then reject the request.

  • Add the user to the openedx GitHub organization. Inform the user that their invite has been sent to their GitHub email.

  • As part of the invitation, add the user to the groups:

    • @openedx/openedx-triage

    • @openedx/2u-edx-legacy (was called @openedx/push-pull-all up until ~July 2023)

      • We’re no longer adding users to the 2u-edx-legacy group.

      Other sensible groups that the user requsets. For guidance $SQUAD, where $SQUAD is the specific squad they’re on at 2U. The onboarding request needs to specify this. If it doesn’t, ask, and mark the request as blocked.

    • For some more context on this system and how it differs from what we did historically, you can see: Granting write access to repos in the openedx org (that’s a public memo, feel free to share). Ask the team if in doubt

  • Do not grant the user write access to any repos as a part of this process. The CC process should be followed by the engineers once they’ve established a history with the project to get nominated (or self-nominate) for write access to repos.

  • Add the user to the CLA database.

  • Close the issue once the invitation is sent and the user has been added to the CLA database.

...

Remove the Core Contributor role from their record in Salesforce. If relevant, disassociate them from an entity CLA as described above.

🧑‍🤝‍🧑 Managing teams and access

See .

🧑‍🤝‍🧑 Managing teams and access

Anyone is allowed to join the openedx-triage group if they ask. This group gives access to clone the repo and manage issues and pull requests.

For other requests, follow rules in GitHub Access & Team StructureGrant and grant requests that follow those rules and seem reasonable.

👩‍🔧 FC Contractor teams and access

...

  1. First, determine whether the repository should be moved.

    • See our interim guidance on which repositories belong in the openedx GitHub organization. Feel free to bring the question to the team if you’re not sure.

  2. If you believe the repository should move, ensure that we legally can move the code.

  3. Choose a method: Transfer or Fork. We default to Transfer.

    1. Transfer. “Transfer” is a feature that GitHub provides. Its main benefit is that links to the repository’s original location will indefinitely forward to the new location, unless the repo is forked back into the original org. Furthermore, transferring the repository implies that Axim is receiving the entire repository as a code contribution under the contributor’s existing CLA, which has legal ramifications. To execute the transfer, follow these steps:

      1. Ask the requester to confirm the transfer using the wording in /wiki/spaces/NPGA/pages/3544940606 . Note the requester must be a principal (or higher) engineer or a manager, or have one of those people comment their approval on the request.

      2. Ask the requester to add you to the repository with admin permissions. If you are not in the source organization (you’re probably not), they can still add you to the repository an outside collaborator. They should not need to grant you any permissions in the source organization as a whole. One you’re granted repository admin permissions, go to the repository’s Settings page, scroll all the way down to the Danger Zone, hit “Transfer”, and follow the prompts.

      3. If the requester wasn’t comfortable granting you admin rights to the repo for some reason, then we can do it the hard way:

        1. Get on a screenshare with the requester (they must have admin rights on the repo being transferred). Particularly, they must share their screen looking at the GitHub page of the repo.

        2. Grant them Owner rights (from https://github.com/orgs/openedx/people , find their username. Click, then use the dropdown on the right sidebar to switch from Member to Owner)

        3. Observe them press the transfer button

        4. Determine which teams need access to the repo and add those teams in the next screen

        5. Press Transfer. After a minute or two, verify that the transfer is complete

        6. Demote them to Member (from https://github.com/orgs/openedx/people , find their username. Click, then use the dropdown on the right sidebar to switch from Owner to Member)

    2. Fork. The benefit here is that it can be done without the involvement of anyone in the source organization. Legally, we claim fewer rights using this method; as such, we are able to use it in situations where transferring wouldn’t be appropriate. Steps:

      1. First, check with the team and/or legal. We don’t use this method much, so if you’re doing it, you should probably check that these steps are still valid.

      2. Fork the repository into the openedx organization.

      3. Update any links in the repository to point to the new openedx location.

      4. If it’s not there already, add a Apache 2 or AGPLv3 license file to the repo.

      5. Add a note to the README stating that any contributions up to <version> are licensed by <original owner> under <original license>, and that any after <version> are licensed by Axim under <AGPL or Apache>. Example: https://github.com/openedx/django-require/#license

  4. Tag the latest commit.

    1. Before new changes are merged to the repo, tag the commit that was the last commit in the old org. The tag should follow a naming convention like this:

      1. Code Block
        last-commit-in-<orgname>-org
# Some examples would be
last-commit-in-edx-org
last-commit-in-opencraft-org

  5. Ensure that the newly transferred/forked repo has a catalog-info.yaml file an a clearly named owner.

  6. Run the repo_checks on the newly transferred repo(s)

Methods of transferring

  • Transfer. Based on https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository#transferring-a-repository-owned-by-your-organization

    1. Ask the requester to confirm the transfer using the wording in /wiki/spaces/NPGA/pages/3544940606 . Note the requester must be a principal eng or a manager, or have one of those people comment their approval on the request.

    2. Someone must have Owner rights to both the source org (or simply the source repo) and the dest org in order to do the transfer. In order to do this transfer, follow the following steps to grant the requester (or someone with admin rights to the repo) temporary Owner rights on the openedx GitHub organization:

    3. The main benefit here is that links to the repository’s original location will indefinitely forward to the new location, unless the repo is forked back into the original org.

  • Fork. You only need write access to the destination organization in order to do this.

...

For trivial PRs with unresponsive authors, as a rule of thumb if the change is:

  • less than 10 lines of code,

  • mostly deletions, or

  • the only way to do something, or it is just updated facts

it's okay to close it out and still make the change.

In this case, I can see that we tried a couple times to get the CLA, and that's good practice, too.

💁‍♂️ Using Mr Meeting to create a meeting

See /wiki/spaces/~618bf0adcc2d7c00717a67d8/pages/4428496908