Product curation meeting #18 notes - 28 July 2020

Continuing the discussion from Product curation meeting #17 notes - 14 July 2020:

Done since last time we met

Current view of product roadmap

In play

  1. SCA Compliance phase 1 (@lin_d_hop + @luisramos0) - stick with original plan - gradual roll-out, @Rachel switching as many hubs as possible during summer. Important to note that:
  • refund cannot happen from OFN for orders made through connect, once switched to SCA .
  1. Mobile shopping improvements (@danielle + @maikel) - product listing is still the main thing we’re waiting on, close but not closed.

CLOSED: Spree and 2.1 and Rails Upgrade.

  • Target Tuesday 4th August for UK and Canada, can go before @lin_d_hop is away is best, USA will go last as lots of sales and not much support
  • Retro: after delivery train half hour next week? Yup
  1. The BI database replica stuff. (@lin_d_hop + @HarrietHolley + @Matt-Yorkley) - @luisramos0 taking this on, after all the bugs

  2. Hub’s suppliers can prepare individual orders for the hub’s customers (@Kirsten + @sauloperez)

  • kick-off was planned, but @Matt-Yorkley has done the two issues, they are in code review. @luisramos0 will review
  • Product Review to check the situation and what else at 7pm (Melb time) Tuesday 4 August

Next up

  1. Allowing shoppers to agree on T&Cs (@lin_d_hop + @sauloperez) - stories in GH, ready to go.

  2. Rails Upgrades 4.1 and 4.2

  • There is a big PR @luisramos0 prepared a month ago, has feedback. Hopefully one week to finish Rails 4.1.
  • Rails 4.2 hopefully also quite small, maybe 4 weeks dev and massive value for getting there (2015-2016)
  • Bye Bye Spree is ongoing - not related
  1. History of invoice changes (@Rachel + @luisramos0) - re-incepting as required solution is changing
  • Tech solution is changing . .
  • Needs UX / design - will be allocating a new designer - yay!
  1. Invoice number system (@Rachel + @luisramos0) - re-incepting and also needs design

  2. Consumer price comparison (?) - inception and design required

  3. Networking pt 1 (@Kirsten + @luisramos0 + @Mario ) - a bit on hold, @Mario to summarise and update both as example to @Eriol and to get the team back up to speed. Team session next week

  4. Adapted weights and measures (@Kirsten or @lin_d_hop + hopefully @luisramos0?) - work stalled due to chaos in the US.

  5. Improved reporting (@HarrietHolley + @lin_d_hop + @Matt-Yorkley) - confirming scope with instance managers, creating UX brief and then work will start on wireframing

XX USA and Canada server upgrades

  • What is the performance issues - we need to see the problem - new GH issue. If it is then is easy for us to upgrade AWS as is, just click a few buttons to spec it up
  • The ‘control’ issue is really 1-2 hour job to move to a new AWS account - @lauriewayne1 when framed like this is it still a priority?
  • eco-friendly difficult to prioritise this right now, and is it what we want. We need a strategy around values-aligned and how much resource we put into it
  • Canada increasing concern about data being hosted in the USA

XX Map focus for new volunteer dev: starting a Wishlist / discussion forum re. map, to include:

  • Map ux improvements
  • Completion of OSM
  • OSM / Google - continued co-existence? If we build features in one / both etc?

Notes from topics covered in the session

  • Need to start thinking about how to onboard the product manager this week.

Thanks @Kirsten for the notes!
I now realize we haven’t discussed when we will resume StripeSCA development, ping @Rachel
StripeSCA is still the top priority and it’s likely we will decide to restart it soon. We can probably make the call when most people are back from holidays.
I believe it will land somewhere between/before point 5, 6, and 7.

It’s not a small task. There are quite a few parts to it. I am afraid we are something like 50% done only :warning:

@luisramos0 I guess it depends if this is something you should pursue or if another dev can pick it up?

I think I would put it even after 3, to not let it untouched for a long time? But I’m curious what other people think. ping @lin_d_hop @Kirsten

given that we think / hope that 4. might also be almost done, that would mean bumping 5 and 6. I don’t have a good feel of the size of 5, but I don’t think I would support putting 6 behind another chunk of SCA that’s as big as the last one. I would support doing 6 first, maybe that will make it marginally easier to finish SCA, and/or to bring in more devs etc

I think 5 is bigger than 3, 4 and 6 but smaller than 8 and 1 (the remaining stripeSCA work).

there’s nothing specific that I need to do, any dev can take these things Rachel.

@Kirsten we need to keep in mind that it means upgrade Rails for Stripe Connect and Stripe SCA. At least on the testing side we need to double our efforts :confused: We have no automated tests on Stripe yet… everything is manual.

Let’s also see this list as a priority list, not a list in which each dots will be released. If @luisramos0 is not working on SCA, then he can work on 5 or 6 in parallel.
I wonder with this discussion if 6 isn’t too low in our priority list. If we start T&C’s before we will to upgrade this new feature as well :thinking:

@lauriewayne1 can you check the comments above re. the US server and let us know your thoughts on urgency? If there are performance problems please create a github issue and document them

If it’s mostly about migrating the services from one AWS account to another so that it’s under your / our control that’s 1-2 hours

Values-aligned providers are something we’re all interested in but aren’t in a position to prioritise at the moment. Consideration will be given to this as part of our product vision and strategy process - - commencing soon (yippeeee!) I think we think that geopoliticial considerations can be part of this discussion too.

ping @tschumilas

I think the urgency is high to get a server that we have control over. Everything else can wait - I don’t have an opinion about performance/capacity because we don’t have a monitoring process in place (but we will!). I am totally fine with staying on AWS for as long as it makes sense given the global product vision and strategy.

ok so I will create an issue for the migration of the US server into an AWS account that we control . . and put it at the top of ‘all the things’ . . I think - or ‘dev ready’ so we don’t forget about it?

Would love some more info on this as I assume it’s referencing me :smiley:

Thank you @Kirsten! I’m thinking about the communications/user support/testing strategy for this transition so there will be way more coordination required than with usual changes (even big ones).

no i don’t think there will @lauriewayne1 - I am assuming that the users will see nothing at all, perhaps a few moments of downtime. So basic upgrade checks should be fine. I may be wrong - dev who does it can confirm - @maikel and @Matt-Yorkley are the only ones online this week though . .

I’m not 100% sure what’s involved here (if it’s just switching accounts) but I would expect the downtime to be between 5 minutes and 1 hour and we can do it at 3am to not impact users. Pre-communication is probably not needed because we can display a maintenance message during the downtime.