Commit ac2038b0c94abbc03fec3ef11f0efbe5f508d7d9

Authored by dosire
1 parent c3ae30b6

Detail the merge window.

Showing 2 changed files with 11 additions and 2 deletions   Show diff stats
CONTRIBUTING.md
@@ -67,7 +67,13 @@ If you can, please submit a merge request with the fix or improvements including @@ -67,7 +67,13 @@ If you can, please submit a merge request with the fix or improvements including
67 1. Link relevant [issues](https://gitlab.com/gitlab-org/gitlab-ce/issues) and/or [feedback items](http://feedback.gitlab.com/) from the merge request description and leave a comment on them with a link back to the MR 67 1. Link relevant [issues](https://gitlab.com/gitlab-org/gitlab-ce/issues) and/or [feedback items](http://feedback.gitlab.com/) from the merge request description and leave a comment on them with a link back to the MR
68 1. Be prepared to answer questions and incorporate feedback even if requests for this arrive weeks or months after your MR submittion 68 1. Be prepared to answer questions and incorporate feedback even if requests for this arrive weeks or months after your MR submittion
69 69
70 -Please keep the change in a single MR as small as possible. If you want to contribute a large feature think very hard what the minimum viable change is. Can you split functionality? Can you only submit the backend/API code? Can you start with a very simple UI? The smaller a MR is the more likely it is it will be merged, after that you can send more MR's to enhance it. 70 +Please keep the change in a single MR **as small as possible**. If you want to contribute a large feature think very hard what the minimum viable change is. Can you split functionality? Can you only submit the backend/API code? Can you start with a very simple UI? The smaller a MR is the more likely it is it will be merged, after that you can send more MR's to enhance it.
  71 +
  72 +The **official merge window** is in the beginning of the month from the 1st to the 7th day of the month.
  73 +The best time to submit a MR and get feedback fast.
  74 +Before this time the GitLab.com team is still dealing with work that is created by the monthly release such as assisting subscribers with upgrade issues, the release of Enterprise Edition and the upgrade of GitLab Cloud.
  75 +After the 7th it is already getting closer to the release date of the next version.
  76 +This means there is less time to fix the issues created by merging large new features.
71 77
72 We will accept a merge requests if it: 78 We will accept a merge requests if it:
73 79
@@ -78,7 +84,7 @@ We will accept a merge requests if it: @@ -78,7 +84,7 @@ We will accept a merge requests if it:
78 * Fixes one specific issue or implements one specific feature (do not combine things, send separate merge requests if needed) 84 * Fixes one specific issue or implements one specific feature (do not combine things, send separate merge requests if needed)
79 * Keeps the GitLab code base clean and well structured 85 * Keeps the GitLab code base clean and well structured
80 * Contains functionality we think other users will benefit from too 86 * Contains functionality we think other users will benefit from too
81 -* Doesn't add unnessecary configuration options since they complicate future changes 87 +* Doesn't add avoidable configuration options since these complicate future changes
82 * Contains a single commit (please use `git rebase -i` to squash commits) 88 * Contains a single commit (please use `git rebase -i` to squash commits)
83 89
84 For examples of feedback on merge requests please look at already [closed merge requests](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?assignee_id=&label_name=&milestone_id=&scope=&sort=&state=closed). 90 For examples of feedback on merge requests please look at already [closed merge requests](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests?assignee_id=&label_name=&milestone_id=&scope=&sort=&state=closed).
doc/release/monthly.md
@@ -65,6 +65,9 @@ After making the release branch new commits are cherry-picked from master. When @@ -65,6 +65,9 @@ After making the release branch new commits are cherry-picked from master. When
65 * 21st: optional release candidate 2 (x.x.0.rc2, only if rc1 had problems) 65 * 21st: optional release candidate 2 (x.x.0.rc2, only if rc1 had problems)
66 * 22nd: release (VERSION x.x.0, create x-x-stable branch, tag, blog and tweet) 66 * 22nd: release (VERSION x.x.0, create x-x-stable branch, tag, blog and tweet)
67 * 23nd: optional patch releases (x.x.1, x.x.2, etc., only if there are serious problems) 67 * 23nd: optional patch releases (x.x.1, x.x.2, etc., only if there are serious problems)
  68 +* 24-end of month: release Enterprise Edition and upgrade GitLab Cloud
  69 +* 1-7th: official merge window (see contributing guide)
  70 +* 8-16th: bugfixes and sponsored features
68 71
69 # Write a blog post 72 # Write a blog post
70 73