For the `closed_issue_locker` behavior, this is a migration to an equivalent action.
For the `label_issue_migrater` behavior, this is not replaced and instead it is suggested to use native GitHub functionality for issue transfer. If mostly equivalent behavior is desired via label automation, it may be possible to submit an issue transfer feature request to dessant/label-actions as it is a popular community action or create a new GitHub Action. Please reach out if this is a major issue for your team.
For the `remove_labels_on_reply` behavior, it is equivalent except this initial configuration does not make the collaborators distinction. There is a workflow configuration workaround for setting up per-user ignores for any job/step, so if you desire that here please reach out.
This requires more GitHub token permissions than we have, and it's
inessential. The backport PRs should have reviews assigned to the
original PR author anyway.
Add a written bug triage process and link to it in README.md
Bug process
Remove goals, edit for brevity, and move how to write a good issue report to bug report template
link HashiCorp GPG key in bug report template
add summary links for triage process
Our documentation for how to contribute was in quite a state of disrepair,
with some documents still describing things as they were before moving
providers into separate repositories, others making assumptions about
Go development that are no longer true in modules mode, and so forth.
This is an attempt at a reset to a good state that should work with the
codebase as it currently stands, and should hopefully serve as a basis
for iterative improvement from here.
These new instructions lean primarily on standard Go toolchain usage and
instruct using the Makefile only for some Terraform-specific situations
that the Go toolchain does not automatically handle. The idea here is that
this direct usage of primary commands in the Go toolchain is less likely
to be broken by changes in future Go releases, and should be immediately
familiar to anyone who has experience with Go development.
Brian Flad