项目作者: DeFiCh

项目描述 :
Speed up issue triaging with automated chat-bot and chat-ops operations. Increased code review agility by moving quality control hierarchy from requirements to educational steps.
高级语言: TypeScript
项目地址: git://github.com/DeFiCh/oss-governance-bot.git
创建时间: 2021-02-01T16:11:21Z
项目社区:https://github.com/DeFiCh/oss-governance-bot

开源协议:MIT License

下载


Moved to BirthdayResearch/oss-governance-bot for continued maintenance of project.

OSS Governance Bot

codecov
Codacy Badge
Release
License MIT

Although putting our project on GitHub makes it transparent and visible for public contributions, it’s far from making
it maintainable. For new contributors, creating an issue or pull request and successfully sending it is a mountainous
journey in itself. Quality control hierarchy such as ‘Triage’, ‘Conventional Commits’, ‘CI steps’ and ‘Code review’
often deter contributors from contributing due to the complex nature of each OSS governance policy.

A healthy open source projects must be able to scale to thousands of contributors. This project is an attempt to bring
efficacy to the process by lowering the barrier of entry for community participation. The onus should be on the
reviewers or ChatBot/ChatOp to guide the contributor through a series of education (governance/triage requirements) or
adjustment (code review changes).

This project is created to fully utilize the GitHub generous open source policy. It runs on GitHub Actions workflow
hooks and deeply integrate with many GitHub offerings. In addition to providing a chat-bot experience when contributor
interact with your project, oss-governance-bot also provide automation in the form of policy enforcement. Community
contributors can trigger chat-ops via /slash style commands.

What can OSS Governance Bot do for you?

  • Speed up issue triaging with automated chat-bot and chat-ops operations.
  • Increased code review agility by moving quality control hierarchy from requirements to educational steps.
  • Scale to thousands of contributors without alienating community participation with complex quality control hierarchy.
  • A GitHub Action that lives natively and integrate well with the GitHub action/workflow product offering. You can view
    the source directly and modify it to your needs.
  • See it in action at DeFiCh/jellyfish
    or DeFiCh/scan.

preview

Usage

.github/workflow/governance.yml

  1. # .github/workflow/governance.yml
  2. on:
  3. pull_request_target:
  4. types: [ synchronize, opened, labeled, unlabeled ]
  5. issues:
  6. types: [ opened, labeled, unlabeled ]
  7. issue_comment:
  8. types: [ created ]
  9. # You can use permissions to modify the default permissions granted to the GITHUB_TOKEN,
  10. # adding or removing access as required, so that you only allow the minimum required access.
  11. permissions:
  12. contents: read
  13. issues: write
  14. pull-requests: write
  15. statuses: write
  16. checks: write
  17. jobs:
  18. governance:
  19. name: Governance
  20. runs-on: ubuntu-latest
  21. steps:
  22. # Semantic versioning, lock to different version: v2, v2.0 or a commit hash.
  23. - uses: BirthdayResearch/oss-governance-bot@v2
  24. with:
  25. # You can use a PAT to post a comment/label/status so that it shows up as a user instead of github-actions
  26. github-token: ${{secrets.GITHUB_TOKEN}} # optional, default to '${{ github.token }}'
  27. config-path: .github/governance.yml # optional, default to '.github/governance.yml'

.github/governance.yml

  1. # .github/governance.yml
  2. version: v1
  3. issue:
  4. labels:
  5. - prefix: triage
  6. list: [ "accepted" ]
  7. multiple: false
  8. author_association:
  9. collaborator: true
  10. member: true
  11. owner: true
  12. needs:
  13. comment: |
  14. @$AUTHOR: This issue is currently awaiting triage.
  15. The triage/accepted label can be added by org members by writing /triage accepted in a comment.
  16. - prefix: kind
  17. list: [ "feature", "bug", "question" ]
  18. multiple: false
  19. needs:
  20. comment: |
  21. @$AUTHOR: There are no 'kind' label on this PR. You need a 'kind' label to generate the release note automatically.
  22. * `/kind feature`
  23. * `/kind bug`
  24. * `/kind question`
  25. - prefix: area
  26. list: [ "ui-ux", "semantics", "translation", "security" ]
  27. multiple: true
  28. needs:
  29. comment: |
  30. @$AUTHOR: There are no area labels on this issue. Adding an appropriate label will greatly expedite the process for us. You can add as many area as you see fit. **If you are unsure what to do you can ignore this!**
  31. * `/area ui-ux`
  32. * `/area semantics`
  33. * `/area translation`
  34. * `/area security`
  35. - prefix: os
  36. list: [ "mac", "win", "linux" ]
  37. multiple: true
  38. - prefix: priority
  39. multiple: false
  40. list: [ "urgent-now", "important-soon" ]
  41. author_association:
  42. collaborator: true
  43. member: true
  44. owner: true
  45. chat_ops:
  46. - cmd: /close
  47. type: close
  48. author_association:
  49. author: true
  50. collaborator: true
  51. member: true
  52. owner: true
  53. - cmd: /cc
  54. type: none
  55. - cmd: /assign
  56. type: assign
  57. author_association:
  58. collaborator: true
  59. member: true
  60. owner: true
  61. - cmd: /comment issue
  62. type: comment
  63. comment: |
  64. @$ISSUE_AUTHOR: Hey this is comment issue example for issue/pr author.
  65. @$AUTHOR: Hey this is comment issue example for sender author.
  66. pull_request:
  67. labels:
  68. - prefix: kind
  69. multiple: false
  70. list: [ "feature", "fix", "chore", "docs", "refactor", "dependencies" ]
  71. needs:
  72. comment: |
  73. @$AUTHOR: There are no 'kind' label on this PR. You need a 'kind' label to generate the release automatically.
  74. * `/kind feature`
  75. * `/kind fix`
  76. * `/kind chore`
  77. * `/kind docs`
  78. * `/kind refactor`
  79. * `/kind dependencies`
  80. status:
  81. context: "Kind Label"
  82. description:
  83. success: Ready for review & merge.
  84. failure: Missing kind label to generate release automatically.
  85. - prefix: priority
  86. multiple: false
  87. list: [ "urgent-now", "important-soon" ]
  88. author_association:
  89. collaborator: true
  90. member: true
  91. owner: true
  92. chat_ops:
  93. - cmd: /close
  94. type: close
  95. author_association:
  96. author: true
  97. collaborator: true
  98. member: true
  99. owner: true
  100. - cmd: /cc
  101. type: none # does not trigger anything
  102. - cmd: /request
  103. type: review
  104. author_association:
  105. collaborator: true
  106. member: true
  107. owner: true
  108. - cmd: /comment pr
  109. type: comment
  110. comment: |
  111. @$AUTHOR: Hey this is comment pr example.

Configuration

You can target pull_request or issue with labels and/or chat_ops.

  1. version: v1
  2. issue:
  3. labels:
  4. chat_ops:
  5. pull_request:
  6. labels:
  7. chat_ops:

Author Association

Author association to restrict who can trigger the operation. You can use this for both labels and chat_ops
in issue or pull_request.

  1. version: v1
  2. issue:
  3. labels:
  4. - prefix: triage
  5. list: [ "accepted" ]
  6. author_association:
  7. author: false
  8. collaborator: true
  9. contributor: true
  10. first_timer: false
  11. first_time_contributor: false
  12. mannequin: false
  13. member: true
  14. none: false
  15. owner: true

Labels

  1. version: v1
  2. pull_request:
  3. labels:
  4. - prefix: kind
  5. multiple: false
  6. list: [ "feature", "fix", "chore", "docs", "refactor", "dependencies" ]
  7. needs:
  8. comment: |
  9. @$AUTHOR: There are no 'kind' label on this PR. You need a 'kind' label to generate the release automatically.
  10. * `/kind feature`
  11. * `/kind ...`
  12. status:
  13. context: "Governance/Kind"
  14. description:
  15. success: Ready for review & merge.
  16. failure: Missing kind label to generate release automatically.

ChatOps: close

  1. version: v1
  2. issue:
  3. chat_ops:
  4. - cmd: /close
  5. type: close

ChatOps: review

Review is only available for pull_request.

  1. version: v1
  2. pull_request:
  3. chat_ops:
  4. # /request-review @john @ben @more
  5. - cmd: /request-review
  6. type: review

ChatOps: assign

  1. version: v1
  2. issue:
  3. chat_ops:
  4. # /assign @john @ben @more
  5. - cmd: /assign
  6. type: assign

ChatOps: none

Does nothing, might be useful to show it in governance.

  1. version: v1
  2. issue:
  3. chat_ops:
  4. - cmd: /cc
  5. type: none

ChatOps: comment

  • $AUTHOR is the user that send the /chat-ops, comment/issue/pull_request.
  • $ISSUE_AUTHOR is the user that owns the current issue/pull_request.
  1. version: v1
  2. issue:
  3. chat_ops:
  4. - cmd: /comment me
  5. type: comment
  6. comment: |
  7. @$ISSUE_AUTHOR: Hey this is comment issue example for issue/pr author.
  8. @$AUTHOR: Hey this is comment issue example for sender author.

ChatOps: label

Add or remove labels via chat ops.

  1. version: v1
  2. issue:
  3. chat_ops:
  4. - cmd: /label me
  5. type: label
  6. label:
  7. add: kind/me
  8. remove: [ 'label/remove', 'label/that' ]

Captures: Regex

Capture labels based on regex, optionally validate them against github_release.

  1. version: v1
  2. issue:
  3. captures:
  4. - regex: "- Version: *(.+)"
  5. github_release: true # validate against github_release
  6. label: 'version/$CAPTURED'

Development & Contribution

IntelliJ IDEA is the IDE of choice for writing and maintaining this code library. IntelliJ’s files are included for
convenience with toolchain setup but usage of IntelliJ is optional.

  1. npm i # npm 7 is used
  2. npm run all # to build/check/lint/package
  • For any question please feel free to create an issue.
  • Pull request for non-breaking features are welcomed too!
  • Although all features were created specifically for Birthday Research needs;
    you should not limit yourself to our offering. Feel free to fork the project. Appreciate if you mention us!

Prior art