Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/davearonson/pull-request-roulette
Site to match up developers with people willing to comment on their pull requests
https://github.com/davearonson/pull-request-roulette
Last synced: 3 months ago
JSON representation
Site to match up developers with people willing to comment on their pull requests
- Host: GitHub
- URL: https://github.com/davearonson/pull-request-roulette
- Owner: davearonson
- Created: 2013-04-21T20:52:21.000Z (over 11 years ago)
- Default Branch: master
- Last Pushed: 2022-12-14T00:52:50.000Z (almost 2 years ago)
- Last Synced: 2024-05-28T14:21:45.021Z (5 months ago)
- Language: Ruby
- Size: 236 KB
- Stars: 29
- Watchers: 5
- Forks: 12
- Open Issues: 33
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
- Open-Source-Ruby-and-Rails-Apps - pull-request-roulette - Site to match up developers with people willing to comment on their pull requests 👴 🚀 (Happy Exploring 🤘)
README
pull-request-roulette
=====================
[](https://codeclimate.com/github/davearonson/pull-request-roulette)
[](https://travis-ci.org/davearonson/pull-request-roulette)
[](https://coveralls.io/r/davearonson/pull-request-roulette?branch=master)
[](https://gemnasium.com/davearonson/pull-request-roulette)
[](https://www.pullreview.com/github/davearonson/pull-request-roulette/reviews/master)
Web app to match up developers, with public pull requests (PRs) on Github, with
people willing to comment on their PRs.
The current workflow is:
- Project owner Polly has a project.
- Coder Carol submits a pull request to Polly's project.
- Either Carol or Polly (or currently, anybody!) submits Carol's PR to Pull
Request Roulette (PRR). Most likely, she'll have done that because Polly
just hasn't had the time to look at the PR and approve it.
- Reviewer Rachel comes to PRR, sees Carol's PR in the list, and "takes" it.
- It is now marked as under review by Rachel.
- The hope is that Rachel will give Carol's PR a thorough review, using
comments or email to notify Carol and Polly when done, and Rachel's comments
will help Polly decide whether to accept it.
- Eventually Carol or Rachel or Polly will come to PRR and mark the PR as no
longer under review, either to solicit more reviews, or to remove it from the
list. However, removal is not yet implemented.
Yes, that's very simple. There's only one thing being stored (a simple PR
descriptor), and it's not even full CRUD as there is no Update. But this is
just the MVP. The main workflow I envision eventually is:
- Project owner Polly has a project.
- Coder Carol submits a pull request to Polly's project.
- Either Carol or Polly (or *maybe* anybody) submits Carol's PR to PRR.
- PRR looks at what languages the files in the PR use, and lets the submitter
adjust the list. (This may be needed due to .txt files, or files with no
extension, being in some human language, so that for instance the reviewer
needs to know Chinese. Other than that, it means computer languages. It
might deduce some human languages from filenames like fr.yml. I do not
intend for it to grow language-detection from text, a la Google Translate.)
- Reviewer Rachel has registered at PRR, and possibly specified what languages
she knows.
- Rachel comes to PRR, and asks for a PR to review.
- PRR analyzes the possible matches, decides that Carol's is the best match,
and presents it (and no others) to her. This is the "roulette" aspect I'm
aiming for.
- That includes the details of how many files in what languages, how many
additions, deletions, and other changes, etc.
- Rachel may decline it and ask for a different one, but in this case let's say
she accepts, or in current parlance, "takes" it.
- PRR marks it as being assigned to Rachel for review.
- PRR notifies Carol and Polly... *if* it has their email addresses.
- Polly sees the email and thinks "hmmm, what is this PRR thing and how does it
have my email address?" (The answer is, either Polly signed up on PRR after
we established user profiles, or she made it public on Github.)
- Meanwhile, Reviewer Roger comes to PRR and asks for a PR to review.
- PRR determines that Carol's *would* be the best match for him, *except* that
it's already being reviewed, so it looks for the second best.
- Rachel makes comments on Github, mainly in the PR but possibly in the
project's issues. Github notifies Carol, Polly, and any other interested
parties; PRR is not involved.
- Rachel comes back to PRR, and marks the PRR as reviewed.
- PRR notifies Carol and Polly... *if* it has their email addresses.
- PRR asks Rachel to rate Carol as a coder.
- Carol comes back to PRR, and rates Rachel as a reviewer.
- Brief aggregate ratings as coder and/or reviewer are shown when someone lists
the users (at least, those who don't hide their profiles); more detailed
ratings, if we decide to have them, are shown when someone views their
profiles.
- Top coders and/or reviewers may be featured on the front page, newsletter,
etc.
If Rachel shirks her duty, then the fact that the PR has been "taken" will
count for less and less, when PRR decides on matches. Eventually, either the
PR could be marked as "untaken", or it could be under review by multiple
reviewers at once. There could be a "pestering" mechanism so that Rachel gets
reminded every few days... again, *if* we have her email address. We could
require it, but I don't like that idea.
See the Issues for possible features saved for later, known bugs to fix, etc.
The code is currently deployed at http://www.PullRequestRoulette.com, as a free
public service of [Codosaurus, LLC](http://www.Codosaur.us).