Focusing in for the first half of 2019 - a proposal for the global community

Hello everyone and in particular @Kirsten @MyriamBoure @Rachel @lin_d_hop @NickWeir @sauloperez @luisramos0 @tschumilas @MSFutureFarm @lauriewayne1 @Theodore as instance owners (who can ensure anyone else in their local world who should see this is directed here :smiley: ).

Myself, Kirsten, Rachel and Myriam caught up this week and chatted about the state of the product development process and pipe this week in terms of:

  • Trying to push too many discrete features through at the same time and spreading our dev effort too thin.

  • Having too many things still in the pipe from a long time ago (product import, subs)

  • Voting for things that don’t necessarily fit into our 4 focus areas (#makeitgreat, #techforfuture, #network #singleteam) and the fact that our diligence in using these focus areas has waned.

  • The fact that sometimes local needs for a particular thing are great and yet when it comes to voting these things will never see the light of day.

  • The custom/bespoke things being built for instances that in some ways can be seen to subvert the global prioritisation process but that can also be used by other instances and could be better included and considered in this context.

The discussions and responses to these points were things that we felt the global community would like to be involved in, so we’re bringing 3 agenda items to the global hangout next Tuesday (aka Monday way too early for our North American contingent).

But prior to this we wanted to pre-arm you…firstly with this list above so you have time to think about these things before the hangout. And secondly, with a proposal we would like to get approved in the global hangout on how we focus our attention in the delivery pipe for the first half of 2019.

Please come along to the global hangout next week where we will put this proposal to the community for discussion and approval. And talk about the other tensions above and find a resolution.

2019 Q1/2 software improvement goals (proposed)

Goal #1 - Clear out the delivery pipe to have only 2 features being developed at any given time.

This means we would do a spree and a mobile ready, or a product import and a subs. Not all of them at once and keep piling things in on top of them and never delivering any of them.

Goal #2 - Spree upgraded to 2.0 (FUTURE PROOF THE TECH PLATFORM)

We’re getting there, it’s close, we just need to close the deal this half and then review the other dependencies that can/potentially should follow this work.

Goal #3 - A concentrated focus on MAKING WHAT WE HAVE GREAT

This means we do things that are specifically improving the functionality we have now and not building out features to have more functionality. Things like:

  • Mobile ready

  • Clearing some severity 3 bugs we have in the pipe that are annoyingly annoying and bad.

  • Map icons that make no sense.

  • Enterprise admin UX pain points that suck our users’ will to continue.

  • Performance issues (so slowwwwwwww!)

  • Taking the first step in improving reports by exploring how all instances can easily have Zapier set up and in use if they want it.

  • etc


amazing! thks for putting it together. perfect.

i think goal 3 can include the current work to document the api.

It’s also already in the delivery pipe, prioritised outside of the prioritisation process (but for good reason given it is being worked on by a separate team to the core dev group). Thus it fits goals 1 and 3 :smiley:

Thanks a lot @danielle!

I’m really glad performance is on that list. It is something @Rachel and I chatted about in one of the FOSDEM’s cafes. I wanted to share a new discourse thread but I think it fits perfectly here.

I want to stress the need to focus some of our efforts on performance. It is nothing new that the overall performance of the app is already awful but what concerns me is that it could become a serious thread in the future because it might discourage others to join.

I feel like with Portugal growing in terms of shops, given the interest from Oikos, and italians wanting to give it a try, besides Katuma’s own growth, might lead to another bloated instance as the main ones already are. Again, this would have implications in terms of food hubs wanting to join, necessary for our sustainability.

Lastly, the single instance topic is becoming increasingly important and with current performance this is impossible.

However, good news is that there few rather straightforward actions we can take to remedy this, as I already explained few times. I’m quite optimistic about it. We just need to spend some time on it. That’s all I wanted to share.


#singleinstance :hearts::hearts::hearts:

I also think we should make decisions on the above that move us toward a single instance. And we aren’t experiencing performance issues here yet - but yesterday I was showing someone what OFN will look like once its populated and went to the UK instance - OMG - I was embarassed at how slow it was! So if this is what people mean about performance issues - yes we have to deal with that.
I also want to ask - @danielle - can you just remind us here - what other issues are already prioritized and in the pipe (like document API that @luisramos0 mentions above. It would be good to have everything on my dashboard for our discussion.

1 Like

Hiya @tschumilas you can always see what the state of features in the delivery pipe are via the product feature backlog. I keep it up to date as best I can based on what comes out of conversations and decisions on here :slight_smile:

I love the specific list of things we can do/finish now. I am thinking of the single instance idea and wondering where to find discussions about the size and scope (and a description) of that effort.

TShirt size of single instance is XXL - OFN must support all currencies, all instance specific configuration must be unified, taxes, legal requirements etc etc etc.

A key prerequisite of single instance is speed/efficiency improvements. Much more worth scoping and prioritising aspects of this at this time.

Good news all - we had agreement at the global hangout that the proposed approach and 4 goals are ALL SYSTEMS GO!

:tada: :tada: :tada: :tada: :tada:

I’ll have a look later this week at what this means for our delivery pipe and also what the contenders (on and beyond the list) for goal #3 could be and also how they should be prioritised.

1 Like

OK team, so here’s what I’m thinking:


We’re sorting out goals 1 and 2.

Spree Upgrade - the bulk of our pipe bandwidth is here until June.

Product Import - @Rachel + @Matt-Yorkley on this, likely not to be done till end of Feb.

Enterprise fees - @Kirsten + @kristinalim on this, likely not to be done till end of Feb.

Subscriptions - @Rachel + @kristinalim + @Matt-Yorkley on this, will be picked up properly once the two things above are done. Likely not to be done till end of March.

Document the API - @luisramos0 is taking the lead on this, and a group of students are doing the work. It will then open up the opportunity to build on the API, if we decide this is a priority for the platform.


As soon as we achieve goal #1 which is to have no more than 2 features in the pipe at any given time, and we get the three features through to done, we can then start working on goal #3.

Shopping on mobile - @Kirsten + next available devs will work on this, but we need to wrangle scope back from ALL THE THINGS to being the core things that will allow shoppers to successfully place an order via their mobile. And we make that experience damn fine!

Shopping S3 bugs - to keep inline with the focus in the pipe, we’ll look to do the bugs identified within the shopping experience alongside of the mobile improvements. This means that we will have a solid push at improving the shopping experience for the first half of this year.


Once the Spree Upgrade is done, we will have wider dev availability and be able to add things to the pipe inline with the 2 things at a time rule. In no particular order:

Site performance - @sauloperez will drive work on improving performance, and the first task will be to define the pain points and then determine the success indicators to be achieved. Potentially giving it a red hot go for the month of June if we decide to timebox this work.

Admin UX - This will be fixing all the dumb things that drive users crazy and aren’t that hard to fix if we’d only focus on them. It can include all the admin UI-related S3 bugs that have been reported.

Reports via Zapier - @lin_d_hop can take the lead on this one, so that other instances can see how the UK are doing reports via Zapier and can have equivalent stuff set up. Though maybe I’m understanding this one wrong in terms of scope, happy to be corrected.

Thoughts? If everyone is happy with this approach then we’ll keep on trucking!

Ping @Kirsten @maikel @Jen @tschumilas @Rachel @MyriamBoure @lin_d_hop @NickWeir @SineadOFNUK @Matt-Yorkley @sauloperez @luisramos0 @lauriewayne1 @MSFutureFarm

One additional thing to note:

The work we’re doing developing a WordPress theme and sitebuilder set up for Canada (which can then be used for any instance) and for the global site also fit firmly into our 3rd goal to make what we have great:

  • The current global site is a shambles
  • We don’t have a well blended content/platform experience for our local instance users.

So I’d like to propose that the work @Jen and @tschumilas and Yuko and I (though not specifically in the delivery pipe for the platform) are still things that can be counted towards our goal for this first half of the year. Even if we do operate on the fringe of the pipe :laughing:


nice @danielle, just a comment on: “Once the Spree Upgrade is done, we will have wider dev availability”

After Spree 2.0 Upgrade is done we should leave a buffer for debugging live issues that come with it and also for clean up.

Also, I think we should start calling this task Spree 2.0 Upgrade because afterwards we have Spree 2.1 upgrade which is the one with the big goal of moving to Rails 4.

1 Like

We should probably have a longer view of what is actually involved in this dependency work @luisramos0, so we can better understand it’s impact on the delivery pipe. Perhaps we need an epic for 2.1, and then another epic for Rails 4? And some thinking on that epic about complexity in comparison to what has been done so far. What do you think?

Couple of notes:

  • I think API work and Zapier work can intertwine. To expand on Zapier I’d love to integrate properly meaning specific endpoint based on the Zaps we all want. I’m well up for leading on this work with @luisramos0 - particularly if we can parallel the pipe a little bit!

  • I am also up for contributing to the global site to whip it into shape

I write, fully of energy, as I quit my job yesterday.
No money + more time = Lynne spending all her life on OFN :smiley: #onlyhalfjoking


Awesome @lin_d_hop
I am looking forward to work on the api. Currently I am on v2 until it’s live.

Anything is possible…if the community votes that this is the next priority thing to put in the pipe. For this half of the year though it’s about small improvements and if Zapier is already up and running then we can initially just look at how other instances can reap the benefit of your hard work in the UK @lin_d_hop, then we can look at extending it out beyond that and prioritise it against Spree 2.1 / Rails 4 and the other things that have been voted for, etc etc.

If only the pipe bandwidth was huge so we could do all the things (one at a time though, @luisramos0, of course, but just quicker :wink: )!

1 Like

Of course and obviously pipe bandwidth is the limitation.

However my potential work on understanding most effective endpoints to meet our needs through Zapier integrations would be outside of the pipe, as it would not impact my capacity for anything pipe related that I might be doing (which is currently nothing).

Am I right in thinking that @luisramos0 worked on API stuff without it being prioritised because he volunteered his time on it? If so maybe there is a potential conversation to be had about a separate “integrations” pipe in that case… assuming @luisramos0 would still be able to volunteer additional time to API once v2 is live. Then the community could prioritise integrations collectively in the same way we prioritise all the things and API work wouldn’t be blocked when there was actually potential resource to do it sooner. Similarly the main pipe wouldn’t suffer from losing any capacity.

Not trying to derail or complicate anything… I just wonder if there is a conversation to be had around this? Different pipes for different skill sets?

This is when I confess my volunteering heart as moved elsewhere recently :heart:

All for it, would be awesome to see that happen. And also to get more Lynne magic in the main pipe as well @lin_d_hop, if there’s room :smiley: