[Optional] Add Danger to our development workflow

[pengyin-shan]

Danger library [#70]

This is an optional step targeting to enhance our coding environment, we can discuss if we want to add this extra check or not

Danger (https://github.com/danger/danger) is a tool to automate some team conventions on code review, such as setting up reminders to update the CHANGELOG, adding more PR descriptions, adding tests for newly implemented methods, etc. It targets to give suggestions, so we can approve PRs even Danger test is not passed. It is totally based on our needs.

My previous team used it to prevent programmers from forgetting some contribution rules, such as changelog updates. I borrowed the rules but we are totally open to changing whatever the best for us. The code to define the rules is in dangerfile.js.

So far, the rules of danger suggestions are:

1. Add changelog
2. If the programmer feels that no need to update the CHANGELOG, add #trival to PR to eliminate this danger check
3. Encourage us to write at least some descriptions (line>=3) in PR so that we can refer back to it
4. Big PR (>500 lines of change) should be separated into smaller PR
5. Any working in process PR should have [WIP] somewhere so that code reviewers don't need to check
6. (Disabled currently since we don't have unit test) if someone makes lots of changes but with no test, Danger will give a reminder
7. (Update on Apr 14, 2023) If anyone modifies the .eslintrc file, GitHub will show a warning in PR to remind the submitter to double-check the necessity of modifying this file.

If we proceed with this PR, we will have a new Github action that runs whenever there's a push operation. We could get something like:

[pengyin-shan]

Hi @navarroc @sandeep-ps @ylyangtw , this is an old PR that will add danger to the GitHub workflow to automate some PR review points and is ready for your review.

[ylyangtw]

Looks good to me. Approve

[sandeep-ps]

Changes in lines 276-278 could be removed as they are not part of this PR. Thanks.

[pengyin-shan]

good catch, should be resolved in my last commit

[sandeep-ps]

Should this not run on PR since it'll be easier to catch any missing entries before the PR is merged?

[pengyin-shan]

I see what you mean. Looking back, I think it makes more sense to use:

on:
  pull_request:
    branches:
      - develop

This way, it will help to enhance PR creation practices without interrupting current release practices. Do you think will work better?