Skip to content

Commit

Permalink
chore: release version 0.1.1 (#40)
Browse files Browse the repository at this point in the history
* chore: release new version

* Improve maintainer contribution guidelines
  • Loading branch information
WilliamBergamin authored Aug 6, 2024
1 parent 77dcac0 commit 9ddcdfc
Show file tree
Hide file tree
Showing 5 changed files with 56 additions and 50 deletions.
35 changes: 19 additions & 16 deletions .github/contributing.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,25 +7,28 @@ well.
There are many ways you can contribute! :heart:

### Bug Reports and Fixes :bug:
- If you find a bug, please [create a new issue](https://github.com/slackapi/slack-health-score/issues/new). Fill out the "Bug Report" section of the issue template. Even if an Issue is closed, feel free to comment and add details, it will still

- If you find a bug, please [create a new issue](https://github.com/slackapi/slack-health-score/issues/new). Fill out the "Bug Report" section of the issue template. Even if an Issue is closed, feel free to comment and add details, it will still
be reviewed.
- Issues that have already been identified as a bug (note: able to reproduce) will be labelled `bug`.
- If you'd like to submit a fix for a bug, [send a Pull Request](#creating_a_pull_request) and mention the Issue number.
- Include tests that isolate the bug and verifies that it was fixed.
- Issues that have already been identified as a bug (note: able to reproduce) will be labelled `bug`.
- If you'd like to submit a fix for a bug, [send a Pull Request](#creating_a_pull_request) and mention the Issue number.
- Include tests that isolate the bug and verifies that it was fixed.

### New Features :bulb:
- If you'd like to add new functionality to this project, describe the problem you want to solve in a [new Issue](https://github.com/slackapi/slack-health-score/issues/new).
- Issues that have been identified as a feature request will be labelled `enhancement`.
- If you'd like to implement the new feature, please wait for feedback from the project

- If you'd like to add new functionality to this project, describe the problem you want to solve in a [new Issue](https://github.com/slackapi/slack-health-score/issues/new).
- Issues that have been identified as a feature request will be labelled `enhancement`.
- If you'd like to implement the new feature, please wait for feedback from the project
maintainers before spending too much time writing the code. In some cases, `enhancement`s may
not align well with the project objectives at the time.

### Tests :mag:, Documentation :books:, Miscellaneous :sparkles:
- If you'd like to improve the tests, you want to make the documentation clearer, you have an

- If you'd like to improve the tests, you want to make the documentation clearer, you have an
alternative implementation of something that may have advantages over the way its currently
done, or you have any other change, we would be happy to hear about it!
- If its a trivial change, go ahead and [send a Pull Request](#creating_a_pull_request) with the changes you have in mind.
- If not, [open an Issue](https://github.com/slackapi/slack-health-score/issues/new) to discuss the idea first.
- If its a trivial change, go ahead and [send a Pull Request](#creating_a_pull_request) with the changes you have in mind.
- If not, [open an Issue](https://github.com/slackapi/slack-health-score/issues/new) to discuss the idea first.

If you're new to our project and looking for some way to make your first contribution, look for
Issues labelled `good first contribution`.
Expand All @@ -45,13 +48,13 @@ If the contribution doesn't meet the above criteria, you may fail our automated

## Creating a Pull Request

1. :fork_and_knife: Fork the repository on GitHub.
2. :runner: Clone/fetch your fork to your local development machine. It's a good idea to run the tests just
1. :fork_and_knife: Fork the repository on GitHub.
2. :runner: Clone/fetch your fork to your local development machine. It's a good idea to run the tests just
to make sure everything is in order.
3. :herb: Create a new branch and check it out.
4. :crystal_ball: Make your changes and commit them locally. Magic happens here!
5. :arrow_heading_up: Push your new branch to your fork. (e.g. `git push username fix-issue-16`).
6. :inbox_tray: Open a Pull Request on github.com from your new branch on your fork to `main` in this
3. :herb: Create a new branch and check it out.
4. :crystal_ball: Make your changes and commit them locally. Magic happens here!
5. :arrow_heading_up: Push your new branch to your fork. (e.g. `git push username fix-issue-16`).
6. :inbox_tray: Open a Pull Request on github.com from your new branch on your fork to `main` in this
repository.

## Maintainers
Expand Down
12 changes: 7 additions & 5 deletions .github/issue_template.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,8 @@

Describe your issue here.

### What type of issue is this? (place an `x` in one of the `[ ]`)
### What type of issue is this? <!-- place an `x` in one of the `[ ]` -->

- [ ] bug
- [ ] enhancement (feature request)
- [ ] question
Expand All @@ -11,10 +12,11 @@ Describe your issue here.
- [ ] testing related
- [ ] discussion

### Requirements (place an `x` in each of the `[ ]`)
* [ ] I've read and understood the [Contributing guidelines](https://github.com/slackapi/slack-health-score/blob/main/.github/contributing.md) and have done my best effort to follow them.
* [ ] I've read and agree to the [Code of Conduct](https://slackhq.github.io/code-of-conduct).
* [ ] I've searched for any related issues and avoided creating a duplicate issue.
### Requirements <!-- place an `x` in one of the `[ ]` -->

- [ ] I've read and understood the [Contributing guidelines](https://github.com/slackapi/slack-health-score/blob/main/.github/contributing.md) and have done my best effort to follow them.
- [ ] I've read and agree to the [Code of Conduct](https://slackhq.github.io/code-of-conduct).
- [ ] I've searched for any related issues and avoided creating a duplicate issue.

---

Expand Down
53 changes: 27 additions & 26 deletions .github/maintainers_guide.md
Original file line number Diff line number Diff line change
Expand Up @@ -30,21 +30,22 @@ avoid accidently leaking tokens!

### Releasing

* Check the status of this project's GitHub Milestone to be released for issues that should be shipped with the release.
- If all issues have been closed, continue with the release.
- If issues are still open, discuss with the team about whether the open issues should be moved to a future release or if the release should be held off until the issues are resolved.
- Take a look at all issues under the Milestone to make sure that the type of issues included aligns with the Milestone name based on [semantic versioning](https://semver.org/). If the issues do not align with the naming of the Milestone (ex: if the issues are all bug fixes, but the Milestone is labeled as a minor release), then you can tweak the Milestone name to reflect the correct versioning.
* Update the version in `package.json`.
* Update all references to versions in the README and in the workflow files under `example-workflows/` to refer to the latest release.
* Run all tests using `npm test` to make sure the tests pass.
* Commit the changes on your `main` branch.
* Create a GitHub Release:
- check the "Publish this Action to the GitHub Marketplace" checkbox
- input a manual tag in the "Choose a tag" input that matches the version in `package.json`; click the "Create a new tag" button under the input (this will not immediately create a tag, but only once you are doing creating the release)
- manually select the previous latest tag in the "Previous tag" dropdown, then click "Generate release notes" and review them: make sure they make sense for a consumer of the Action
- release title should be automaticaly populated to match the new tag name
- click "Publish release". This will trigger the `publish.yml` GitHub workflow, which, once complete, will also overwrite the major, minor and patch tags of this project
* Once released, make sure to close the relevant GitHub Milestone for the version you released. Optionally, create any new milestones representing the next major/minor/patch releases, if applicable and if makes sense.
1. Look at the issues merged since the last release and consult the contributors to the next version to release. It must follow [semantic versioning](https://semver.org/).
2. Create a new branch from `main` name it the release version (example: `v0.1.1`)
1. Update the `"version"` field in `package.json`.
2. Update all references to versions in the `README.md` to refer to the latest release.
3. Run all tests using `npm test` to make sure the tests pass.
3. Commit the changes and open a Pull Request to merge your release branch into `main`.
4. Create a GitHub Release:
1. `Draft a new release` from the [release page](https://github.com/slackapi/slack-health-score/releases).
2. Check the "Publish this Action to the GitHub Marketplace" checkbox.
3. Leave the default settings for this project.
4. Input a manual tag in the "Choose a tag" input that matches the version in `package.json`; click the "Create a new tag" button under the input. (this will not immediately create a tag, but only once you are doing creating the release)
5. Manually select the previous latest tag in the "Previous tag" dropdown, then click "Generate release notes" and review them: make sure they make sense for a consumer of the Action.
6. Release title should be automatically populated to match the new tag name. (example: `v0.1.1`)
7. Check the `Set as the latest release` box.
8. Click "Publish release". This will trigger the `publish.yml` GitHub workflow, which, once complete, will also overwrite the major, minor and patch tags of this project
5. Notify the appropriate channels of the release.

## Workflow

Expand All @@ -70,18 +71,18 @@ After a major version increment, there also may be maintenance branches created

Labels are used to run issues through an organized workflow. Here are the basic definitions:

* `bug`: A confirmed bug report. A bug is considered confirmed when reproduction steps have been
* `bug`: A confirmed bug report. A bug is considered confirmed when reproduction steps have been
documented and the issue has been reproduced.
* `enhancement`: A feature request for something this package might not already do.
* `docs`: An issue that is purely about documentation work.
* `tests`: An issue that is purely about testing work.
* `needs feedback`: An issue that may have claimed to be a bug but was not reproducible, or was otherwise missing some information.
* `discussion`: An issue that is purely meant to hold a discussion. Typically the maintainers are looking for feedback in this issues.
* `question`: An issue that is like a support request because the user's usage was not correct.
* `semver:major|minor|patch`: Metadata about how resolving this issue would affect the version number.
* `security`: An issue that has special consideration for security reasons.
* `good first contribution`: An issue that has a well-defined relatively-small scope, with clear expectations. It helps when the testing approach is also known.
* `duplicate`: An issue that is functionally the same as another issue. Apply this only if you've linked the other issue by number.
* `enhancement`: A feature request for something this package might not already do.
* `docs`: An issue that is purely about documentation work.
* `tests`: An issue that is purely about testing work.
* `needs feedback`: An issue that may have claimed to be a bug but was not reproducible, or was otherwise missing some information.
* `discussion`: An issue that is purely meant to hold a discussion. Typically the maintainers are looking for feedback in this issues.
* `question`: An issue that is like a support request because the user's usage was not correct.
* `semver:major|minor|patch`: Metadata about how resolving this issue would affect the version number.
* `security`: An issue that has special consideration for security reasons.
* `good first contribution`: An issue that has a well-defined relatively-small scope, with clear expectations. It helps when the testing approach is also known.
* `duplicate`: An issue that is functionally the same as another issue. Apply this only if you've linked the other issue by number.

**Triage** is the process of taking new issues that aren't yet "seen" and marking them with a basic
level of information with labels. An issue should have **one** of the following labels applied:
Expand Down
4 changes: 2 additions & 2 deletions .github/pull_request_template.md
Original file line number Diff line number Diff line change
@@ -1,8 +1,8 @@
### Summary
### Summary

Describe the goal of this PR. Mention any related Issue numbers.

### Requirements (place an `x` in each `[ ]`)
### Requirements <!-- place an `x` in each `[ ]` -->

* [ ] I've read and understood the [Contributing Guidelines](https://github.com/slackapi/slack-health-score/blob/main/.github/contributing.md) and have done my best effort to follow them.
* [ ] I've read and agree to the [Code of Conduct](https://slackhq.github.io/code-of-conduct).
2 changes: 1 addition & 1 deletion package.json
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"name": "slack-health-score",
"version": "0.1.0",
"version": "0.1.1",
"description": "A rough health score reporter",
"main": "dist/index.js",
"scripts": {
Expand Down

0 comments on commit 9ddcdfc

Please sign in to comment.