In general, the same [guidelines](https://devdocs.magento.com/guides/v2.3/contributor-guide/maintainers.html) for [`magento/magento2`](https://github.com/magento/magento2) maintainers apply to devdocs maintainers. However, there are some additional guidelines specific to devdocs that will help you as a maintainer.

- Self assign issues/pull requests (mostly pull requests)

- Review and approve or request changes

- Enforce the use of the issue/pull requests template

- Ask contributors to link to the code base to validate documentation updates when applicable

- Ask contributors not to contribute to v2.0 docs

- If a maintainer creates a pull request, it should be reviewed by another maintainer or DevDocs staff member

Labels are important because they help us identify pull requests and ensure that contributors receive points and recognition. See [devdocs awards and points](https://devdocs.magento.com/guides/v2.3/contributor-guide/contributing.html#devdocs-awards-and-points).

Here is a brief summary of the most important labels:

- `New Topic`: Entirely new documents

- `Major Update`: Significant new info: new section in existing topic, etc.

- `Technical`: Changes to technical content/code/processes/naming conventions (any change to technical content)

- `Editorial`: Typos, grammatical inconsistencies, or minor rewrites

- `small changes`: See [Small changes workflow](#small-changes-workflow)

We also use version labels when appropriate.

As a maintainer, we expect you to add or remove labels when appropriate.

See https://github.com/magento/devdocs/labels for all labels and their descriptions.

Currently, we only test internal links. In the future, we plan to expand tests to include external links, markdown linting, and spell checking.

We use private CI/CD stack and do not provide access to it.

Every pull request to the `master` branch must pass tests before it can be merged. When a pull request is ready for tests, a member of the [`devdocs-admins`](https://github.com/orgs/magento/teams/devdocs-admins) team must add the test trigger phrase to the pull request as a comment. The trigger phrase is "_running tests_". By approving a pull request, you are signalling an admin that the pull request is ready for tests.

We use several projects to help organize issues and pull requests. You can add existing issues and pull requests to these projects as you see fit.

We prefer Markdown over HTML (in most cases). You can use [kramdown](https://kramdown.gettalong.org/syntax.html) syntax for more markup features and [Liquid](https://jekyllrb.com/docs/liquid/) for in-topic scripting.

Before merging a pull request to the `master` branch, it must pass automated testing. Testing takes about 30 minutes to complete for each pull request, so we created a workflow to save time for small changes.

- **Individual pull requests to `master`**—15 individual pull requests to `master` x 30 minutes per pull request = 7.5 hrs of testing time

- **Multiple pull requests using `small_changes`**—1 `small_changes` pull request (containing 15 individual pull requests) to `master` x 30 minutes = 30 minutes of testing time

This workflow is for typos, formatting issues, and minor text additions or deletions. It is not for substantial new content, changes to tables, new files, or files that have been moved.

Periodically, we will create a pull request from `small_changes` to `master` and then run tests on that pull request to save time.

1. Review the pull request and either approve it or request changes.

1. Apply the `Small changes` label if one of the following labels should also be applied:

- `Editorial`

- `Technical`

1. That's it! A devdocs-admin will run tests and merge.

updated: Mon May 20 13:19:25 2019

- description: Added [reference documentation](https://devdocs.magento.com/guides/v2.3/extension-dev-guide/routing.html#result-object)

about the `result object` returned by the `Action` class.

versions: 2.1.x, 2.2.x, 2.3.x

type: Major update

date: May 20, 2019

link: https://github.com/magento/devdocs/pull/4541

- description: Added information about adding a custom carrier to the [Customize Checkout

tutorial](https://devdocs.magento.com/guides/v2.3/howdoi/checkout/checkout-add-custom-carrier.html).

versions: 2.1.x, 2.2.x, 2.3.x

type: New topic

date: May 20, 2019

link: https://github.com/magento/devdocs/pull/4371

- description: Added examples of [creating and updating a Magento admin user](https://devdocs.magento.com/guides/v2.3/install-gde/install/cli/install-cli-subcommands-admin.html)

with the command line.

versions: 2.1.x, 2.2.x, 2.3.x

type: Major update

date: May 17, 2019

link: https://github.com/magento/devdocs/pull/4526

- description: Added reference documentation for [ZIP code attributes](https://devdocs.magento.com/guides/v2.3/howdoi/checkout/checkout_zip.html),

including a new code sample showing how to pass multiple ZIP code patterns for

the same country.

versions: 2.1.x, 2.3.x, 2.x

type: Major update

date: May 17, 2019

link: https://github.com/magento/devdocs/pull/4530

- description: Added 'webapi.xsd XML schema file' section to [Configure services as

web APIs](https://devdocs.magento.com/guides/v2.3/extension-dev-guide/service-contracts/service-to-web-service.html#validate-webapi).

versions: 2.1.x, 2.2.x, 2.3.x

type: Technical changes

date: May 15, 2019

link: https://github.com/magento/devdocs/pull/4521

- description: Added "Reverting data patches" section to [Develop data and schema

patches](https://devdocs.magento.com/guides/v2.3/extension-dev-guide/declarative-schema/data-patches.html).

versions: 2.3.x

type: Major update

date: May 13, 2019

link: https://github.com/magento/devdocs/pull/4504

to do translations.

and a new code example that shows how to use them.

[Compatibility](https://devdocs.magento.com/release/).

in the technical guidelines.

showing how to initialize and pass options to the drop-down dialog widget.

topic that describes Magento release policy, product availability, and extension

In general, the same [guidelines](https://devdocs.magento.com/guides/v2.3/contributor-guide/maintainers.html) for [`magento/magento2`](https://github.com/magento/magento2) maintainers apply to DevDocs maintainers. However, there are some [additional guidelines](https://github.com/magento/devdocs/blob/master/.github/MAINTAINER_GUIDELINES.md) that apply to DevDocs.

{: .bs-callout .bs-callout-info }

Action class should return a `result object`.

Name | Description

--- | ---

`json` | Sets `Content-Type:application/json` in the header and returns a json encoded representation of an array with data

`raw` | Returns the data as it's been set. Does not set a `Content-Type` in the header

`redirect` | Creates an external redirect, which the browser follows and requests a new url

`forward` | Internally calls the execute method of another action class and does not trigger a new request from the browser. The URL stays the same

`layout` | View result. You can use a generic layout response to render any kind of layout. The layout comprises a response body from its layout elements and sets it to the HTTP response

`page` | View result. Encapsulates page type, page configuration, and imposes certain layout handles. `page` triggers `layout.xml` to render into HTML