Extra features for large PR workflow
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 28/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- html
- Domain
- frontend
Research direction
Start with the options page and the existing tree-view filtering flow described in the issue, then review the GIF to understand the proposed interactions. The issue proposes full-path filtering, matching filters in file diffs, and marking visible files as viewed; confirm which features are wanted before implementation, with optional settings disabled by default as the completion criteria.
Written by the indexing model from the issue text.
Description
I just moved to Github from Gitlab and this extension is really great, thanks for building it!
I often have to review very large pull requests and there are a few features that help me quite a lot in my workflow, so I cloned the project and had a go at adding them. I was wondering if you're interested in having any of these:
- Option to filter by the full file path instead of just file name. I use this to review things like
api,src/mainandsrc/testseparately rather than go file by file alphabetically - Option to filter out file diffs as well as the tree view (so the diffs on the right hand side always match what's in the tree). This means I can filter to e.g.
apiand then scroll through all theapirelated changes - A button to click "viewed" on all currently visible files. I use this to register that I've reviewed all the
apistuff after scrolling through it, rather than clicking on each individual file
I put these features as optional settings in the options page, with them disabled by default.
Happy to raise a PR but wanted to check if any of these sound useful first. If not that's totally fine, I can see why you'd want to avoid the behaviour of the extension spilling out into other areas of the screen such as the file diffs! Also, I'm going to be using this a lot for work so I'll be more than happy to help maintain it
Below is a gif to show the features together. The benefits aren't very obvious on small pull requests, but I struggled to find really large PRs in open source projects!
- Dominant language
- HTML
- Stars
- 697
- Forks
- 79
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from berzniz/github_pr_tree
-
Difficulty 5/5 Over a week Newbie friendliness 30/100
berzniz/github_pr_tree#232 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 25/100
berzniz/github_pr_tree#229 · 1 comment ·
-
Difficulty 1/5 Under an hour Newbie friendliness 45/100
berzniz/github_pr_tree#228 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 30/100
berzniz/github_pr_tree#221 · 1 comment · 3 reactions ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
berzniz/github_pr_tree#217 ·
All issues in berzniz/github_pr_tree
Similar issues
-
Difficulty 1/5 1-3 hours Newbie friendliness 74/100
italia/bootstrap-italia#1963 ·
Maintainers usually reply within 1 day
-
Tenant
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
MTES-MCT/Dossier-Facile-Frontend#2061 ·
Maintainers usually reply within 1 day
-
PWA stores a grouped number entry 1000x too small in German localePossibly taken @Minhal128 claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
area:frontend
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
interledger/publisher-tools#905 ·
Maintainers usually reply within 1 day
-
area-clientside-dartpad
Difficulty 1/5 Under an hour Newbie friendliness 64/100
Maintainers usually reply within 2 days