We use github issues for bugs, issues, concerns, questions from users.
When reporting bugs, they should be opened as a new issue on the individual repository where the issue is believed to be.
Those with contributor access can all help triage bugs and they'll follow these steps:
Most importantly, bug triagers should always be nice. We're grateful to know about issues, so if anybody responds rudely, please contact Henrik by email firstname.lastname@example.org. We're committed to making this whole process as inclusive and friendly as possible.
It's recommended, though not required, to jump into chat or open an issue before you take the time to write a pull request.
PRs are issues too and thus will receive a similar treatment.
Changes to repos should all happen via pull requests, even from project leads and core contributors.
All PRs should have 2 +1's contributors or project lead unless:
In which case a judgement call will be made by core team / project lead whether to just merge them.
We do our best to adhere strictly to semver throughout the project. This is crucial to the architectural approach we're taking with Ampersand.
Most merged pull requests will be published to npm immediately unless we're bundling up a few fixes for releases.
Many small documentation fixes don't justify a release, in which case we'll just merge them to the master branch and leave them there. We'll leave a comment with the version number of the npm release that contains the merged code.
We use the following labels on issues, these will get programmatically applied by a bot to all projects in the AmpersandJS organization on github:
breaking changes: Will change existing behavior, necessistates a major version bump per semver conventions
bug: It's broke, yo.
dependency: Changes/updates a dependency
discussion: Needs discussion or was opened for discussion.
documentation: Improves docs (we love this).
enhancement: Adds feature or improves functionality.
example: Adds example.
help wanted: We'd love help with this one, open for contributions and it's not yet been assigned.
new contributor: This is a good one for a new contributor to tackle. (note to contributors, if triaging and adding this label, please try to add as much detail/instruction as possible to help new contributor be successful).
non-issue: Assumed that this behavior isn't actually an issue.
question: This is a question, not a bug.
release notes: Related to adding or needing release notes.
request: This is a request for help or a for a feature.
security: This is a security related fix or concern.
test: Fixing/improving test coverage
If you have publish rights (which if you're on the core or community teams you can have at your request).
Here's the scripts we've been using to publish, just add something like this to your bash profile or equivalent. Then it's pretty simple just run
Eventually this may become part of some official release script. But anyway, here it is for your copy/paste enjoyment:
alias patch='git pull && npm version patch && git push && git push --tags && npm publish --registry https://registry.npmjs.org' alias minor='git pull && npm version minor && git push && git push --tags && npm publish --registry https://registry.npmjs.org' alias major='git pull && npm version major && git push && git push --tags && npm publish --registry https://registry.npmjs.org'