diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS index 868b113..c2ea895 100644 --- a/.github/CODEOWNERS +++ b/.github/CODEOWNERS @@ -1,10 +1,8 @@ # Lines starting with '#' are comments. # Each line is a file pattern followed by one or more owners. # https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners#codeowners-syntax - # The Auro team will be the default owners for everything in the repo. * @AlaskaAirlines/generalauroreviewers - # Order is important. The last matching pattern has the most precedence. # If a pull request touches any files in the ./src dir, only these owners # will be requested to review. diff --git a/.github/CODE_OF_CONDUCT.md b/.github/CODE_OF_CONDUCT.md index 2177c3d..2be02b1 100644 --- a/.github/CODE_OF_CONDUCT.md +++ b/.github/CODE_OF_CONDUCT.md @@ -1,44 +1,44 @@ -# Code of Conduct - +# Code of Conduct + ## Our Pledge In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and -our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation. - +our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation. + ## Our Standards Examples of behavior that contributes to creating a positive environment include: -- Using welcoming and inclusive language -- Being respectful of differing viewpoints and experiences -- Gracefully accepting constructive criticism -- Focusing on what is best for the community -- Showing empathy towards other community members +* Using welcoming and inclusive language +* Being respectful of differing viewpoints and experiences +* Gracefully accepting constructive criticism +* Focusing on what is best for the community +* Showing empathy towards other community members Examples of unacceptable behavior by participants include: -- The use of sexualized language or imagery and unwelcome sexual attention or advances -- Trolling, insulting/derogatory comments, and personal or political attacks -- Public or private harassment -- Publishing others' private information, such as a physical or electronic address, without explicit permission -- Other conduct which could reasonably be considered inappropriate in a professional setting - +* The use of sexualized language or imagery and unwelcome sexual attention or advances +* Trolling, insulting/derogatory comments, and personal or political attacks +* Public or private harassment +* Publishing others' private information, such as a physical or electronic address, without explicit permission +* Other conduct which could reasonably be considered inappropriate in a professional setting + ## Our Responsibilities Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. -Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. - +Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. + ## Scope -This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. - +This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. + ## Enforcement -Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at Kevin.Sonnichsen@alaskaair.com. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. - -Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. +Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. +Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. + ## Attribution This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md index 008f5b7..397d3ea 100644 --- a/.github/CONTRIBUTING.md +++ b/.github/CONTRIBUTING.md @@ -1,92 +1,159 @@ # Auro Design System Contributing Guidelines -Please take a moment to review this document in order to make the contribution process easy and effective for everyone involved. +Please take a moment to review this document in order to make the contribution process easy and effective for everyone involved. Also be sure to review the [Issues, pull requests and labels](https://auro.alaskaair.com/contributing/issues-prs-labels) process document. +If you are an Alaska Airlines Employee, Contractor, or Vendor, please see our [Innersourcing Flow Guide on Sharepoint](https://alaskaair.sharepoint.com/sites/ECOMt/Guilds/auro-users-and-contributors). + ## Feature Requests -Feature requests stem from a business need. Also be sure to find out whether your idea fits with the scope and aims of the project of if this serves to address a personal/local scenario. It is up to you to make a strong case to convince the project's managers of the merits of this feature. Please provide as much detail and context as possible. +Feature requests stem from a business need. It is important to understand whether your idea fits within the scope and aims of this project or if this serves to address a personal/local scenario. It is up to you to make a strong case about the merits of this feature. Please provide as much detail and context as possible. + +## Submitting issues -## Reporting Bugs +A bug is defined by: _"A demonstrable problem that is caused by a file in the repository."_ Good bug reports are extremely helpful - thank you! -A bug is defined by: "A demonstrable problem that is caused by a file in the repository." Good bug reports are extremely helpful - thank you! +To submit an issue, please go to [Auro's project status board](https://auro.alaskaair.com/component-status) and click on the ISSUES link to the left of the associated project you wish to submit an issue for, or click on the GITHUB ISSUES icon at the top of every element's page in the Auro doc site. Guidelines for bug reports: -1. Use the search option under Boards > Work Items — check if the issue has already been reported -1. Check if the issue has been fixed — try to reproduce it using the latest main or development branch in the repository +1. BEFORE submitting an issue, make sure that you are **using the latest version** of the component you are working with and/or see if you can reproduce the error in the Auro doc site. +1. Check if the issue has already been reported. Go to any Auro repo's issue page and use Github's search features to see if a similar issue has been submitted. +1. Check if the issue has been fixed — try to reproduce it using the latest main or feature branch in the repository 1. Isolate the problem — ideally create a reduced test case and a live example -A good bug report shouldn't leave others needing to chase you up for more information. Please try to be as detailed as possible in your report. What is your environment? What steps will reproduce the issue? What browser(s) and OS experience the problem? What would you expect to be the outcome? All these details will help people to fix any potential bugs. +Please allow up to 48 hours to receive a response from the Auro team post issue submission. -Poor bug reports will be reassigned back to the creator for revision prior to any additional investigation. +A good bug report shouldn't leave others needing to follow up for more information. Please try to be as detailed as possible in your report. What is your environment? What steps will reproduce the issue? What browser(s) and OS experience the problem? What would you expect to be the outcome? All these details will help people to fix any potential bugs. +Poor bug reports will be closed as the team is unable to reproduce the issue. + +PLEASE be responsive to questions asked via the issue's comments. All attempts to communicate to the author of the issue will be made. If the author is unresponsive, the issue will be labeled as `abandoned` and will be closed upon next review. + +Please remember, submitting an issue is not a work request. The issue itself is a report of the situation, not a solutions statement. + +Please **DO NOT** start any work on a potential pull request until you have consulted with a member of the Auro team per your issue. This brief consultation, facilitated via the issue and its related comments, will help ensure the success of your pull request submission. + ## Submitting pull requests -No one other than repository managers have direct access to the repository. For all pull requests you must first fork the project to your own Github account. +No one other than repository maintainers and trusted committers have `write` access to any repository. For others a pull request must originate from a [forked repo](https://auro.alaskaair.com/contributing/upstream) in your own Github account. If you are interested in `write` access to Auro, please submit a request to the team's leadership. + +All new work that is to be considered for merging with the `main` branch must start from a new feature branch of work. This feature branch should be in response to either a [reported bug](https://auro.alaskaair.com/bugs) or a [requested features](https://auro.alaskaair.com/help-wanted). -All new work that is to be considered for merging with the `MAIN` branch must start from a new feature branch of work. This feature branch should be in response to either a bug or a new business requirement. +Unsolicited pull requests **will take longer** to respond to. We ask for your patience. To help expedite any pull request, we ask that you **submit an issue first**. This will help the team understand the problem you are trying to solve before submitting the solution. +To assist with the pull request review, it is also recommended that you **DO NOT** do any work until you have consulted with maintainer related to the Auro project. This process will be facilitated via the issue and its related comments. Once an issue is submitted, please allow up to 48 hours to receive a response from the Auro team post issue submission. + ### Feature branch naming -The name of the feature branch should be descriptive as to the nature of the work and please include any references to the story or bug work item ID. +The name of the feature branch should be descriptive as to the nature of the work, reference the author, and please include any references to the story or bug work item ID. For example, if John Doe created a branch for issue #80 about cleaning up the npm API. -### Conventional Commits +```shell +jdoe/cleanUpNpmApi/#80 +``` + +## DO NOT git pull on a feature branch -This project utilizes [Conventional Commits](https://www.conventionalcommits.org/) to auto-generate release versions, based on the [Angular Commit Message Guidelines](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines). +We ask that we keep our repo's history linear. This helps maintain a easy to understand version history and is crucial to our semantic versioning strategy. If you find yourself unable to push to the remote, please **DO NOT** use the `$ git pull` command. If this is discovered during a review, **the pull request will be rejected**. Please see the following instructions on rebasing below. + +### Rebase on main + +To maintain repository history health, it is best practice to [rebase branches off of an updated main versus merging down](https://www.atlassian.com/git/tutorials/merging-vs-rebasing). + +If you have push access to the repo ``` -[optional scope]: +$ git checkout main +$ git pull +$ git checkout [feature branch] +$ git rebase main +$ git push origin [feature branch] --force ``` -All commit messages must be prefixed with a specific type so that the semver release configuration can analyze the commit and apply the correct version release. Please see the following types with their respective meanings. +If you are working off a forked branch, please see [Maintaining your fork's upstream relationship](https://auro.alaskaair.com/contributing/upstream) to sync your main branch and then follow the outlined steps. + +## Conventional Commits + +This project utilizes [Conventional Commits](https://www.conventionalcommits.org/) to auto-generate release versions, based on the [Angular Commit Message Guidelines](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines). + +**NOTE:** Before working in your project, be sure to run `$ npm i` to ensure that all packages are installed. + +#### Commit Message Format + +Each commit message consists of a **header**, a **body** and a **footer**. The header has a special format that includes a **type**, a **scope** and a **subject**: + +```html +(): + + + +