Open Source DevKit

Machine Shop

Visible to members of this folder

Open Source DevKit

Overview

In this project, we are going to build three tools:

A command line interface `to GitHub, for querying and manipulating PR, searching issues, and generally improve the command line workflow for contributors to scikit-image.

A web dashboard that displays different views on existing GitHub projects. E.g., we might want to see which issues are tied to merged PRs, which PRs haven’t had discussion for a while, or which PRs are awaiting review.

A bot, that will be able to do small tasks on PRs.

Team

Teddy Tran @teddytheodoretran248@berkeley.edu

Claudia Tse @claudiatse@berkeley.edu

Winn Cui @Winn C

Advisors

@Stefan v

@Juan N

@Matthias B

@Matthew B

Reading

To kick off the semester, please familiarize yourself with the following documents:

https://matthew-brett.github.io/curious-git/curious_intro.html (read by: 15/06/2017)

https://developer.github.com/v4/

Component Descriptions

Command line tool

@Juan N, @Matthew B Please help me to fill out this section

Pull down a PR by number or URL

Push changes back to that PR

List all PRs

@Ralf G says: it would also be useful to list PRs by Milestone. Ideally in two ways, by Milestone as set in the Github UI, and as actually merged (because not everyone puts PRs under the right milestone when merging). For the latter, can reuse code from https://github.com/numpy/numpy/blob/master/tools/announce.py

Search for a keyword in PRs

Some caching mecanisms to avoid querying the Github API all the time.

Web dashboard

@Nelle V, @Matthew B Please help me to fill out this section form your notes

Pull requests related features:

Display list of PRs that haven’t had a comment in over a week

Most active pull requests “hot topics”

The PRs on which “I” have commented before.

PRs that haven’t seen any discussion.

Stalled PRs

No discussion at all

Discussion that stopped + time between the stalled discussion and now

List of oldest, unmerged PRs

Duplicate PRs (closing the same ticket).

Unmergeable PRs (that need to be rebased).

PRs that passed the majority of tests.

Issues related features

New issues without any comments.

Recently merged PR referring to a ticket that hasn’t been closed

Tickets being referred to many times.

Issues that external projects refer to.

/ping @

~~We’ll build the dashboard on top of cesium/baselayer, which provides a Python~~ ~~(Tornado)~~ ~~webserver, with WebSockets for communication between backend and frontend.~~

We’ll build the dashboard as static pages to start with, for simplicity.

Bot

I don’t really know what the bot should do, yet, even though we had discussed this many times before. I think @Matthias B and @Matthew B had some ideas! Also @Nathaniel S and @Ralf G

GitHub now has: https://github.com/probot/probot --- can we build plugins for what we need?

Matthias:

The bot can allow you to have finer grained permissions, and to allow simpler executing of commands.

For example; even if a PR is tagged “waiting for author to apply changes” you can have the author to “@bot ready”. You can look at the set of commands that https://github.com/MeeseeksBox/MeeseeksDev has, and take inspiration from other bots, like HighFive , Homu, Bors, and Facebook’s MentionBot. They in general:

Welcome first time contributors with instructions, make sure to assign reviewer and that reviewers respond in time, when a PR is ready they are the one responsible from putting it on the merge queue, and check that the test suite pass before going to the next PR (unlike travis that test when the PR is submitted and does not rebuild everytime master have changed in the meantime.

A few other things that (I believe) would be great is:

if you can complain you can fix it: Instead of failing on linting, run something like YAPF/autopep8 and submit a PR against the PR.

Welcome non-core contributor with a “Expected time to review and merge”, with potentially guides to make that faster (hey your PR is 1200 lines long, please consider splitting this in smaller chunks).

Travis often fails for arbitrary reasons, have the ability for PR author to relaunch the test of their PR.

Ralf:

It’s important a bot is not too noisy. So for example a coverage bot should either update it’s first comment, or add a new one but delete its old one. That probably applies to any bot that reports on something (like code style checks). Configurable, preferably add to the “checks” list (like where TravisCI/CircleCI statutes go), or otherwise either silent or a single one that keeps updating.