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 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 .
If this is welcome, I will create identical project boards for tooling and plugins. 
 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.
 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.
> - 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.
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.
2018-09-04 11:34 GMT+02:00 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 :/
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.
INFRA approved the use of the project-bot app .
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 ).