- #general > PR tracking
- #t-compiler > review latency meeting planning
- #t-compiler > reducing PR review time
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
.
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.
- 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)
- 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
- 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
- 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(maybe not, there's activity happening also after ther+
to actual issue closingr+
, 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)
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:
- 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)