Product curation meeting #22 notes - 22 September 2020

[danielle]

Continuing the discussion from Product curation meeting #21 notes - 8 September 2020:

Done since last time we met

Current view of roadmap

In play

1. Stripe SCA compliance phase 1 + automated tests (@lin_d_hop + @luisramos0) - @Matt-Yorkley is turning the automated tests epic for the pipe. Rollout going smoothly, everyone in the UK is on SCA and so far no issues, finished in FR as well (those remaining are using subscriptions so will wait for next round of work before rolling on).

2. Mobile shopping improvements (@danielle + @maikel) - Product list redesign final tweaks being worked on this week, will need to do image resize server-side work beforehand. This likely to happen next week and the new design out the week after.

3. The BI database replica for use with Metabase (@Jana + @Matt-Yorkley) - not sure where this is at, will need an update from @Jana and @Matt-Yorkley on exactly where this piece of work is at and what’s left to do.

4. Allowing shoppers to agree on T&Cs (@lin_d_hop + @sauloperez) - flowing through pipe, first usable nugget is done, but the remaining work for the first phase is still coming through. User guide will be updated once the first phase is live, instance managers will be notified at this point as well.

5. Rails Upgrade 4.1 (@luisramos0) - community devs have started working on this, so there is some movement however no additional work has been done. On standby till @luisramos0 freed up from T&Cs work.

Next up

6. Stripe SCA compliance - subscriptions (@lin_d_hop + @luisramos0) - ready to go, stories in GH, still need to do a sanity check on test cases but to all intents and purposes it’s ready to be picked up.

7. Rails Upgrade 4.2 (@luisramos0) - not yet started.

8. Consumer price comparison (@Jana + @Erioldoesdesign) - currently investigating legal requirements, design work are progressing, inception truly underway.

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

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

11. Networking pt 1 (@Kirsten + @luisramos0 + @Mario ) - In depth work done for UI work on product list, feedback good so far, next step on that to catch up with @luisramos0 and start slicing up the work to be done for this. For @Mario the next step is to review the flow where producers to give permissions to hubs and for hubs to add products to their product lists.

12. Adapted weights and measures (@Jana + hopefully @luisramos0?) - first piece of work is done, tested, live. Another issue will be created and completed for bulk order management. Have a workaround for shipping, however there’s one bug left to fix. Making it part of the config set up may need to also be done, will size this work and then decide on whether it’s in/out of scope for this round of work.

13. Improved reporting (@lin_d_hop + @Rachel + @Matt-Yorkley) - no update from last catch up, need to integrate community feedback into planning. Low on the list at the moment so no urgency to pick this up over other priorities.

Notes from topics covered in session

Platform APIs

• Slack conversation where it was decided that the API was officially being supported. What @lin_d_hop has proposed is that we need to do a bit of work to make this ok.
• Endpoints that are tidy, others that include messy spree logic that doesn’t make sense and requires hacking. Quirks that mean we can’t support those endpoints till they’re tidied.
• Using @luisramos0’s personal email address instead of an OFN one.
• Couples tightly with bye bye spree and also adjustments improvements.
• Is this tech debt or product opportunity?
• Currently impacting on pipe as endpoints not working are going through as S2 bugs. Not sure why, given we don’t say we support an API for external use.
• Priority of this would be after what is already in the roadmap, the assumption at this point is that it isn’t a bigger priority.
• First phase likely to be deciding which endpoints we want to support.
• Having it in a personal account is a clear sign that we’re not officially supporting it.
• For now need to move it out of Luis’ personal account and use an OFN account and look at writing it up and we can point people to it without saying we publicly support it at this stage and it’s an informal set of APIs and we’re looking to improve our API coverage. Luis is has said he’s going to do the work moving them.
• @lin_d_hop will take on writing this up as a discourse item, this work can happen after the gathering.

Trademark work and the platform

• Potential work required to separate brand elements from the open source repo, so that only the open source elements are available for associates but affiliates setting up OFN instances can access these as part of their licence agreement.
• Also need to do an audit on the software, there are a lot of things that are more proprietary (e.g. about page hard links to AU).
• However, none of this work needs to be considered in the context of the roadmap yet, this is a notice that it may come up as a need as the trademark work evolves.

[luisramos0]

Hello, thanks for the update!

re network feature - I am available to catch up, let me know

re API, a few comments:

@danielle

• Couples tightly with bye bye spree and also adjustments improvements.
• Is this tech debt or product opportunity?

API work does not couple with bye bye spree. It’s pretty much unrelated since we removed spree_api almost a year ago.
the orders endpoint is related to the adjustments improvements but I dont think we should couple it with adjustments improvements even for the orders endpoints. We can refactor the API and keep the internal adjustments structure as is.

I think API is a theme in the roadmap with both features and tech debt. Currently we can say most of it is tech debt, clean up. After we have a first version oficcially supported we can start thinking about features (adding/adapting fields in endpoints, adding endpoints, etc).

@danielle

Priority of this would be after what is already in the roadmap, the assumption at this point is that it isn’t a bigger priority.

Not prioritizing API work can be a big strategic mistake. Even if you think the DFC api will support our interoperability needs, investing on the REST API is fundamental for the growth of OFN for several reasons. If this is not prioritized as part of the Product strategy, we need to prioritize it as part of the overall tech debt backlog. In that respect, I think that on the tech debt backlog this would come quite high because it is a small effort. It will be pretty quick to get this sorted out and have a map of what can be supported already and what needs to be improved.

[danielle]

@luisramos0

Not prioritizing API work can be a big strategic mistake. Even if you think the DFC api will support our interoperability needs, investing on the REST API is fundamental for the growth of OFN for several reasons. If this is not prioritized as part of the Product strategy, we need to prioritize it as part of the overall tech debt backlog. In that respect, I think that on the tech debt backlog this would come quite high because it is a small effort. It will be pretty quick to get this sorted out and have a map of what can be supported already and what needs to be improved.

It hasn’t been prioritised now, but it can’t be given there’s no detail on how the API strategically will be important to the platform and to the OFN mission in the future (all of which aren’t yet defined). @lin_d_hop’s task of starting to write up something in discourse, alongside of the work going into developing the product strategy, will no doubt highlight the importance of the API to the future path of the product. So yep, correct, strategically important, let’s start researching, identifying, and articulating why this is. And incorporate this into however the product prioritisation process evolves in the coming months.

[lin_d_hop]

@luisramos0

I think API is a theme in the roadmap with both features and tech debt

Hey Luis, this is essentially what we discussed.

The main take away is that the API is to be prioritised.
But let’s be real. We’re not saying ‘drop everything and work on the API today’.
We’re saying ‘let’s create some next steps and put the steps into the priorities while respecting what’s already in play’.

I think the first bits of API work will jump to high in everyone’s priority list.

[tschumilas]

Just want to say how helpful I found the product curation meeting notes - and thanks @danielle for taking this time. I also see from slack that you all get uber-excited about prioritizing API - and as I understand it, this will be described as an issue (ie: what it would mean and the impact on the product) at some point so we can all join the excitment. I’d appreciate that immensely.

[luisramos0]

Hello,
Regarding StripeSCA.

re point 1, this is represented in GH epic https://github.com/openfoodfoundation/openfoodnetwork/issues/4211
All that is missing here is the improvement of the Automated tests, that’s issue https://github.com/openfoodfoundation/openfoodnetwork/issues/4639

then, the party continues on point 6 below, and this one is represented by GH epic https://github.com/openfoodfoundation/openfoodnetwork/issues/4170 (I just added “part II” to the epic title in GH).
This still needs a bit of refinement: what we really need to do now and what we can leave for the future. We can do this when the epic reaches Dev Ready

ping @lin_d_hop can you please confirm this is also your understanding of these two epics?

[lin_d_hop]

Hi @luisramos0

Yes that is my understanding.

In Slack @Matt-Yorkley agreed to take on #4639. I’ll update the issue to reflect this.

I still have a task to look through #4170 and check the testing notes reflect the learning we have from the first epic.

[luisramos0]

ok, thanks @lin_d_hop !