Pueblo Contribution Model - mikaelasymanovich/hello-world Wiki

CONTRIBUTING

Every project seeking help from the contributors MUST include this file into their git repository and link this page from README.md. Text in <angular braces> is project/service specific. Maintainers of the project are required to replace this text with content relevant to their project/service. For a concrete example of how this template was used, see the contribution-model-template repo. This repo demonstrates GitHub features such as CODEOWNERS file, PR/Issue Template files and more which will help you team better communicate and enforce your defined contribution model.

1. What is a Pueblo Widget?

<Engineers need to understand the value of contributing their time and effort to this project. Start by providing a concise description of the project and the problem(s) it solves. Next, review the benefits of contributions to Adobe, such as a more agile workforce, increased resiliency of knowledge, and a faster time-to-market. Finally, highlight the benefits to the individual engineer such as learning a new programming language/framework, a greater understanding of use-cases, learnings gained from best-practices and design patterns, working with a great team, and the heightened visibility in the org achieved by contributions.>

2. Why Should You Contribute a Widget?

<Engineers need to understand the value of contributing their time and effort to this project. Start by providing a concise description of the project and the problem(s) it solves. Next, review the benefits of contributions to Adobe, such as a more agile workforce, increased resiliency of knowledge, and a faster time-to-market. Finally, highlight the benefits to the individual engineer such as learning a new programming language/framework, a greater understanding of use-cases, learnings gained from best-practices and design patterns, working with a great team, and the heightened visibility in the org achieved by contributions.>

3. Developer Setup

  1. Join the #pueblo Slack channel.
  2. Setup your local dev by cloning the pueblo repo and forking the quarry repo. Instructions for pueblo are HERE and instructions for quarry are HERE.
  3. Clone following code repos <List of git repos to clone>
  4. Run local build <build scripts to run>
  5. <Anything else specific to your project>

4. List of Related Repositories

https://git.corp.adobe.com/exc/pueblo - Contains the code for the home application which runs at multiple routes (/home, /journey-optimizer/home). Pueblo is built on the quarry dashboard framework. https://git.corp.adobe.com/frontend/quarry - Quarry contains the dashboard framework leveraged in pueblo and the package which new widgets should be contributed to.

5. Coding Guidelines

  • File a JIRA ticket in the <JIRA Project> setting <components>, <domain> and a detailed description of the task with relevant epic links and documentation links. If it is a bug, clearly outline the steps to reproduce it.
  • Follow coding guidelines for the project. <Link to the coding guidelines>
  • Commit changes, including tests, with the "JIRA-ID" in the commit message.
  • Issue a pull request for your changes. Make sure the pull request title matches the "JIRA-ID - Jira issue title."
  • Based on the repository settings, it is likely that code reviewers will be automatically assigned to your PR. You are encouraged to tag any additional repository maintainers via the github @name notification mechanism.
  • For error handling, you SHALL follow the Platform Error Code Standard.
  • When working with REST APIs, you SHALL follow the Platform REST API Guidelines.
  • To onboard your API to Adobe IO, you SHALL following the guidelines outlined here.
  • You SHALL provide up to <specify a number required by your project. A 100 is desirable, but there a room to adjust as per the nature of feature/project>% of unit test coverage for your feature. In addition, you SHALL write integration tests, end-to-end tests and performance tests as deemed necessary by the maintainers of the service.

<Specify any other merge processes followed by this project> https://git.corp.adobe.com/pages/hstack/opendev/contributing_guide.html

6. PR Review Process

<If you have your service/team specific PR Review guidelines, please outline them here. Otherwise please use the guidelines provided in the link below.> https://git.corp.adobe.com/pages/hstack/opendev/code_review_guide.html

7. Test Automation

This project consists of the following test automation. As a contributor, it is your responsibility to add new tests for your feature in the categories as required by the project maintainers. * Explain that they should add e2e tests in cypress in the pueblo repo once they are on home *

8.1. Unit Tests

Each local build and a pull request trigger the execution of unit tests. Every module contains a pairing unit test module. You SHALL add new unit tests or update existing tests to provide code coverage for your change.

8.2. Integration Tests

Integration tests verify that the application modules work correctly when they are connected. This project runs integration tests at a <specific frequency> on the following <integration test environment>

Integration tests are available in the following repositories.

<List repositories and locations of integration tests> You SHALL add new integration tests or update existing tests to provide coverage for your change.

8.3. End-to-End Tests

End-to-End tests verify the successful operation of this service from the end-user perspective, validating workflows by using real-world scenarios. Their purpose is to check on dependencies and to make sure information flows are as expected between components.

This project is tested end-to-end by following tests in the end-to-end test suites.

<List repositories and locations of the end-to-end tests> <Details of how end-to-end tests are run> You SHALL add new end-to-end tests or update existing tests to provide coverage for your change.

8.4. Performance Tests

Performance tests check the system's behavior when subjected to an increased volume of requests up to a defined threshold in a controlled environment.

<Detailed description of your service's performance test framework, and process to run performance tests such as: How to schedule a performance test against a PR Steps to spin-up/scale-up resources Start and end performance tests Links to the dashboards to view results of the performance tests> <Guide to contribute to new performance tests, if applicable for the change>

9. Monitoring

Several dashboards are available to monitor the health of this service. When appropriate, you SHALL add observability-related code to measure the performance of your feature and make necessary changes to the dashboards.

<List all dashboards, and their links to access and how to interpret dashboard data. You could also link to the section in Operational Readiness document containing monitoring related information>

10. Alerting

Describe how alerts are generated and how they are linked to Slack, PagerDuty etc. <Link the alerting section in the Operational Readiness document>

11.1 Infrastructure Telemetry

This service's Infrastructure-as-Code contains instrumentation to ensures runtime collection of logs and events generated by <virtual hosts/containers, OS, foundational software services like databases, application servers, message queues, and other resources>. You SHALL change this code to collect any additional infrastructure-related metrics generated by your change.

11.2 Application Telemetry

You SHALL ensure that your change is properly instrumented to enable application performance monitoring at runtime.

12. Production Support

PR reviews and test automation are expected to catch most of the issues with your change. However, by experience, we know that every new change will bring potential instability to the service. Likely, the on-call engineers may not be fully aware of your change. In case of a production issue or a CSO, contributors agree to support the on-call engineers when the problem is likely related to their change. <teams may specify for how long the on-call support is expected>

13. Documentation

13.1. Design Docs

<List all design docs of this project> If your change is bringing any design change, you SHALL update the relevant design document.

13.2. API Docs

<List all current API docs of this project, and describe how they are auto-generated; if not, what is the process to update the docs> If your change is creating new APIs or updating existing APIs, you SHALL ensure that the API documentation is updated accordingly.

14. Support For the Contributors

This section describes how to seek help from the existing contributors and maintainers of the service. <List all the avenues for contributors to seek help. For example, a dedicated slack channel, office hours, etc.>

15. Contribute to Improve CONTRIBUTING.md

This is a live document. Suggestions, improvements to the guidelines, processes outlined here are always welcome! Please issue a pull requests to make changes to this document.

⚠️ **GitHub.com Fallback** ⚠️