-
Notifications
You must be signed in to change notification settings - Fork 3
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
contributing: Intitial commit, based on Pantheon 2 repo contribution …
…guidelines.
- Loading branch information
Showing
1 changed file
with
20 additions
and
42 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,29 +1,13 @@ | ||
| # publishing-tutorial-sample-repo | ||
| # Publishing tutorial sample repo | ||
| A sample repo to be used in conjunction with the tutorial "Getting started publishing with Pantheon 2" | ||
|
|
||
| [](https://travis-ci.org/redhataccess/pantheon) | ||
| [](https://codecov.io/github/redhataccess/pantheon?branch=master) | ||
| * [Contributing to this repository](#contributing-to-this-repository) | ||
|
|
||
| Pantheon 2 is a modular documentation management and publication system based on asciidoc | ||
| and built on top of Apache sling. | ||
| * [Contributing to Pantheon](#contributing-to-pantheon) | ||
| * [Installing Pantheon](#installing-pantheon) | ||
| * [Prerequisites](#prerequisites) | ||
| * [Environment Variables](#environment-variables) | ||
| * [Building the application](#building-the-application) | ||
| * [Unit tests](#unit-tests) | ||
| * [Running the application](#running-the-application) | ||
| * [Live deploy of code](#live-deploy-of-code) | ||
| * [Using the application](#using-the-application) | ||
| * [Other use cases](#other-use-cases) | ||
| * [Developing the frontend code](#developing-the-frontend-code) | ||
| * [End user documentation](#end-user-documentation) | ||
| ## Contributing to this repository | ||
|
|
||
| ## Contributing to Pantheon | ||
| ### Filing a bug | ||
|
|
||
| ### Filing a bug for Pantheon 2 end-user documentation | ||
|
|
||
| If you have any suggestions to improve or extend the end-user documentation, create a new issue and tag @pantheon-doc-authors. | ||
| If you have any suggestions to improve or extend this repository, add a new issue in the repository. | ||
|
|
||
| ### Prerequisites | ||
|
|
||
|
|
@@ -38,45 +22,44 @@ If you have any suggestions to improve or extend the end-user documentation, cre | |
|
|
||
| Fork the repository so that you can create and work with branches independently of the `redhataccess/pantheon` repository. | ||
|
|
||
| 1. In a web browser, navigate to https://github.com/redhataccess/pantheon | ||
| 1. In a web browser, navigate to https://github.com/redhat-documentation/publishing-tutorial-sample-repo | ||
| 1. Click **Fork**. | ||
| 1. Click your user space in GitHub. | ||
|
|
||
| ### Cloning the repository | ||
|
|
||
| After you have forked the repository, you must clone it to your local machine and add the original `redhataccess/pantheon` repository as an upstream remote. | ||
| After you have forked the repository, you must clone it to your local machine and add the original `redhat-documentation/publishing-tutorial-sample-repo` repository as an upstream remote. | ||
|
|
||
| 1. From a terminal, clone the repository: | ||
|
|
||
| ```sh | ||
| $ git clone [email protected]:<user-space>/pantheon.git | ||
| $ git clone [email protected]:<user-space>/publishing-tutorial-sample-repo.git | ||
| ``` | ||
| 1. Set up `redhataccess/pantheon` as the upstream: | ||
| 1. Set up `redhat-documentation/publishing-tutorial-sample-repo` as the upstream: | ||
|
|
||
| ```sh | ||
| $ cd pantheon | ||
| $ git remote add upstream [email protected]:redhataccess/pantheon.git | ||
| $ cd publishing-tutorial-sample-repo | ||
| $ git remote add upstream [email protected]:redhat-documentation/publishing-tutorial-sample-repo.git | ||
| ``` | ||
|
|
||
| ### Creating a working branch | ||
|
|
||
| Whenever you work on a new issue, you must create a new working branch based on the latest version of the upstream master branch. | ||
| Pull requests should have a corresponing issue in the repo. Whenever you work on a new issue, you must create a new working branch based on the latest version of the upstream main branch. | ||
|
|
||
| 1. Ensure you are on master | ||
| 1. Ensure you are on main | ||
|
|
||
| ```sh | ||
| $ git checkout master | ||
| $ git checkout main | ||
| ``` | ||
| 1. Ensure your fork is up to date | ||
|
|
||
| ```sh | ||
| $ git pull upstream master | ||
| $ git pull upstream main | ||
| ``` | ||
| 1. Create a working branch based on the issue in JIRA. For example: | ||
|
|
||
| 1. Create a working branch based on the issue ID. For example for issue #2, you can use "2" or "02" for the branch name: | ||
|
|
||
| ```sh | ||
| $ git checkout -b FCCEUD-<ID#> | ||
| $ git checkout -b 02 | ||
| ``` | ||
|
|
||
| ### Creating a pull request and completing review | ||
|
|
@@ -90,11 +73,10 @@ When your work is ready to be reviewed and merged, create a pull request. | |
| ``` | ||
| 1. From the repository page in GitHub, click **New pull request**. | ||
| 1. Select your working branch from the compare list. | ||
| 1. Add `WIP:` to the title of the pull request. This automatically converts the pull request to a draft pull request. | ||
| 1. Add `WIP:` to the title of the pull request. This automatically converts the pull request to a draft pull request, preventing it from being merged. | ||
| 1. Click **Create new pull request**. | ||
| 1. Add the **awaiting tech review** label to the pull request. | ||
| 1. In the pull request comment field, enter `@redhataccess/eud-tech-review Please review for technical completeness and accuracy`. | ||
|
|
||
| 1. In the pull request comment field, enter `@redhat-documentation/publishing-tutorial-team Please review for technical completeness and accuracy`. | ||
|
|
||
| ### The review process | ||
|
|
||
|
|
@@ -106,15 +88,11 @@ After creating and labeling a pull request as outlined above, the developers rev | |
| When technical review is complete, writers click the **Reviewers** gear icon and select the name of a team member to request peer review. The peer writer reviews the pull request for clarity, consistency, and compliance with necessary standards. | ||
| Writers receive a notification that comments have been added via email, and when all comments have been addressed, the reviewer clicks **Review changes > Approve** from the **Files changed** tab of the pull request to approve the changes and the pull request. | ||
|
|
||
| #### Code review | ||
|
|
||
| For code pull requests, one or more developers review the pull request. A contributor submits a PR and uses Github's **Reviewers** gear icon to tag `@redhataccess/pantheon-developers`. A developer comments on the code, and discusses it with the submitter, before ultimately deciding to accept or reject the PR. | ||
| ### Merging a pull request | ||
|
|
||
| When you have addressed all technical review and peer review comments, notify the developers to accept the pull request. | ||
|
|
||
| 1. Remove `WIP` from the title of the pull request. | ||
| 1. Click **Request Review** and enter `@redhataccess/pantheon-developers`. | ||
| 1. Click **Request Review** and enter `@@redhat-documentation/publishing-tutorial-team`. | ||
|
|
||
| The developers check that the **Tech review complete** label has been added to the pull request and peer pull request approval provided, then accept it. | ||