1. Current view of the roadmap
Finished since the last meeting
…
In play - Core Pipe
- Postgres upgrade - investigations ongoing
- Refactoring Adjustments: @Matt-Yorkley - half way through the roll out. Prepping the next pieces of work with feedback from Canada. Estimated time ‘maybe a couple of weeks real time’.
- Split Checkout page - Discourse Post here, Inception Pipe Issue here. The frontend of the first step is done and Andy will look at connecting the backend.
- Deprecated Stripe connect - Need to verify complete in Aus. Issues to be created for migration to Stripe SCA and removal of Connect code.
- OFN Styleguide: @jibees to create a comparison and then devs can make a decision.
In-play - Funded pipe
API
Next step: DFC Authentication – kick off has happened. Notes are on their way.
In play - Contributor
- Question about password expiration time found by Mattieu. Still in play
- Guido’s PR awaiting testing - Still in play
2. Next Up
Ready To Go
- Tax Report (@lin_d_hop + @Matt-Yorkley) - The rocket is bored on the launch pad. Blocked by adjustments.
- Backoffice UI Uplift - Phase 1 - Paused due to too many priorities
Inception/Design
- Improved reporting - We need to think about a general technical approach for this. Tax reporting might be a good a time for this however the overall improved reporting project will be worked on after History of Invoice changes.
Ready for Inception
-
History of invoice changes (This is next up before improved reporting (@Rachel + ?) - Blocked by the work on adjustments
There are plenty of potential soultions and the best technical approach needs to be found and will be explored after Adjustments is complete. -
Invoice number system (@Rachel + ?) - waiting for re-inception, but linked to history of invoice changes.
Backlog
Discussion
Roll-out of the next release:
The release has been published for all non-core instances.
All is going well! ES, DE, BE, IE, UK, FR all released.
Turkish Specific Payment Method
Theoretically we can merge their code. The OFN Global community cannot take responsibility for eternal maintenance of this code so we need to be able to ensure that this code is somehow separate in the code. We explored the potential of a gem or engine however because of the depth of integration with our checkout flow this is unrealistic. It was agreed that we will merge this code into the code base with a) a toggle as to whether this payment method is available for an instance b) a toggle that allows us to easily switch off the tests in the case that changes to the payment flow cause this payment method to break.
The global team can support in two ways to help make sure the Turkish community get their payment method merged:
- If the Turkish team can continue to work with their developer we can support with code reviews and merging for free. Usually this work costs around 50% of development time, so we’re aiming to be generous and support the Turkish community here
We do have specific requirements about merged code that maintains the quality of our project so this might be a long-ish process. - The Global Team can take on the remainder of the development to complete this task. We estimate that this is a S-M task and I can give a rough estimate of 8-12 days of delivery time (including dev, product/management, code review, test, merge and release) to get this work fully merged from this point. We can explore prioritising this work under our funded features pipe if this is desired.
@lin_d_hop will explore with the Turkish instance if this is required.
Retro for unit prices
To be organised, hopefully for this week. @Jana is taking on the organising 
NEXT MEETING:
Tues July 6th at 6PM UTC
Facilitation: ??
Notes: ??