Web Apps SDK for Adobe Business Catalyst allows web developers to create custom client-side applications that leverage the Business Catalyst system APIs. Used inside any Adobe Business Catalyst site, these applications can enhance the standard functionality and experience of the site.
The project includes the SDK itself, some sample applications and the reference guides. We welcome your contributions in any of these components.
There are several ways you can help the Web Apps SDK project, choose the one that best suites you:
- Fix a bug or implement a new feature
- Create an sample app based on Web Apps SDK
- Write or update documentation
- Test the Web Apps SDK or any of the sample apps and report the bugs you find
- Write unit tests
- Write integration tests
Here are some ressources you might want to check out before writing out code:
Once you’re ready, move on to the Contributing Code section, to learn more about how you can contribute code or docs.
To get started editing the Web Apps SDK code, read about developing for Web Apps SDK.
Before submitting any pull request, please make sure to:
- Discuss any major changes or questions beforehand in the Adobe Business Catalyst developer forum
- Sign the Web Apps SDK Contributor License Agreement (we cannot merge before this).
- Fork the current repository using your github account (https://help.github.com/articles/fork-a-repo)
- Document code
- Check the code passes unit test
- Write unit tests for your contribution (either new functionality or bug fixing)
- Write integration tests for any new functionality
- Create a pull request once you are confident code works as expected (https://help.github.com/articles/using-pull-requests).
High quality code and consistent look and feel for sample applications are important to us and therefore we carefully review every pull request. The better you follow the guidelines above, the more likely we are to accept your pull request - and the faster the code review will go.
Web Apps SDK approvers have write access to the source three. They are responsible for reviewing contributions, providing feedback, merging code into the master and mediating disputes. Approvers are responsible for making sure that contributions do not break the build.
Once you've opened a pull request, an approver will generally respond to it within a week with an initial set of comments (you don't need to ping anyone to find a reviewer). Some pull requests could raise larger questions about architecture, design or project scope.
The best way to avoid this sort of holdup is to discuss your changes on the newsgroup first! Once your pull request is approved and merged, it will appear in the next release, generally within a month.
All participants in the community are encouraged to provide support for new users within the project management infrastructure. This support is provided as a way of growing the community. Those seeking support should recognize that all support activity within the project is voluntary and is therefore provided as and when time allows.