Hi folks, just checking in on this process with some reflections following yesterday’s release (v2.7.1)
What happened: We released a complete change to shopper experience, without warning shop owners or customers beforehand. Instance managers had been alerted that this change was coming in the next few weeks (probably early Feb) but not that it was coming in this release. Here in Aus we scrambled to inform shop owners and wrote a crap newsletter in a hurry that didn’t explain it well, and it was just luck that I was able to shuffle tasks to write it there and then, and luck that @danielle was online to review the newsletter. I didn’t really have adequate documentation of the logic of the change to explain why it was being made. Shop owners had zero time to inform customers of the change, and some shop owners couldn’t see how to open order cycles - the shop tab wasn’t intuitive, they were just freaking out. There is still no documentation in the user guide to point them to.
Some alternative ways we could approach this:
Where there’s a dramatic change to shopper experience like this, it would be great to be able to alert shop owners at least 1 week beforehand so that they can pass this info on to customers. I think a change like yesterday’s fits somewhere between a usual weekly release and a feature release, and in a case like that it needs to be flagged to not release until it has been communicated out to shop owners and shoppers. (Or in reality, to not be released until a certain amount of time has passed since the instance managers have been informed specifically of the date of a release that needs this type of communication - whether they act or not is up to them)
I would also really like to be communicating changes that are coming to users, rather than changes that have been made - when a significant bug was discovered we didn’t roll the release back because we had just told all of our platform users about the changes an hour or two earlier. If we had told them that it was coming, we could have also rolled it back quickly and more of them would just assume it hadn’t arrived yet.
I’d love to see us including something in our templates so that the logic of a change was more visible to people communicating this on to users who are outside the product /dev team. Yes, I can see the what/why in https://github.com/openfoodfoundation/openfoodnetwork/pull/4655 but it doesn’t speak to user experience - why is this change being made from that perspective?
What’s our process for flagging which things require a user guide change, and allocating someone to them? To me it would seem ideal that the user guide update is ready to hit publish at the same time as we hit publish on the release.
In my dream version of this release, shoppers and shop owners would get a little pop-up that says something like ‘You may notice some changes! We’ve done xyz (insert logic of why) which means that you’ll find all of the products on the ‘Shop’ tab, and all of the info about how to order on the ‘Home’ tab. Check out this video to see a quick demo’
It also feels like we’re falling down on this step as a global team. The fact that I’ve written a software newsletter for Australia - rather than there being a global version that means we don’t all have to reinvent the wheel - seems like it’s not ideal. Sure, I can just share it with the rest of you (it’s here https://mailchi.mp/900662b472f1/new-open-food-network-shop-display-and-more-latest-platform-release ) but that’s too late for a release that’s already out in the world.
What do others think would work? Maybe it just boils down to this tranche of work needing a comms plan and not having it 
- I’m not sure. So maybe the main change needed is just identifying non-features that need a comms plan?