INFRA approved the use of the project-bot app [1]. It enables us to use automation on more than 5 repositories per project board. It also adds new functionality like automatic adding of new items (issues or PRs) to the project board, automatic moving based on additional triggers (adding ore removing of labels, assign state, milestone setting and much more [2]).
I am currently testing it for all active Cordova repositories at: https://github.com/orgs/apache/projects/5?fullscreen=true (You might notice the messages when the bot is active on issues or PRs) If this works out, we can use it to improve our PR project boards (less maintenance necessary) or build an issue project board (columns by label etc.). J [1] https://github.com/apps/project-bot [2] https://github.com/philschatz/project-bot#rules 2018-09-16 22:01 GMT+02:00 Jan Piotrowski <[email protected]>: > I had a few hours and created two additional project boards based on > the existing project boards, this time for the plugins with the most > PRs: > > https://github.com/orgs/apache/projects/9?fullscreen=true = camera, > file, inappbrowser, media splashscreen > https://github.com/orgs/apache/projects/10?fullscreen=true = dialogs, > geolocation, media-capture, statusbar, whitelist > These cover ~95% of all available plugin PRs I think. > > I already labeled all the PRs for the impacted platform and sorted > them into the correct columns based on the test status (which was a > real pain, as the plugin tests seem to fail for no reason at all or > even all the time - we should look into this in the neat future if we > ever want to get this under control) and if there is a conflict. There > is no priorization of the PRs inside a column, I just dropped stuff > into the correct one. > > I had also started to comment on some to get the original creator to > fix conflicts or failing tests, but stopped after Julio mentioned it > might not be the smartest thing to get people to do additional work on > PRs that will never be merged. He is of course rightd. We will have to > look at the conflicted PRs as well and close those with no chance of > merge. > > Best, > Jan > > > > 2018-09-05 16:56 GMT+02:00 <[email protected]>: >> Thanks again, Jan. >> >> Am Mi., 5. Sep. 2018 um 16:44 Uhr schrieb Jan Piotrowski < >> [email protected]>: >> >>> > I'd rather link cordova-create than cordova-js since the latter is not >>> > really tooling (it's kind of an outlier). >>> >>> Ok, changed. Makes sense. >>> >>> > But what's the difference between linked and unlinked repos anyway? >>> >>> 1. "Add Cards" has a nice "Only show results from linked repositories" >>> checkbox which makes it easier to add those PRs to the board. >>> 2. Automation rules are only triggered for linked repositories. So if >>> someone merges a PR, the card/PR is only moved to the respective lane >>> if it belongs to one of the linked repositories. >>> >>> No idea why GitHub had to limit this to 5. >>> There are workarounds/tools which I will test in the near future. They >>> are not really pretty though :/ >>> >>> -J >>> >>> 2018-09-05 14:58 GMT+02:00 <[email protected]>: >>> > Thanks for creating this Jan! >>> > >>> > I'd rather link cordova-create than cordova-js since the latter is not >>> > really tooling (it's kind of an outlier). >>> > But what's the difference between linked and unlinked repos anyway? >>> > >>> > Cheers, >>> > Raphael >>> > >>> > Am Mi., 5. Sep. 2018 um 12:39 Uhr schrieb Jan Piotrowski < >>> > [email protected]>: >>> > >>> >> Having (🤖/👩🔧) in the column title turned out to be a bad idea as >>> >> it made the messages added to PRs very noisy. >>> >> I removed them and added a card with the same information ("column >>> >> managed by 👩🔧 + 🤖") instead. >>> >> >>> >> As I personally did benefit from having the Platforms PR board in >>> >> going through all the existing PRs, I created another one for tooling: >>> >> >>> >> Apache Cordova: Tooling Pull Requests >>> >> https://github.com/orgs/apache/projects/8?fullscreen=true >>> >> Linked repositories: cordova-js cordova-cli cordova-lib cordova-common >>> >> cordova-fetch >>> >> >>> >> Unfortunately we hit the "5 linked repositories limit" here as >>> >> predicted, and cordova-create and cordova-serve, so I had to "Add >>> >> Cards" to them manually by searching for their PRs: `is:open is:pr >>> >> repo:apache/cordova-serve`. Will do some research to see if there is a >>> >> workaround for that. >>> >> >>> >> Best, >>> >> Jan >>> >> >>> >> 2018-09-04 11:34 GMT+02:00 Jan Piotrowski <[email protected]>: >>> >> > Thanks Raphael, good questions: >>> >> > >>> >> >> - What's the difference between: "Waiting for Review" and "Pending >>> >> Approval"? >>> >> > >>> >> > Yep, that was a new thing for me as well. Let me explain: >>> >> > "Waiting for Review" is a state we manually give to a PR after we had >>> >> > a look and the title and description is ok, the changes make sense and >>> >> > there are no conflicts or failing tests. >>> >> > "Pending Approval" is a state that the automation gives to a PR when >>> >> > there was some review activity (e.g. "comment" or "request changes") >>> >> > but the PR is not _approved_ (yet). >>> >> > This also applies in the case that the repo has a "3 approvals before >>> >> > merge" requirement for example, then a PR with 1 approval would move >>> >> > to that column. >>> >> > Maybe also if someone leaves a review who is not a maintainer - but I >>> >> > am not 100% sure about that. >>> >> > One could also call the column "Review in progress" maybe - but I >>> >> > wanted to see it in practice first to be honest. >>> >> > >>> >> >> - Do we need to distinguish "Blocked: Tests failing" and "Blocked: >>> >> Conflict"? >>> >> > >>> >> > We don't need to, but I thought it might be handy. >>> >> > A PR in the "tests failing" can be moved to "waiting for review" when >>> >> > there is not red x any more that indicates a failing test (because >>> >> > there was a new commit or tests were rerun). For conflicts, there is >>> >> > no visual indicator and the PR _has_ to be checked manually. >>> >> > If there is not much use for that, we can collapse both columns into >>> >> > one without much effort. But for now I would leave it as it is to get >>> >> > some experience with it. >>> >> > >>> >> > Best, >>> >> > Jan >>> >> > >>> >> > >>> >> > >>> >> > 2018-09-03 18:16 GMT+02:00 gandhi rajan <[email protected]>: >>> >> >> Looks great Jan. But for some reason I m not able to see the emojis >>> in >>> >> my >>> >> >> chrome browser. Does anyone else have the same issue? >>> >> >> >>> >> >> On Mon, Sep 3, 2018 at 6:13 PM Jan Piotrowski <[email protected]> >>> >> wrote: >>> >> >> >>> >> >>> Hi, >>> >> >>> >>> >> >>> with the switch to GitHub for issues I started looking into GitHub >>> >> >>> Project boards to help us manage Issues and Pull Requests. >>> >> >>> >>> >> >>> The first concrete result of this is ready for feedback: >>> >> >>> >>> >> >>> Apache Cordova - Platforms Pull Requests >>> >> >>> https://github.com/orgs/apache/projects/7 >>> >> >>> >>> >> >>> As the name implies, this board contains all Pull Requests for the >>> >> >>> Platform repositories (ios, android, windows, osx, browser). It can >>> be >>> >> >>> used to 1) get an overview of all the PRs for several repositories >>> at >>> >> >>> the same time and 2) help us maintainers to find PRs to comment on, >>> >> >>> test and approve or merge. >>> >> >>> >>> >> >>> The project board contains these columns: >>> >> >>> >>> >> >>> - 🐣 New PR / Untriaged (🤖/👩🔧) >>> >> >>> - 👷 Blocked: Work in Progress (👩🔧) >>> >> >>> - ⛔ Blocked: Tests failing (👩🔧) >>> >> >>> - 💥 Blocked: Conflict (👩🔧) >>> >> >>> - ⏳ Waiting for Review (👩🔧) >>> >> >>> - 🙅 Pending Approval (🤖) >>> >> >>> - ✅ Approved, waiting for Merge (🤖) >>> >> >>> - 🏆 Merged, waiting for Release (🤖) >>> >> >>> - ☠️ Closed/Abandoned (🤖) >>> >> >>> - 🎈 Released (👩🔧) >>> >> >>> >>> >> >>> The columns itself should cover all the common cases we can >>> encounter >>> >> >>> with PRs (Did I miss anything that should be tracked?). >>> >> >>> >>> >> >>> The column a PR is currently located in is shown in the "Projects" >>> >> >>> section of the sidebar of the PR on GitHub. Each time a PR is moved, >>> >> >>> the PR gets a "<username> moved this from <foo> to <bar>" line added >>> >> >>> at the bottom. The emojis make parsing these info bits a lot easier. >>> >> >>> >>> >> >>> New PRs can be added to this board a) semi-automatically by clicking >>> >> >>> the "Cog" icon next to "Projects" in the sidebar of a PR on Github >>> and >>> >> >>> then selecting the board or b) by using the "Add cards" >>> functionality >>> >> >>> on the board itself. There is no way to fully automatically add new >>> >> >>> PRs to this board yet [1]. >>> >> >>> >>> >> >>> The emojis at the end of the column description (🤖/👩🔧) explain >>> who >>> >> >>> is responsible for getting PRs into or out of a lane. As you can see >>> >> >>> only the first 5 columns (and the last one) have to be handled >>> >> >>> manually, the rest is automated. >>> >> >>> Our "work" on this board is only to get all PRs from "New PR" to >>> >> >>> "Waiting for Review" in the board. Then the automation takes over by >>> >> >>> looking if a PR is approved, merged or closed on GitHub itself. At >>> the >>> >> >>> end we can manually track what PRs were released to users. >>> >> >>> >>> >> >>> >>> >> >>> Feedback or Comments? >>> >> >>> >>> >> >>> If this is welcome, I will create identical project boards for >>> tooling >>> >> >>> and plugins. [2] >>> >> >>> >>> >> >>> Best, >>> >> >>> Jan >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> [1] If this project board is considered useful and will be used, >>> there >>> >> >>> are options to automatically add new PRs to this column via GitHub >>> >> >>> apps. We certainly could use this, but I didn't want to spend the >>> time >>> >> >>> to configure this up front. >>> >> >>> >>> >> >>> [2] It will be interesting to see how the automation will work for >>> >> >>> e.g. Plugins where we have >5 repositories. Probably we will also >>> need >>> >> >>> a workaround the "5 repo per project board" limit from Github via an >>> >> >>> GitHub app. >>> >> >>> >>> >> >>> >>> --------------------------------------------------------------------- >>> >> >>> To unsubscribe, e-mail: [email protected] >>> >> >>> For additional commands, e-mail: [email protected] >>> >> >>> >>> >> >>> >>> >> >> >>> >> >> -- >>> >> >> Regards, >>> >> >> Gandhi >>> >> >> >>> >> >> "The best way to find urself is to lose urself in the service of >>> others >>> >> !!!" >>> >> >>> >> --------------------------------------------------------------------- >>> >> To unsubscribe, e-mail: [email protected] >>> >> For additional commands, e-mail: [email protected] >>> >> >>> >> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
