Hubs managers can choose the adapted weight and measure units for their shops given their own local situation

Tags: #<Tag:0x00007f21951b6490> #<Tag:0x00007f21951b63a0> #<Tag:0x00007f21951b62b0>

Hi all, sorry to have been so quiet! Alas, people in the US do still want to think in odd measures like gallons and pounds, ugh. In terms of adoption of the software by actual American users, I think it’s going to be a showstopper if that’s not easily available. I’m having a hard time getting my brain around what the best solution would be, and how to describe it as something funders would write a check for - @tschumilas, I think you are closest to my time zone. Would you be available to talk me through it, and the implications/benefits for Canada, when you have a bit of time?

Happy to do a call on this @lauriewayne1 - but I want to try to replicate @Kirsten 's experiment above first so I understand the issue myself. Will have to be into next week for me (sorry really busy on the farm right now.)

No problem - I can totally relate! Everything is growing so hard! :slight_smile: Please let me know when you have a window and I will try to make it work.

don’t get distracted by the ‘weirdness’ @tschumilasand @lauriewayne1, the key issue is how much of 1, 2 and 3 do you really NEED to get going - I think 4 is definitely beyond minimum viable product. Most likely the weirdness is a bug that we deal with separately

Sorry @Kirsten, yes I was distracted :smiley: So as per your options… #1 we have now - and I just want to point out that in CAnada now we use variants that ‘appear’ to have different measures by using ‘bag’ or ‘jar’ or ‘package’ as the ‘item’. So for sausage: 1 package (8 ounces), 1 package (485 g), … so kind of cheating - but really no one minds. So this is why I say the US does have a totally workable solution right now. Its only a problem when you want to sell and CALCUATE a price per lb or per quart… So that said, IF we want to go next step, I think #2 is MVP.

It depends on how M the MVP is desired to be. But, if I was in charge of the product I would say 1, 2, and 3 are needed where 3 can just be instance config to enable/disable some units.

I just want to make sure we’re all clear on the definition of an MVP (minimum viable product):
An MVP is not a released piece of functionality, it’s something that proves whether product we’re building will meet the expectations and can be sold/used, which is then used to determine what the ultimate product/feature is that will be built/released. It’s testing your riskiest assumptions about the product/feature, not the delivery of that feature.

Let’s not confuse first release with MVP. They’re two different things.

</end of lecture>

(Can you tell that I spend my days consulting with businesses that all use MVP as a replacement for first release…and usually only release…because they want to sound cool? :grimacing: )

Anyway…as you were…I’ll get off my soap box now :laughing:

Hello, I just went through this thread now.

“We think this is might be just a case of creating some additional lines in lib/open_food_network/option_value_namer.rb”

As you can see in this description of point 2 there are 2 more files listed, and the list is not complete. There are quite a few places where this is done in the code (several places on the server plus a couple more in javascript, there’s an option_value_namer in ruby and another in js doing very similar things, but not exactly!), in my book this qualifies as a mess where conversions and lists of units appear in many different places in the code (not to mention the option_types/option_values mess with units in the database).
The problem with a mess is that you make a change in one place, deliver and then you find out it’s broken somewhere else because of this or that condition.

This piece of work will be good to clean up some of this mess and get the units logic into a single place in the code.
So, after this (I’d say mandatory) clean up is done, I agree point 2 can be “straight forward” to do. 5 dev days, specially because I think it will take some time to test and debug this.

Regarding point 3, should be easy to do, but we need to be careful with use cases where users change the settings, for example, disable grams and kilograms but there are still products in the system using these units.

I am seeing so many people in the US really wanting imperial measures - to the point of offering to “pay for it themselves” or “do it themselves” - and several people have told me it is a showstopper that causes them to decide to not use OFN. Might be something to revisit soon?

1 Like

yes @lauriewayne1 there are devs in the USA interested in working on this. Conversations on slack? We’ve just agreed in product curation meeting that @luisramos0 will be lead tech contact and i’ll be watching from a product perspective. Let’s try and get it done!

1 Like

openfoodnetwork, I assume you are Kirsten right?
I think it’s better to first ask @luisramos0 if he agrees with that? :hugs: :slight_smile:
I just asked him, he is ok with that decision :tada: :slight_smile:

2 Likes

we laughed about that in the meeting @luisramos0 - dangers of not attending :wink: but I’m glad you asked him and he’s ok with it! yes it’s me @lauriewayne1 - logged in as admin as trying to sort out people’s permissions. Might up yours while I’m here

To be honest, I think it’s totally unacceptable group behavior to assign something to someone on their absence and then make a joke about it. But that’s your decision to have that behavior as a group. I would not accept it if I was part of that group.

2 Likes

Thanks all, sigh, I suppose I will have to just accept that OFN is not going to be the one last thing that causes everyone in the US to accept metric weights and measures. :slight_smile: Can you help me with the best next steps for letting US devs that this work would be acceptable for them to do? I am very sensitive to the facts that (a) there is always more work - in design, testing, and maintenance - than there appears to be to the unfamiliar eye, (b) this work will not positively impact the global commons or users in other countries (except Canada - @tschumilas this would make some Canadians happy, yes?), and © the US is still not contributing to the global pot financially. So, not knowing the process, I am looking for help with connecting US devs with the product development team in the most streamlined way. Should I ask them to get familiar with github and understand the wiki and then contact you, @luisramos0, or should it work some other way?

@lauriewayne1 I am not 100% familiar with the latest agreements re instance specific dev initiatives/teams but it looks like the way to go. I am available to support them :+1:

re a) that’s a law of software development, not related to OFN

In Canada, we have a number of vendors selling in imperial measures - just entered as ‘item’ versus g, kg… and people are OK with it. Its a bit confusing to explain why its not listed with the other units though. I can imagine its annoying for US users for sure - not to mention, its not legally compliant. But then - taxes are not calculating on line items in either US or Can, and thats not legally compliant either. I guess we pick our issues.

Meanwhile @lauriewayne1 - your users CAN sell in imperial. Just enter lbs or ounces as an ‘item’ type unit.

I have a canned explanation about the “item” workaround that I end up using several times a week as people ask about it - in fact these days it is one of the “three things you wonder about OFN” that I proactively include whenever I am contacted by someone exploring whether it will work for them (the others are “can I use Square” and “how much does this cost?”). Since we had the same workaround when I was a Local Orbit user, I personally do not understand the importance and urgency people have around imperial measures, but I observe that it’s there and I hear from people that it would make a big difference.

just cross-posting here to keep all info together

point taken re. ‘unacceptable group behaviour’ @luisramos0 - as discussed in private message (but just sharing here so the resolution is also public :slight_smile: - it was a question in the meeting awaiting your consideration, and I was clumsy and abrupt in my communication. Sorry about that :heart_eyes:

1 Like

We already have a small draft PR for this :tada:


I think from Zee and Jennifer.

Looking at it I realize my comments may not be correct, which could be good news!
I am no longer sure that we need to refactor the option_value_namer for this.
This change could be made in a parallel to the option_value_namer problem and so, be made without the refactoring I mentioned above.

Now I am thinking that adding a few things (the units!) here and there in the code and some nice automated tests can actually get this feature to done. Let’s see what our dear new friends can get to!

1 Like