Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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.

Requirements

When copying crop plans the user should be able to…

… see the following:

  • Crop plan cards, including:

    • Plan name

    • Varietal

    • Current status

    • Date range

    • (Maybe?) # of pending tasks

  • (Nice to have) Card view and calendar view

… do the following:

  • Filter according to the following characteristics:

    • Date range

    • Statuses (multi-select, including ‘select all’)

    • Locations (multi-select, including ‘select all’)

    • Varietals / cultivars (multi-select, including ‘select all’)

    • Rating (X stars and up)

  • Indicate that a plan should be copied or not

  • Set an offset or select a date for the crop plan to start

  • Modify the location for copied plan

    • (Nice to have) select multiple locations for the plan

  • (Nice to have) Expand the plan to view individual tasks that are part of the plan

    • (Nice to have) Select / unselect whether particular tasks should be included in copy

    • (Nice to have) Modify offset / dates for individual tasks

  • (Nice to have) copy the plan more than once

    • For example: copy this lettuce plan ever 15 days for 5 iterations

Open questions

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.

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.

  1. 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.

  2. 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.

  3. 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.

  1. 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.

  2. 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

Jira Legacy
serverSystem JIRA
serverId815f41e5-e5fb-3402-8587-82eccc3ffab0
keyLF-3371
to help users understand ☝️ isn’t a bug.

When repeating a crop plan when is the first “new” copy?

As designed on 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

Jira Legacy
serverSystem JIRA
serverId815f41e5-e5fb-3402-8587-82eccc3ffab0
keyLF-3463
).

How should name copied crop plans?

For repeating plans we’ll default to “Repetitions of <source_plan_name>” (see

Jira Legacy
serverSystem JIRA
serverId815f41e5-e5fb-3402-8587-82eccc3ffab0
keyLF-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
Jira Legacy
serverSystem JIRA
serverId815f41e5-e5fb-3402-8587-82eccc3ffab0
keyLF-3370
.

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:

...