Fix: broken links and typos (#4117)

Signed-off-by: Sachin Sahu <sachinksahu.431@gmail.com>
opensearch-project · Oct 11, 2023 · c469fb1 · c469fb1
1 parent b8a4bfc
commit c469fb1
Show file tree

Hide file tree

Showing 7 changed files with 64 additions and 163 deletions.
diff --git a/MAINTAINERS.md b/MAINTAINERS.md
@@ -8,17 +8,6 @@
     - [General Guidelines](#general-guidelines)
   - [Correcting Mistakes](#correcting-mistakes)
   - [Retrospectives](#retrospectives)
-- [ZenHub Process Workflow](#zenhub-process-workflow)
-  - [What is ZenHub?](#what-is-zenhub)
-  - [Setting up ZenHub](#setting-up-zenhub)
-  - [Sprint Board](#sprint-board)
-    - [Pipelines](#pipelines)
-  - [Creating Issues](#creating-issues)
-  - [Managing issues/stories](#managing-issuesstories)
-    - [Spillovers](#spillovers)
-  - [Epics](#epics)
-  - [Recurring Team Meetings](#recurring-team-meetings)
-  - [On-Call](#on-call)
 
 ## Overview
 
@@ -83,91 +72,3 @@ The release process will be improved and invested in, running a retrospective an
 Feedback comes from the retro issue created during the release and component level retrospectives.  A meeting could be run to capture additional feedback if desired.  This process is focused on recording what happened to make remedies.
 
 After the retro items are in, a final summary is written as a comment on the retrospective issue.  The comment includes areas of consideration for the project alongside action items with owners to drive them, [example](https://github.com/opensearch-project/opensearch-build/issues/880) summary.
-
-## ZenHub Process Workflow
-
-We follow agile methodologies for our development and release process. We use GitHub issues with annotations via ZenHub to manage and track our stories and issues to effectively manage them over the sprint.
-
-### What is [ZenHub](https://www.zenhub.com/)?
-
-ZenHub is an agile project management and product roadmaps solution, natively integrated into GitHub. It is free to use for opensource repository and comes with a paid membership to manage private repositories. 
-We currently use ZenHub only with our public and opensource repositories.
-
-### Setting up ZenHub
-
-ZenHub can be easily added as an [extension]((https://www.zenhub.com/extension)) to chrome and firefox which can be downloaded for free from the ZenHub website. 
-Alternatively, we can use a the ZenHub [webapp link](https://app.zenhub.com/workspaces/engineering-effectiveness-614cf4272a385f0015d2b48f/board?repos=357723952,406037663) to view the board.
-
-### Sprint Board
-
-Once the ZenHub extension is installed, ZenHub board can be accessed using the ZenHub tab on GitHub.
-
-![img.png](zenhub_tab_image.png)
-
-If you are using the webapp - here is the [link](https://app.zenhub.com/workspaces/engineering-effectiveness-614cf4272a385f0015d2b48f/board?repos=357723952,406037663)
-
-#### Pipelines
-
-1. **New Issues -** Issues to be reviewed and estimated before being added to the Product Backlog.
-2. **Icebox -** Low priority Issues that do not need to be addressed in the near future**.**
-3. **Product Backlog -** Upcoming Issues that have been reviewed, estimated, and prioritized top-to-bottom.
-4. **Sprint Backlog -** Issues ready to be worked on in the sprint, prioritized top-to-bottom.
-5. **In Progress -** Issues currently being worked on by the team.
-6. **Review/QA -** Issues open to the team for review and testing. Code complete, pending feedback.
-7. **Done -** Issues tested and ready to be deployed to production. Verify the acceptance criteria and close the issue.
-8. **Closed -** Issues that are deployed to production and closed
-
-Description for each pipeline can also be found on the sprint board by clicking on the 3 dots next to the pipleine name.
-
-### Creating Issues
-
-Follow the steps below to create issues on ZenHub workflow -
-
-1. Create the issue for the desired repository following the required guidelines for mandatory and optional fields on GitHub.
-2. Add an acceptance criteria for the issue
-3. Add relevant tags to the issue. This would help us to track and filter issues.
-4. Select the correct pipeline for the issue (defaults to New Issues )
-5. Mark the issue for a sprint (if known)
-
-### Managing issues/stories
-
-1. Everyone working on a task should ensure the following -
-    1. Have an issue associated with it to record the work
-    2. The issue should be assigned
-    3. The issue should have an estimate set
-    4. The issue should have the correct pipeline
-2. Pull requests raised should be assigned and linked to their issues. There should not be a PR without an issue.
-3. If you are working on an issue that belongs to a private repository, create an issue in the opensearch-build repository with only public details to track your work.
-
-#### Spillovers
-
-Spillover issues that were a part of the sprint but were not completed are a good indicator for improvement areas.
-
-These issues will automatically be moved to the next sprint. There are 3 possible cases in this scenario :
-
-1. **Issue is still in sprint backlog -** This is an indication that we need to look again at our sprint planning to help plan better for the sprint. 
-2. **Issue is in progress -** This means that we need to create smaller issues such that these can be completed in a sprint. 
-3. **Issue is in Review -** These issues should be closed at a priority in the upcoming sprint.
-
-### Epics
-
-An epic is *a large body of work that can be broken down into a number of smaller stories*, or sometimes called “[META] Issues”. Epics often encompass multiple teams, on multiple projects, and can even be tracked on multiple boards. Epics are almost always delivered over a set of sprints.
-
-ZenHub provides an elegant way to incorporate epics reducing a lot of manual work compared to meta issues and easy viewing. Click [here](https://help.zenhub.com/support/solutions/articles/43000010341-an-intro-to-zenhub-epics) for more details.
-
-### Recurring Team Meetings
-
-- **Standup -** Daily standups can easily be managed using the sprint board. The moderator should select the filter for the current sprint and change filter for assignees as we move forward with the standup. 
-This would ensure that all the tasks the an individual is working on is correctly represented on the sprint board.<br>
-
-  Everyone should spend approximately 1 minute to discuss the work without interruption, answering questions like - What did I do yesterday? What is the plan for today? What help I might need from others? After everyone turns, we can discuss go-backs if any. The Moderator keeps track of the time.
-
-- **Grooming -** All team members come together to add items to the Product Backlog.  These issues/stories should have been reviewed, estimated, and prioritized top-to-bottom.
-
-- **Planning -** We go over the product backlog to see what all do we need to complete for the current sprint.
-
-- **Retrospective -** This meeting is held at the end of a sprint used to discuss what went well during the previous sprint cycle and what can be improved for the next sprint.
-
-### On-Call
-
-Since on-call is a weekly rotation, we do not create an issue for on-call. However, if on-call requires you to work on a bug, please make sure that we have issue associated with the task for tracking.
diff --git a/ONBOARDING.md b/ONBOARDING.md
@@ -19,7 +19,7 @@ Add the new plugin to the [opensearch-plugins meta](https://github.com/opensearc
 
 ### Onboard to Build Workflow
 
-1. Update a [manifest](/manifests) for a particular release to include your plugin.  For example to be included in the 1.1.0 release, you would update [opensearch-1.1.0.yml](/manifests/1.1.0/opensearch-1.1.0.yml). We require your plugin name, repository url, and git ref that should be used. For unreleased versions this should be a branch in your repository.  Once a release is cut, these refs will be updated to build from a tag or specific commit hash.
+1. Update a [manifest](/manifests) for a particular release to include your plugin.  For example to be included in the 1.1.0 release, you would update [opensearch-1.1.0.yml](https://github.com/opensearch-project/opensearch-build/blob/opensearch-1.1.0/manifests/1.1.0/opensearch-1.1.0.yml). We require your plugin name, repository URL, and git ref that should be used. For unreleased versions this should be a branch in your repository.  Once a release is cut, these refs will be updated to build from a tag or specific commit hash.
 
 2. Create a `scripts/build.sh` if you have specific requirements that are not covered by the [default build.sh script](/scripts/default/opensearch/build.sh) and commit it to your repository.
 
@@ -33,15 +33,15 @@ Add the new plugin to the [opensearch-plugins meta](https://github.com/opensearc
 
 ### Onboard to `test-workflow`
 
-1. Update the test configuration file (use 1.3.0 as an example), [opensearch-1.3.0-test.yml](manifests/1.3.0/opensearch-1.3.0-test.yml), for a particular release, to include your plugin. This test configuration defines full suite of tests - `integ`, `bwc`, that can be run on the plugin.
+1. Update the test configuration file (use 1.3.0 as an example), [opensearch-1.3.0-test.yml](https://github.com/opensearch-project/opensearch-build/blob/opensearch-1.3.0/manifests/1.3.0/opensearch-1.3.0-test.yml), for a particular release, to include your plugin. This test configuration defines full suite of tests - `integ`, `bwc`, that can be run on the plugin.
 
-2. For integration testing, the `test-workflow` runs integration tests available in the plugin repository. You will need to add `integ-test` config for your plugin in opensearch-1.3.0-test.yml, [example](manifests/1.3.0/opensearch-dashboards-1.3.0-test.yml).
+2. For integration testing, the `test-workflow` runs integration tests available in the plugin repository. You will need to add `integ-test` config for your plugin in opensearch-1.3.0-test.yml, [example](https://github.com/opensearch-project/opensearch-build/blob/opensearch-1.3.0/manifests/1.3.0/opensearch-1.3.0-test.yml).
 
     1. It supports two test configs - `with-security` and `without-security`, which runs test with security plugin enabled and disabled respectively. Choose one or both depending on what your plugin integration tests support.
 
     2. If your plugin is dependent on `job-scheduler` zip, you can define that in `build-dependencies` in the config. Currently, the test workflow only supports `job-scheduler` as build dependency. Please create an issue if your plugin needs more support.
 
-3. For backward compatibility testing, the `test-workflow` runs backward compatibility tests available in the plugin repository, (see [reference]((https://github.com/opensearch-project/anomaly-detection/blob/d9a122d05282f7efc1e24c61d64f18dec0fd47af/build.gradle#L428))). Like integration test, it has a set of configurable options defined in opensearch-1.3.0-test.yml, [example](manifests/1.3.0/opensearch-1.3.0-test.yml).
+3. For backward compatibility testing, the `test-workflow` runs backward compatibility tests available in the plugin repository, (see [reference](https://github.com/opensearch-project/anomaly-detection/blob/d9a122d05282f7efc1e24c61d64f18dec0fd47af/build.gradle#L428)). Like integration test, it has a set of configurable options defined in opensearch-1.3.0-test.yml, [example](https://github.com/opensearch-project/opensearch-build/blob/opensearch-1.3.0/manifests/1.3.0/opensearch-1.3.0-test.yml).
 
     1. It supports two test configs - `with-security` and `without-security`, which runs test with security plugin enabled and disabled respectively. Choose one or both depending on what your plugin integration tests support.
 
@@ -57,14 +57,14 @@ See https://github.com/opensearch-project/opensearch-build/issues/1234 for detai
 1. Create a Jenkins workflow that utilizes one of the [build libraries](https://github.com/opensearch-project/opensearch-build-libraries#library-details) to publish the artifacts to right platform. Please check the [library requirements and retrieval methods](https://github.com/opensearch-project/opensearch-build-libraries#jenkins-shared-libraries) before using it.
 1. For publishing to a new platform (other than ones specified above) a new library needs to be added. (ETA: 2 weeks)
 1. **Release Drafter**: Release drafter is a GitHub Action workflow that drafts a release that may or may not contain the release artifacts. The drafted release acts as a trigger to the Jenkins workflow. It also acts as a staging environment for release artifacts. This is to make sure the build environment remains the same even for release artifacts. [Example](https://github.com/opensearch-project/opensearch-py/blob/main/.github/workflows/release-drafter.yml)
-    * _**2 Person Review**_ It is highly recommended to add 2PR approval for any release workflow. In universal release process this can be added to release-drafter workflow as that is the starting point to trigger any release. See how to [add the mechanism in the workflow](https://github.com/opensearch-project/opensearch-dsl-py/pull/102). The mentioned solution creates an issues that notifies and assignes the reviewers. [Example](https://github.com/gaiksaya/opensearch-dsl-py/issues/6)_
+    * _**2 Person Review**_ It is highly recommended to add 2 PR approval for any release workflow. In universal release process this can be added to release-drafter workflow as that is the starting point to trigger any release. See how to [add the mechanism in the workflow](https://github.com/opensearch-project/opensearch-dsl-py/pull/102). The mentioned solution creates an issue that notifies and assigns the reviewers. [Example](https://github.com/gaiksaya/opensearch-dsl-py/issues/6).
 1. **Jenkins Workflow:** Once the Jenkins workflow is added to the repository, onboard the workflow to publicly available [CI system](https://build.ci.opensearch.org/)
     1. Create a `New Item`
     2. Name it `<component-name>-release`
     3. Select `Pipeline` as type of the project
     4. Hit `Ok` and scroll to the bottom of the page
     5. Select "Pipeline script from SCM" under Pipeline section
-       - _SCM_: Github repository link. eg: https://github.com/opensearch-project/opensearch-build
+       - _SCM_: GitHub repository link. eg: https://github.com/opensearch-project/opensearch-build
        - _Script_ Path: Relative path to jenkins file. eg: jenkins/check-for-build.jenkinsfile
     6. Run the workflow once in order to update the configuration of the Jenkins Workflow. You can abort once the workflow starts pulling the docker image. 
 1. **GitHub Webhook**: Add webhook to your GitHub repository by going to repository settings → Click `Webhooks`:
@@ -75,7 +75,7 @@ See https://github.com/opensearch-project/opensearch-build/issues/1234 for detai
     | SSL verification                                    | Enable                                                                                    |
     | Which events would you like to trigger this webhook | Releases. Please ensure to deselect the default option "Pushes"                           |
     | Active                                              | Enable                                                                                    |
-1. Once a webhook is added, it will send a ping to check the connectivity (✅). You can check the ping by going to repistory settings → Webhooks → Click on `Recent Deliveries` tabs
+1. Once a webhook is added, it will send a ping to check the connectivity (✅). You can check the ping by going to repository settings → Webhooks → Click on `Recent Deliveries` tabs
 1. Add `RELEASING.md` file to the repository documenting how to release the artifact. [Example](https://github.com/opensearch-project/opensearch-py-ml/blob/main/RELEASING.md)
 1. **Adding tests:** Each library has a respective library tester associated with it that can be used to test you jenkins workflow. This tests can be used to verify that the workflow is making the calls. The build system used is gradle. 
 For example, this [PublishToNpm test](https://github.com/opensearch-project/opensearch-build-libraries/blob/main/tests/jenkins/TestPublishToNpm.groovy) uses [PublishToNpmLibTester](https://github.com/opensearch-project/opensearch-build-libraries/blob/main/tests/jenkins/lib-testers/PublishToNpmLibTester.groovy) with expected parameter that can be unique to your workflow. The assertions makes sure that calls to npm registry is made which is mandatory to release an artifact.