Release: July release

[dhmlau]

[THIS IS VERY TENTATIVE. This issues is created to initiate discussion.]

Goal

Align with Node Summit conference (July 23-25)

What to include

• Declarative support epic Declarative Support #565
• model relation
  • Legacy Juggler - Providing repositories based on relations(spike) [SPIKE]Legacy Juggler - Providing repositories based on relations  #995
• Validation and type-conversion of input arguments in the REST layer
  • Validation Epic: Validation and Type Conversion (DP3) #755
  • Router: validate input parameters Router: validate input parameters #118
• integration with REST / SOAP services
• integration with database
  • do we have enough test to show that we support all the databases we used to support in LB3?
• Extension: authentication
  • OAuth2 Strategy support for the authentication package OAuth2 Strategy support for the authentication package #230
  • Spike: Use express constructs / enable express shimming for Authentication Spike: Use express constructs / enable express shimming for Authentication #191
  • Test other Passport Strategies Test other Passport Strategies #160
• Extension: authorization
  • Extension: Add Authorization component Extension: Add Authorization component #538
• Extension: logging
• Extension: automation
• Extension: monitoring
• LB4 web site with new rebranding [EPIC] New web site design on LB4 #817

cc @raymondfeng @bajtos @kjdelisle
Per @bajtos' suggestion, i'm creating this epic for July release.

[kjdelisle]

I'm withholding my opinions until we have a backlog for these items, since it affects our ability to estimate and build a timeline.

[bajtos]

I'm withholding my opinions until we have a backlog for these items

Isn't this a chicken-and-egg problem? We cannot create a meaningful backlog until we know the high-level areas we want to address, but at the same time we cannot define those high-level areas without your opinions, @kjdelisle.

I am not entirely sure what's @dhmlau's intent in this issue. In my recent comment, what I was asking for, was to have a list of major features that we think are required for GA release but not implemented yet/not in MVP scope.

As I see it, the next step is to create high-level estimates for those areas, so that we can decide on what should be part of GA and what to leave out to keep the GA date in the near future. What I would like to see is a consensus of 1) what is story we want to tell for GA release 2) what features we are going to leave out of GA. After the list of high-level areas is reduced to what we are likely to work on in the next few months, only then it's time to start working on a more detailed backlog.

If we start building a detailed backlog for everything that we are missing compared to current LB 3.x scope, then we will waste a lot of time estimating things that we won't work on for many months, with a high probability that acceptance criteria and estimates will become invalid by the time we will get to work on those stories.

[dhmlau]

I am not entirely sure what's @dhmlau's intent in this issue. In my recent comment, what I was asking for, was to have a list of major features that we think are required for GA release but not implemented yet/not in MVP scope.

@bajtos , I've copied the list from my PR to this issue with the added github issue number so that we won't be creating duplicate tickets. Please feel free to edit the original description!

+1 on having high-level estimates. For the detailed grooming and estimates, we can do it iteratively as we're doing right now, so that when time goes by, the prediction will be more accurate.

[kjdelisle]

Isn't this a chicken-and-egg problem? We cannot create a meaningful backlog until we know the high-level areas we want to address, but at the same time we cannot define those high-level areas without your opinions

No, this is a cart-before-the-horse problem. Aiming for a date before we know what we want to have in the complete product doesn't provide any value, because:

• The scope of the final product hasn't been established
• The cost of the proposed items hasn't been determined
• The nature of each item hasn't been discussed to decide which items are must haves and which are optional
• It gives stakeholders and the community an impression that we'll be done by then, no matter how much we imply that it's not firm

I know this seems like semantics, but I want to have this discussion without a date attached to it so that we can

• nail down what must be in GA
• prioritize the estimation and scoping of those items (so that we know what the timeline for that product looks like)
• spend the remaining time figuring out what extras are worth adding after

If we're constantly viewing this through the lens of "how can we meet a July deadline?", then we're going to be tempted to cut corners and that's a dangerous precedent to set. It gives stakeholders a false sense of security, no matter how often we write "tentative" on it. They'll assume that we're only mentioning that date because we believe it's within the realm of possibility (and I don't feel comfortable giving others that impression when I have little to no data to support that idea).

If we start building a detailed backlog for everything that we are missing compared to current LB 3.x scope, then we will waste a lot of time estimating things that we won't work on for many months, with a high probability that acceptance criteria and estimates will become invalid by the time we will get to work on those stories.

This isn't a dichotomy; it's not "pipedream" vs "so close to being code it's practically compilable".

Having an estimate based on a common vision is the goal, and thus far, we've made a great many slip-ups with respect to how we plan our tasks. If we can have a "rough" set of items that everyone understands completely and totally, then we'll get estimates worth leaning on, but I'm not sure how to get there since our previous slippage says we're not doing enough to reach that common perception of what we're trying to build.

Until we can all look at a brief sentence that describes the task and think the same things about what that sentence means, we should try to be as clear as possible to minimize the ambiguity that's slowing us down.

Using that house analogy, I'm not saying that we need to agree on the exact placement of every nail used to build the kitchen, but we should at least all have a sense of the kitchen's dimensions and placement within the house.

[kjdelisle]

With that out of the way, here's my list of items that I think should be in GA:

• Extension: logging
• model relation
  • Legacy Juggler - Providing repositories based on relations(spike) [SPIKE]Legacy Juggler - Providing repositories based on relations  #995
• Validation and type-conversion of input arguments in the REST layer
  • Validation Epic: Validation and Type Conversion (DP3) #755
  • Router: validate input parameters Router: validate input parameters #118
• integration with REST / SOAP services
• integration with database
  • do we have enough test to show that we support all the databases we used to support in LB3?
• LB4 web site with new rebranding [EPIC] New web site design on LB4 #817

[dhmlau]

Capturing the discussion in the working-in-progress release plan. Closing it.