From 99f1bb83e1674c9d9730951aac0ecd2215edde99 Mon Sep 17 00:00:00 2001 From: Daniel Gustafsson Date: Tue, 19 Feb 2019 09:56:56 +0100 Subject: [PATCH] Mention draft PRs in readme and fix PR documentation We do welcome draft PRs, especially now that Github has enabled it as a feature when creating PRs. Add a note on this in the main README and also fix the text regarding which branch to PR against, as we now have a supported back-branch. Also fix a long line in the same section to make reading of the source markdown easier. Reviewed-by: Adam Berlin Reviewed-by: Georgios Kokolatos --- README.md | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index c56791f4f0..4d6beba449 100644 --- a/README.md +++ b/README.md @@ -352,12 +352,18 @@ Feel free to ask on the mailing list to learn more about the Greenplum release p Once you are ready to share your work with the Greenplum core team and the rest of the Greenplum community, you should push all the commits to a branch in your own -repository forked from the official Greenplum and [send us a pull request](https://help.github.com/articles/about-pull-requests/). - -For now, we require all pull requests to be submitted against the main master -branch, but over time, once there are many supported open source releases of Greenplum -in the wild, you may decide to submit your pull requests against an active -release branch if the change is only applicable to a given release. +repository forked from the official Greenplum and +[send us a pull request](https://help.github.com/articles/about-pull-requests/). + +We welcome submissions which are work in-progress in order to get feedback early +in the development process. When opening the pull request, select "Draft" in +the dropdown menu when creating the PR to clearly mark the intent of the pull +request. Prefixing the title with "WIP:" is also good practice. + +All new features should be submitted against the main master branch. Bugfixes +should too be submitted against master unless they only exist in a supported +back-branch. If the bug exists in both master and back-branches, explain this +in the PR description. ### Validation checks and CI -- GitLab