Skip to content
This repository was archived by the owner on Jan 24, 2020. It is now read-only.
This repository was archived by the owner on Jan 24, 2020. It is now read-only.

Making review of pending pull requests more efficient  #142

Closed
@hlapp

Description

@hlapp

The Data Carpentry steering committee members and its Project Lead have an ongoing responsibility to review, comment on, and, when ready, merge pull requests (PRs), in particular for lesson materials after they have been "released" (i.e., taught), to ensure consistency, good organization, and coherence of materials is maintained. Due to the "minimum-of-two-pairs-of-eyeballs" policy, these PRs will almost always not be one they submitted themselves, and with the lessons being split out each into their own repo, it can be quite difficult to know where to go and look for PRs that need reviewing. This is especially so if you're like me and you don't have the necessary block of time whenever one comes in.

One idea is to create a markdown page (in the wiki, or in the repo) that lists all lesson repos, each with a link to the list of PRs (such as this for this repo), and ideally the number of currently open PRs. This could conceivably be generated by a script at regular intervals, or one that gets triggered by means of webhooks.

Another idea could be to use some kind of round-robin principle for assigning incoming PRs, and then everyone looks at what's assigned to them. The round-robin assignments could also be scripted and automated through webhooks. (Though I would argue that assigning stuff risks turning people unnecessarily into points of failure.)

There are probably other ways to deal with. Thoughts anyone? Solutions by comparable projects (SWC??) that we could borrow from?

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions