> 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  <raphine...@gmail.com>:
> 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 <
> piotrow...@gmail.com>:
>
>> 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 <piotrow...@gmail.com>:
>> > 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 <gandhiraja...@gmail.com>:
>> >> 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 <piotrow...@gmail.com>
>> 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: dev-unsubscr...@cordova.apache.org
>> >>> For additional commands, e-mail: dev-h...@cordova.apache.org
>> >>>
>> >>>
>> >>
>> >> --
>> >> Regards,
>> >> Gandhi
>> >>
>> >> "The best way to find urself is to lose urself in the service of others
>> !!!"
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
>> For additional commands, e-mail: dev-h...@cordova.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

Reply via email to