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.
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 LF-3371 - Getting issue details... STATUS to help users understand ☝️ isn’t a bug.
When repeating a crop plan when is the first “new” copy?
It depends! Since we’ll always have an existing crop plan we’re repeating from, we need to be conscious of how we repeat it. I see two primary cases:
Situations where I have a plan and I want to start from that date and iterate. An example of this is I have lettuce in the ground and I want to repeat the plan every week to make sure I have lettuce for each farmers market. In this case, I don’t want to duplicate the source plan. I can avoid that by checking that the “Beginning” date (see LF-3362 - Getting issue details... STATUS ) has the same value as the completion_date or due_date of the earliest task from the source crop plan. If it does, we should ignore that initial crop plan that would duplicate the source. Instead, the first iteration from that date would be the first newly created plan.
Situations where I have a plan and I want to clone that plan to a future date AND repeat that plan from that future date. An example of this is I had a carrot varietal that was awesome last year that I want to grow this year on a schedule. In this case, I would repeat the plan, starting this year (the “Beginning” date is different from the earliest task from the source crop plan), and repeat it from the new start date. In this case, we would create a new plan with a task due on the “Beginning” date and repeat it according to the rules defined.
How should name copied crop plans?
For repeating plans we’ll default to “Repetitions of <source_plan_name>” (see LF-3362 - Getting issue details... STATUS ) 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 LF-3370 - Getting issue details... STATUS .
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.