The v1.1 decision making issue

[mor10]

This issue aims to answer two key questions:

1. When is v1.1 done (as in what features should / shouldn't be in 1.1)?
2. When are we merging v1.1 to master?

Your input is required.

[mor10]

Here's my proposal:

• Once we get the SSL PR sorted and merged, we consider v1.1 feature complete and move to some sort of RC/bug testing stage to make sure everything is in tip-top shape.
• Because Gutenberg is a moving target, Gutenberg features will continue being updated in v1.1 as it merges to Master.
• We set the date for merge at October 1st or thereabouts.
• The main focus of v1.2 is BEM and other advanced templating functionality.

[bamadesigner]

Since I've been a little out of touch, I'll spend some time today looking around and leave my thoughts afterwards.

[ataylorme]

+1 on the proposal. The timeline (2 weeks) may be a bit short to test all the things, surface bugs, fix those bugs, retest all the things, and get documentation updated.

[felixarntz]

I agree with the proposal, except that I share the @ataylorme's concern about timing. There are a couple of very critical issues around that we haven't stumbled across before, which to me indicates that we need to spend more time actually running and testing WP Rig than we've previously done. Based on that, I'm not sure whether 2 weeks are enough.

[ev3rywh3re]

I really have to say y'all have done a wonderful job, so make those timelines as they fit in your live! I really had to start from scratch in the past three weeks from my Vagrant setup to my WPRIG theme (including every single local and VM decency. Ugh!) Although I am an Atom user, the only errors I have today from the 1.1 branch are CSS related. I'll be checking my error reporting while using WPRIG for my personal site work, so if I see anything, it will be reported.

[ataylorme]

Thank you for the kind words @ev3rywh3re. You help with testing and reporting bugs is very much helpful and appreciated!

[mor10]

What do you think is a reasonable timeline? 3 weeks? A month?

[ataylorme]

What do you think is a reasonable timeline? 3 weeks? A month?

Since this is such a big release I think we should:

• Decide what will be in v1.1. I link the proposal but is it formal?
• Assign testing tasks, perhaps broken up, to different folks
  • e.g. Felix for unit tests, myself for gulp, Morten and Rachel for overall
• Find out when each person can commit to testing their portion
• Set a date shortly after that to have all testing feedback and bugs recorded
• Asses and assign work for the feedback and bugs
• Determine a v!.1 release candidate date
• Set a release date
• Do a final round of testing
• Release

Edit: if the list of new features is short, as proposed, then testing for bugs, and thus the timeline, will depend on contributor availability. I think we should ask who has the bandwidth to test before and choose a date based on that rather than setting an arbitrary date.

[mor10]

Thank you @ataylorme. If it isn't clear, I have never run a large project like this before so this kind of input is extremely valuable. I'm thinking this is what the Projects feature is for?

[ataylorme]

Probably but the biggest concern for me personally, especially when working with volunteers, is burnout. I'm sure if we set a date 2 weeks out we could get it done.

However, if that timeline puts too much stress on the folks contributing the benefit of releasing a few weeks sooner is not worth having unhappy contributors and less contributions going forward.

Maybe we can start with an estimate of availability each week for the next 6 weeks. Here is mine

• 9/23 - 9/29: up to 3 hours
• 9/30 - 10/6: up to 4 hours
• 10/7- 10/13: up to 6 hours
• 10/14 - 10/20: up to 3 hours
• 10/21 - 10/27: 1 hour or less
• 10/29 - 11/3: up to 2 hours

[felixarntz]

I can't currently provide a good estimate for the next couple weeks, but I should be able to dedicate about 6 hours next week.

About timeline, to me 4 weeks sounds like a more realistic goal. Maybe we will get it done in 2, and that'd be fine, but I agree having that as a timeline would be too stressful. I think it is most important at this point that we define what goes into 1.1, and for that I agree with @mor10 that after the SSL PR only bug fixes (and more tests) should be allowed for merging into it. Everything else would be milestoned for a later release.

[ataylorme]

Sounds like @mor10, @felixarntz and I are all on the same page about #92 being the last feature to go into v1.1. I consider #123 as a bug fix. I think we should aim to get those in next week and move forward with testing.

I would love to hear from @bamadesigner and @hellofromtonya as well.

[mor10]

The 2 week proposal was merely a proposal to get the conversation started. We need to take the necessary time to get this right while retaining our sanity and jobs and healthy family relations etc. Just sayin'.

[ataylorme]

I would like to add #129 to the discussion for consideration and possible inclusion in v1.1.

[felixarntz]

Given SemVer and the amount of major changes in v1.1, I'd like to bring up the idea of actually naming this v2.0. In that case especially I think #129 should be part of this release since that would bring us to a point where we have a solid base foundation to which we could then stay more backward-compatible than we have done so far.

Releasing a v2.0 as next release after a v1.0 might feel odd, but on the other hand, we've already discussed that we would need to tell folks who have been using v1.0 that they'd need to perform several adjustments in order to migrate to v1.1. That alone indicates that maybe a major bump would make sense.

In order to not delay the entire process, maybe we can release a couple v2.0-beta versions. That would make sense for testing anyways.

[mor10]

I'm tending toward the same thinking @felixarntz re moving to v2.0 in place of v1.1. That would allow for #129 to be baked in and moves us a huge step forward.

To do this, we need a quorum. @bamadesigner @hellofromtonya please chime in.

[mor10]

Also, we need to think carefully about how we position #109 (BEM/CSS modules). If we say full core rework is v2.0, we can set the BEM/CSS modules rework as the goal for v2.1 now and provide a clear development plan into the future.

[bamadesigner]

Hi all. Sorry for my absence. Disney just sucked away all my bandwidth but we launched! Yay!

I agree we can get #92 in for the next release.

I would say if we decide to do #129 we should bump up to v2.0 because big.

With all that said, I say if we're going to do all this work we might as well try to knock out #129 and release v2.0. Unless I missed something, there's no rush here to get something out. Let's do it right and get that big change behind us so we can focus on more front-end details going forward. We've been focusing a lot on build tasks.

[mor10]

Closing in favor of #131 to start v2.0 branch with a clean slate.