The due-22nd label

@victorwu @andr3 I think we should set a clear goal we want to achieve with this label, and document it here. Any suggestions?

This came from #8 (comment 104554517)

Context

The original idea from the label came from a discussion in our weekly meeting on 18 July 2018 (https://docs.google.com/document/d/1cbsjyq9XAt9UYLIxDq5BYFk47VA5aaTeHfkY2dttqfk/edit):

• Victor: Problems with GitLab one month long iterations

  1. A lot of work merged in final week before freeze. Code review and design review rushed.

  2. Our issue sizes can still be big.

  3. Since scope is large and time is long, collaboration (especially FE and BE) is not strategic (as I observe it). One person starts an mr, but goes off to do another task since they are blocked. MR gets stale.

  4. We have mentioned these things in past retros, but I think local solutions will only go so far.

  5. Proposal 1: Two iterations (just for Discussion) per GitLab milestone.

     1. First code freeze is 22nd
     2. Second code freeze is 7th
     3. Manage work internally in Discussion team. Small coordination overhead.
     4. Additional planning required.
     5. Issues need to be small enough to be completed (merged) in smaller time windows.
     6. The first iteration’s window (8th-22nd) is often spent fixing regressions in the current timeline. But if we do smaller issues, we should have less regressions.
     7. Smaller iterations means random events and uncertainty should just be reduced in general. (Basic agile philosophy).
     8. We have RCs now very early in the cycle. So that will only help here with smaller changes being shipped earlier. (Ie merging earlier not only reduces code integration risk, but also we get on the RC train earlier.)
     9. Sean: I like this. I think we could do it informally at first, and specify that some issues should be done by the 22nd, without actually planning in two chunks
     10. Sean: question about when to start - 11.3 (summit interrupts this)? 11.4 (Sean away for three weeks)?
     11. Pedro: I would love to do this as it promotes more collaboration and iteration.
     12. Victor: will create a label to indicate done-by-the-22nd
         1. Soft signal for 11.3 (due to the summit)
         2. Will be in ‘full force’ for 11.4 - there are no consequences for missing it, as it’s not a freeze, but a deadline

  6. Proposal 2: Internal Discussion team 2 week iterations that snap to calendar weeks.

     1. Not realistic because very confusing and requires lots of coordination and communication.

     2. Just mentioning here because this is an ideal extreme for collaboration but not realistic for GitLab now.

     3. I think this is possible with more frequent releases to GitLab.com. But not realistic for an individual team now.