Moved to BirthdayResearch/oss-governance-bot for continued maintenance of project.
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.
- 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.
# .github/workflow/governance.yml
on:
pull_request_target:
types: [ synchronize, opened, labeled, unlabeled ]
issues:
types: [ opened, labeled, unlabeled ]
issue_comment:
types: [ created ]
# You can use permissions to modify the default permissions granted to the GITHUB_TOKEN,
# adding or removing access as required, so that you only allow the minimum required access.
permissions:
contents: read
issues: write
pull-requests: write
statuses: write
checks: write
jobs:
governance:
name: Governance
runs-on: ubuntu-latest
steps:
# Semantic versioning, lock to different version: v2, v2.0 or a commit hash.
- uses: BirthdayResearch/oss-governance-bot@v2
with:
# You can use a PAT to post a comment/label/status so that it shows up as a user instead of github-actions
github-token: ${{secrets.GITHUB_TOKEN}} # optional, default to '${{ github.token }}'
config-path: .github/governance.yml # optional, default to '.github/governance.yml'
# .github/governance.yml
version: v1
issue:
labels:
- prefix: triage
list: [ "accepted" ]
multiple: false
author_association:
collaborator: true
member: true
owner: true
needs:
comment: |
@$AUTHOR: This issue is currently awaiting triage.
The triage/accepted label can be added by org members by writing /triage accepted in a comment.
- prefix: kind
list: [ "feature", "bug", "question" ]
multiple: false
needs:
comment: |
@$AUTHOR: There are no 'kind' label on this PR. You need a 'kind' label to generate the release note automatically.
* `/kind feature`
* `/kind bug`
* `/kind question`
- prefix: area
list: [ "ui-ux", "semantics", "translation", "security" ]
multiple: true
needs:
comment: |
@$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!**
* `/area ui-ux`
* `/area semantics`
* `/area translation`
* `/area security`
- prefix: os
list: [ "mac", "win", "linux" ]
multiple: true
- prefix: priority
multiple: false
list: [ "urgent-now", "important-soon" ]
author_association:
collaborator: true
member: true
owner: true
chat_ops:
- cmd: /close
type: close
author_association:
author: true
collaborator: true
member: true
owner: true
- cmd: /cc
type: none
- cmd: /assign
type: assign
author_association:
collaborator: true
member: true
owner: true
- cmd: /comment issue
type: comment
comment: |
@$ISSUE_AUTHOR: Hey this is comment issue example for issue/pr author.
@$AUTHOR: Hey this is comment issue example for sender author.
pull_request:
labels:
- prefix: kind
multiple: false
list: [ "feature", "fix", "chore", "docs", "refactor", "dependencies" ]
needs:
comment: |
@$AUTHOR: There are no 'kind' label on this PR. You need a 'kind' label to generate the release automatically.
* `/kind feature`
* `/kind fix`
* `/kind chore`
* `/kind docs`
* `/kind refactor`
* `/kind dependencies`
status:
context: "Kind Label"
description:
success: Ready for review & merge.
failure: Missing kind label to generate release automatically.
- prefix: priority
multiple: false
list: [ "urgent-now", "important-soon" ]
author_association:
collaborator: true
member: true
owner: true
chat_ops:
- cmd: /close
type: close
author_association:
author: true
collaborator: true
member: true
owner: true
- cmd: /cc
type: none # does not trigger anything
- cmd: /request
type: review
author_association:
collaborator: true
member: true
owner: true
- cmd: /comment pr
type: comment
comment: |
@$AUTHOR: Hey this is comment pr example.
You can target pull_request
or issue
with labels
and/or chat_ops
.
version: v1
issue:
labels:
chat_ops:
pull_request:
labels:
chat_ops:
Author association to restrict who can trigger the operation. You can use this for both labels
and chat_ops
in issue
or pull_request
.
version: v1
issue:
labels:
- prefix: triage
list: [ "accepted" ]
author_association:
author: false
collaborator: true
contributor: true
first_timer: false
first_time_contributor: false
mannequin: false
member: true
none: false
owner: true
version: v1
pull_request:
labels:
- prefix: kind
multiple: false
list: [ "feature", "fix", "chore", "docs", "refactor", "dependencies" ]
needs:
comment: |
@$AUTHOR: There are no 'kind' label on this PR. You need a 'kind' label to generate the release automatically.
* `/kind feature`
* `/kind ...`
status:
context: "Governance/Kind"
description:
success: Ready for review & merge.
failure: Missing kind label to generate release automatically.
version: v1
issue:
chat_ops:
- cmd: /close
type: close
Review is only available for pull_request.
version: v1
pull_request:
chat_ops:
# /request-review @john @ben @more
- cmd: /request-review
type: review
version: v1
issue:
chat_ops:
# /assign @john @ben @more
- cmd: /assign
type: assign
Does nothing, might be useful to show it in governance.
version: v1
issue:
chat_ops:
- cmd: /cc
type: none
$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.
version: v1
issue:
chat_ops:
- cmd: /comment me
type: comment
comment: |
@$ISSUE_AUTHOR: Hey this is comment issue example for issue/pr author.
@$AUTHOR: Hey this is comment issue example for sender author.
Add or remove labels via chat ops.
version: v1
issue:
chat_ops:
- cmd: /label me
type: label
label:
add: kind/me
remove: [ 'label/remove', 'label/that' ]
Capture labels based on regex, optionally validate them against github_release.
version: v1
issue:
captures:
- regex: "- Version: *(.+)"
github_release: true # validate against github_release
label: 'version/$CAPTURED'
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.
npm i # npm 7 is used
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!