The issue has been closed
<!-- Thanks for contributing! 🏓 -->
It could be useful to know whether a pull-request is going to be time-consuming to review / test from the pull requests page.
Whenever I go to one of my projects' pull requests page, I'd like to know if I'm likely to spend 5 min reviewing a PR or 1 hour (even though we all know large PRs are wrong and partial reviews can at least get the PR moving). Sometimes I know I don't have much time on my hands but could still fit in a quick review on a PR to help somebody in my team.
It may be difficult to determine what makes a PR "complex" or time-consuming to review but I was thinking one (or several) indicators like the number of files changed, the line diff (similar to https://github.com/sindresorhus/refined-github/issues/2326) or the number of commits? Anything that could avoid me having to go into the details of each PR to see if it's worth me starting to have a look.
Example URL:
<!-- Please specify a URL where the feature should appear -->
https://github.com/sindresorhus/refined-github/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc
Complexity is subjective, the only related indicator we have is the lines changed count.
But the PR list is already rather crowded so we should limit further widgets unless actually useful.
the only related indicator we have is the lines changed count
What if the changed lines are meaningless though? It could be updating yarn.lock or removing some large fixtures.
Complexity is subjective
Very true, I was kinda fishing for better alternatives / ideas to mine really :) An update of a snapshot file for example may be a massive line count change but rather trivial (though it is time consuming if you really want to be thorough).
Do you know if it's just a global count we get from the API or if we have access to finer grained data (how many + and how many - for example?)
I agree line change count is not ideal... But maybe a combination of several indicators could give some sort of "score" and a warning sign could appear meaning "wow this one may take a while"?
It could be updating yarn.lock or removing some large fixtures.
I guess that notion of complexity becomes... much more complex than what I initially expected... It would probably be difficult to make a good and generic solution that works for any type of repository :(
I'm happy for you to close that issue then if you guys think it's not really feasible / worth it.
Yeah I think lockfiles trash the line count reliability. Two equal PRs might have substantially different line counts if one adds/updates/removes a dependency. We don't have a way to get the "line count except irrelevant files"
IssueHunt