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.

When it comes to users I always err on the side of overcommunication. @lauriewayne1 you could always just use that popover banner we have on the homepage to let people know and direct them to a message on your website?

I view this as an opportunity to build good feelings among the users about OFN - letting them know ahead of time seems like just good general practice and easy enough to do (and helps people understand that it’s a planned outage, not just “the server fell over and they are trying to fix it”). Really, from my perspective it’s more about building confidence and making the users feel involved and included than anticipating it causing any problems for anyone - I view this as very important as basically everyone is new and we are building our user community now. And @maikel I also appreciate that the migration can happen at a time when it’s very unlikely anyone would be needing it anyway. So I would like to give people a few days notice and use that to also remind them that despite incredible growth and lots of updates, OFNUSA’s downtime this year has been zero (I think).