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! 
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 
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? 
)
Anywayā¦as you wereā¦Iāll get off my soap box now 
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? 
I just asked him, he is ok with that decision 
2 Likes
we laughed about that in the meeting @luisramos0 - dangers of not attending 
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. 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 
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.
point taken re. āunacceptable group behaviourā @luisramos0 - as discussed in private message (but just sharing here so the resolution is also public - it was a question in the meeting awaiting your consideration, and I was clumsy and abrupt in my communication. Sorry about that 
1 Like
We already have a small draft PR for this
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