Creating a high-level pattern library like this one comes with risks. The most significant one is premature abstraction. Our general approach here is that API design happens best in the context of real-world applications. Features should be proposed for this library once they have reached a certain level of stability.
We don't want to have an excessively prescriptive sense of what is 'in' and 'out' of scope for this library. So long as something fits within our architecture, is testable and has an API that has stabilised through real-world use, it's a candidate for inclusion.
New features and functionality
- The first stage of adding a new module happens within an application that uses it. Use the convention of placing it in the
groundwork.experimentalpackage within your application repository to indicate to other people that it's in the process of being abstracted and that they should be mindful of these guidelines.
- Remove any dependencies from application code outside the
groundworkpackage. Start to think about how it can be tested in isolation (if it isn't already).
- Open a feature request against this repository. Describe the new feature, include links to your implementation other repositories. If the application is publicly accessible, include links to it in the live app.
- Discuss and refine the API with other contributors.
Bugs & backward-compatible API changes
We're more open to backward-compatible API changes. For smaller changes, opening a pull request is fine.
Some additional pointers:
- These changes are always a good opportuntiy to improve test coverage of the exsting functionality. Think about how your changes may lead to regressions to the existing functionality and add tests to guard against them.
Improvements to documentation
Releases are published to package managers when a release tag in
vX.X.X format is published in GitHub.
We follow the Semantic Versioning spec for release numbers.