Product curation meeting #20 notes - 25 August 2020

Product Development
1

Continuing the discussion from Product curation meeting #19 notes - 11 August 2020:

Done since last time we met

n/a (Spree upgrade almost!)

Current view of roadmap

In play

  1. Spree and 2.1 and Rails Upgrade - only one s3 bug left, then it’s done like a dinner.

  2. SCA Compliance phase 1 + automated tests (@lin_d_hop + @luisramos0) - still rolling out to hubs during the European summer, UK actively doing it now. Deadlines for this compliance issue hit France first. Will also include setting up automated testing for Stripe, which is super important.

  3. Mobile shopping improvements (@danielle + @maikel) - no change, product listing is still the main thing we’re waiting on, close but not closed.

  4. The BI database replica for use with Metabase (@lin_d_hop + @Matt-Yorkley) - Mostly done, in code review, one question around Katuma set up to be resolved.

  5. Hub’s suppliers can prepare individual orders for the hub’s customers (@Kirsten + @sauloperez) - ready for testing, will then review if more is required.

  6. Allowing shoppers to agree on T&Cs (@lin_d_hop + @sauloperez) - work commenced on first bit.

Next up

  1. Rails Upgrades 4.1 and 4.2 (@luisramos0) - Luis is continuing to work on his PR. Remaining work to be kicked off once other priorities are delivered.

  2. History of invoice changes (@Erioldoesdesign + @Rachel + @luisramos0) - waiting for re-inception

  3. Invoice number system (@Erioldoesdesign + @Rachel + @luisramos0) - waiting for re-inception

  4. Consumer price comparison (@Jana + @Erioldoesdesign) - waiting for inception

  5. Networking pt 1 (@Kirsten + @luisramos0 + @Mario ) - Working way through prototypes, and analytics considerations in play. @Erioldoesdesign beginning work on this alongside of @mario’s lead. Next step is technical solution design that then will shape the feature candidate.

  6. Adapted weights and measures (@Jana + hopefully @luisramos0?) - There are a few product considerations required for this work, so Jana is going to jump in and get up to speed and then make some decisions (with any help she needs) in getting it all clear and well storied and going through the pipe smoothly. PR with all the work done to date is here.

  7. Improved reporting (@lin_d_hop + @Matt-Yorkley) - Lynne taking over the work from Harriet on this work, tax report has a design, will be getting instance managers to review this wireframe to make sure it covers all requirements. Note that a new refactored version of reporting will be used for this first report, and after that we’ll be exploring putting all reports on this version, one at a time. Each of these will be a small piece of work.

Notes from topics covered in the session

Prioritising the next phase of the SCA work

SCA Compliance phase 2 (@lin_d_hop + @luisramos0) - involves subscriptions and only the UK uses this capability. Also includes getting other instances onto the new version of Stripe and remove support for the old version.

:point_up: needs to be added to the list. We thought that above Rails made sense because the longer we wait the longer we have to test both versions of Stripe.

@luisramos0 we didn’t add it because we wanted your input. How do you feel about putting it in the number 7 position?

1 Like
2

Hello,

What S3 are we saying is holding v3 being done? Is it https://github.com/openfoodfoundation/openfoodnetwork/issues/5743 -in this issue I think we are saying this wont be easy to fix now… I’d say we can consider v3 done if this is the pending issue.

In terms of StripeSCA vs Rails upgrade.
StripeSCA is quite a lot of work. I think we should break the epic in smaller parts.
A. StripeSCA - Improve Stripe automatic tests
B. StripeSCA - Make StripeSCA work with Subscriptions
C. StripeSCA - Delete StripeConnect code (only after roll out of StripeSCA for Subs)
D. StripeSCA - Extra features (phase 3?) - I dont think we will need to implement all of the issues in https://github.com/openfoodfoundation/openfoodnetwork/issues/4170 to roll out StripeSCA for Subs

I think we want to prioritize A and B for now. C will need the roll out of B to happen and that will take some time before C is actually dev ready.

I think we should separate Rails 4.1 and Rails 4.2.
E - Rails 4.1 upgrade
F - Rails 4.2 upgrade

Rails 4.1 has around 30 broken specs. It’s now a small task.

Point B is quite a lot of work (the fact I dont want to give a time estimate for it is an indication, but we may be surprised, I dont know). So, imo putting B above E is too much time without investing on paying back tech debt. v3 was a great step forward but OFN is still very far behind on this topic. So, I’d vote to have E, Rails 4.1, above B (StripeSCA for Subs).

3

What S3 are we saying is holding v3 being done?

I wonder if it wasn’t Error while adding a payment method · Issue #5649 · openfoodfoundation/openfoodnetwork · GitHub ?
It was merged after this last product curation meeting.

4

@luisramos0 would be awesome if you could come to these product curation meetings so you can contribute to the conversation when we discuss prioritisation of things like SCA. In trying to be efficient with our time being able to have these conversations in one place means we don’t have to re-consider the decision afterwards based on input you provide. :pray:

I’ll leave you and @lin_d_hop as the owners of the SCA initiative to get on the same page regarding how to break down the work and to present your collective pitch on how it should be prioritised in the pipe at the next session.

Re: the S3 it was one that was already in code review. No idea which. We assumed that this would be officially done as an initiative well before the next curation meeting.

Let’s take what you’ve suggested here in terms of rails and SCA and discuss in the next session, all together, and revise where required.

5

@luisramos0 great! Sounds like we are basically on the same page re SCA.
The discussion about B before or after E in the meeting hinged on the need to support Stripe Connect and Stripe SCA at the same time. But you are right that removing Connect with be another work package after B. I’m happy to agree with your proposal.