Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revise pull request template #18744

Merged
merged 2 commits into from
Feb 4, 2020
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
37 changes: 20 additions & 17 deletions .github/PULL_REQUEST_TEMPLATE.md
Original file line number Diff line number Diff line change
@@ -1,17 +1,20 @@
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Remember to delete this note before submitting your pull request.
>
> For pull requests on 1.18 Features: set Milestone to 1.18 and Base Branch to dev-1.18
>
> For pull requests on Chinese localization, set Base Branch to release-1.16
> Feel free to ask questions in #kubernetes-docs-zh
>
> For pull requests on Korean Localization: set Base Branch to dev-1.16-ko.\<latest team milestone>
>
> If you need Help on editing and submitting pull requests, visit:
> https://kubernetes.io/docs/contribute/start/#improve-existing-content.
>
> If you need Help on choosing which branch to use, visit:
> https://kubernetes.io/docs/contribute/start#choose-which-git-branch-to-use.
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
<!-- 🛈

Hello!

Remember to ADD A DESCRIPTION and delete this note before submitting
your pull request. The description should explain what will change,
and why.

For overall help on editing and submitting pull requests, visit:
https://kubernetes.io/docs/contribute/start/#improve-existing-content

Use the default base branch, “master”, if you're documenting existing
features in the English localization.

If you're working on a different localization (not English), or you
are documenting a feature that will be part of a future release, see
https://kubernetes.io/docs/contribute/start#choose-which-git-branch-to-use
for advice.

-->
33 changes: 28 additions & 5 deletions content/en/docs/contribute/start.md
Original file line number Diff line number Diff line change
Expand Up @@ -196,15 +196,38 @@ to base your work on. Use these guidelines to make the decision:

- Use `master` for fixing problems in content that is already published, or
making improvements to content that already exists.
- Use a release branch (such as `dev-{{< release-branch >}}` for the {{< release-branch >}} release) to document upcoming features
or changes for an upcoming release that is not yet published.
- Use a feature branch that has been agreed upon by SIG Docs to collaborate on
big improvements or changes to the existing documentation, including content
reorganization or changes to the look and feel of the website.
- Use `master` to document something that is already part of the current
Kubernetes release, but isn't yet documented. You should write this content
in English first, and then localization teams will pick that change up as a
localization task.
- If you're working on a localization, you should follow the convention for
that particular localization. To find this out, you can look at other
pull requests (tip: search for `is:pr is:merged label:language/xx`)
{{< comment >}}Localization note: when localizing that tip, replace `xx`
with the actual ISO3166 two-letter code for your target locale.{{< /comment >}}
- Some localization teams work with PRs that target `master`
- Some localization teams work with a series of long-lived branches, and
periodically merge these to `master`. This kind of branch has a name like
dev-\<version>-\<language code>.\<team milestone>; for example:
`dev-{{< release-branch >}}-ja.1`.
- If you're writing or updating documentation for a feature change release,
then you need to know the major and minor version of Kubernetes that
the change will first appear in.
- For example, if the feature gate JustAnExample is going to move from alpha
to beta in the next minor version, you need to know what the next minor
version number is.
- Find the release branch named for that version. For example, features that
changed in the v{{< release-branch >}} release got documented in the branch
named `dev-{{< release-branch >}}`.

If you're still not sure which branch to choose, ask in `#sig-docs` on Slack or
attend a weekly SIG Docs meeting to get clarity.

{{< note >}}
If you already submitted your pull request and you know that the Base Branch
was wrong, you (and only you, the submitter) can change it.
{{< /note >}}

### Submit a pull request

Follow these steps to submit a pull request to improve the Kubernetes
Expand Down