Contributions are welcome and will be fully credited.
Please read and understand the contribution guide before creating an issue or pull request.
It is up to the package author to maintain the repository after it has been released.
You'll be given admin rights to your repo. So you are in total control. Only if you ever do something like breaking semver we'll step in.
If some problems should arise you're always free to copy over the code to your own repo and abandon the one in our organization.
Probably we, as a community, will step in until we find a replacement.
Technically: Admin rights, and you may do with the code whatever your want.
As an admin, package maintainers can choose their own collaborators.
If you need help with anything just ask us. We're nice guys.
You're reading them. If we have the same values (creating a good experience for the users) we don't need too many rules.
For package users: an excellent experience
For package creators: a small ecosystem of package creators that can help each other
These projects are open source, and as such, the maintainers give their free time to build and maintain the source code held within. They make the code freely available in the hope that it will be of use to other developers. It would be extremely unfair for them to suffer abuse or anger for their hard work.
Please be considerate towards maintainers when raising issues or presenting pull requests. Let's show the world that developers are civilized and selfless people.
It's the duty of the maintainer to ensure that all submissions to the project are of sufficient quality to benefit the project. Many developers have different skillsets, strengths, and weaknesses. Respect the maintainer's decision, and do not be upset or abusive if your submission is not used.
When requesting or submitting new features, first consider whether it might be useful to others. Open source projects are used by many developers, who may have entirely different needs to your own. Think about whether or not your feature is likely to be used by other users of the project.
Before filing an issue:
Before submitting a pull request:
If the project maintainer has any additional requirements, you will find them listed here.
Add tests! - Your patch won't be accepted if it doesn't have tests.
Document any change in behaviour - Make sure the
README.md and any other relevant documentation are kept up-to-date.
Consider our release cycle - We try to follow SemVer v2.0.0. Randomly breaking public APIs is not an option.
One pull request per feature - If you want to do more than one thing, send multiple pull requests.