apiraino / prs_stats

Build data about PRs lifecycle

Discussion in these Zulip streams:

• #general > PR tracking
• #t-compiler > review latency meeting planning
• #t-compiler > reducing PR review time

Requirements && install

Data retrieval and parsing:

• Needs Python 3.x. Create a virtualenv and install the packages:

$ virtualenv venv
$ source venv/bin/activate
(venv) $ pip install -r requirements.txt

Website presentation:

• Needs npm LTS. This should install the needed packagesa and start server on http://localhost:8000

npm run dev

• Compile with:

sh update_dist.sh

Output files are in ./prs_stats. Test deployed compiled .js with any http local server, ex. python -m http.server and then open http://localhost:8000/prs_stats.

Scripts

These scripts will fetch and process the pull requests data. Directory ./src/data constains all .json files used by the website.

Use move-stats.sh to move the JSON files into the proper folders.

Use import-data.py to generate the .js file to be included in the HTML pages.

1. Download the entire PRs corpus from rust-lang/rust (+6K pull requests, will take hours! Final dump is about 1GB uncompressed)

./get-all-prs.py (with sorting by date)

2. How long do stay PRs open before being closed?

# filters all PRs in Q1/2023
# output: a file for each team
./filter-prs-by-date.py 2023-01-01 2023-04-30

3. How many PRS are against issues?

# get all connected issues to PRs in Q1/2023
# output: a file for each team
./get-regression-issue-for-prs.py 2023-01-01 2023-04-30

TODOs

• download only delta of data
• set/get a bookmark when downloading data in case the process is interrupted
• alternate API tokens to work around throttling (does not work)
• reduce noise by excluding time elapsed from r+ to actual issue closing (maybe not, there's activity happening also after the r+, often enough that we don't want to ignore it)
• why is a PR actually taking long to be closed? Give evidence if there was a lot of discussion and comments or was just sitting there unattended
• maybe overlay candle/violin representation of max,min,avg in PRs age (see here how)

Frontend to set your review capacity

https://hackmd.io/GqXA4nyTQ4m__hRZUayVRg

Goals:

• Build a simple web page deployed somewhere on github rust-lang org with a few knobs for reviewers to change their settings
• nobody needs to manually edit this file to set themself in or out the rotation

Tasks (more or less):

• BE: save settings into the triagebot DB (detail DB table fields)
• BE: settings for each contributor:

  • open PR assigned (with list? with last comment timestamp?)

  • max # open pr assigned
  • PTO start
  • PTO end
  • "ping me after X days"
  • agree to make these settings visible to the team? (opt-in)
• BE: triagebot reads the local DB before assigning the reviewer
• Nice to have: change these settings directly from Zulip (see HackMD linked above)