Copying crop plans
Work in progress
Why is copying crop plans important?
Creating a crop plan is a time investment. Each plan can take 1 - 2 minutes to complete if the user is familiar with the crop and much longer if they’re not. Asking the grower of a diversified farm to do this potentially dozens of times every growing cycle, or potentially multiple times each growing cycle for sequentially planted crops is a non-starter. Farmers need to be able to easily copy over what worked from previous seasons, and modify what didn’t.
What use cases are there for copying plans?
We know of 3 primary use cases where farmers want to copy their crop plans. There may be others.
Repeating crop plans: I would like to create a crop plan and then have it repeat on a set schedule. Some fast growing crops - such as lettuce - are planted at a set cadence throughout a season. For example, microgreens require 2 - 3 weeks to mature. If a farmer wants to be able to sell microgreens at a farmers market each weekend throughout the growing season, they’ll need that crop plan to repeat every 7 days for several months.
Clone and tweak: I would like to clone an individual crop plan from a previous season to my current or planned season. It could be that the crop grew really well and I just want to repeat that success exactly (as much as that can ever be guaranteed in farming - hah!) by cloning the previous plan wholesale. It could also be that the plan didn’t work perfectly last time and that I want to tweak it slightly this time around. For this use case, I should be able to make changes to the existing plan such as changing the location, moving up or delaying the planting date, or removing or modifying tasks.
Bulk clone: Last season rocked and I just want to clone most or all of my plans into my current or planned season. In this case, it needs to be easy to visualize a bunch of plans together and select which ones to clone in an orderly fashion. Any modifications to plans should be straight-forward and likely visual rather than textual.
Q&A
Should we focus on a bulk copy instead (or in addition to) to allow the modification of many existing plans at once? For example, if there’s a last minute cold spell - all plans may be pushed back by a week.
Nope - lets get simple copies out first and then get feedback for the more complicated bulk adjustments.
How should we be supporting crop rotations?
TBD; not covered in this initial salvo.
When copying a crop plan that has been completed, should we use the due dates or the completed dates of the source tasks?
TBD; there are arguments for both directions.
You could argue that the original plan (the due dates) should be followed even if the completed dates don’t align because that was the plan and different completed dates could represent an uncharacteristic event that isn’t likely to be repeated and shouldn’t be propagated to repeated plans.
However, you could also argue that the plan (due dates) are forecasts and that the completed dates represent the truer version of events and the version of events that should be propagated.
Can I delete a copied plan?
Yes! As long as it meets the other requirements for a plan to be deleted. For plans part of a repeated sequence, that plan is removed from the sequence but the denominator doesn’t change. Here’s an example:
I repeat a plan 3 times resulting in:
Plan 1 (1/3)
Plan 1 (2/3)
Plan 1(3/3)
If I delete “Plan 1 (2/3)” I now have:
Plan 1 (1/3)
Plan 1(3/3)
There’s a note on https://lite-farm.atlassian.net/browse/LF-3371 to help users understand isn’t a bug.
When repeating a crop plan when is the first “new” copy?
As designed on Jul 20, 2023 the source is never part of the repetition group. Repetitions generated at the same time are always grouped into repetition groups.
A better approach may be to remove the ambiguity from the process and allow the user to specifically define which plans are part of the group with a summary and confirmation screen (see https://lite-farm.atlassian.net/browse/LF-3463).
How should name copied crop plans?
For repeating plans we’ll default to “Repetitions of <source_plan_name>” (see https://lite-farm.atlassian.net/browse/LF-3362) with the ability to change the name as long as it’s unique for that varietal. Repeated plans will also have a new visual treatment to denote that they’re repeated via .
For crops that are transplanted, how do we support changing locations?
Kevin’s gut: The starting location isn’t as likely to change since it’ll likely be a greenhouse. However, the final destination will be more more likely to change (e.g. Field 2 instead of Field 1). For repetitions (use case 1), Kevin doesn’t think we’re likely to have any changes in transplant starting or ending locations (should be verified). For clone and tweak, we should probably support an adjustment since the tweak may be changing where it was grown.
Should we allow people to add tasks to a copy of a plan during the copy?
Kevin’s gut: No, just have them add it post-copy
Should we allow people to remove tasks to a copy of a plan during the copy?
Kevin’s gut: Yes, as long as it isn’t the planting task.
When copying a plan that has tasks that target many plans, how should that task be copied?
Kevin’s gut: Cloned tasks should only target the newly created crop plan, not historical plans or (attempt to find) newer versions of those previously targetted historical plans. This feels like more of a use case for a repeating task, rather than a repeating crop plan. For example, I might set up a monthly task to check the fences on all pastures on the farm. It’s harder (for me) to imagine a task that is part of a plan and references many other plans as well that should be repeated on a schedule.
Context:
