Project wishlist

Using farmOS
1

Hi. As my family starts our small family farm, we are heavily in the “Todo” phase of our operation. What I’m looking for are suggestions to track building and improvement projects that would be nice to do, but are not absolutely necessary for the operation of the farm. I would also like a way to specify a priority like “nice to have” vs. “needs to be done at some point”.

For instance, I have two buildings that really need their roofs replaced at some point. I want to have a log entry that indicates it needs to be done at some point, but not put it on the task list.

Currently in the example above, I created maintenance log against the buildings. Right now they are listed in my “late tasks” list in the dashboard.

What I’m looking for is a way to separate out those logs into a project wishlist that will get done when time and resources are available.

4 Likes
2

Welcome to the community @tlcarpenter69! :slight_smile:

A quick idea might be to set these maintenance logs with a date far in the future. This will prevent them from showing under “Late tasks”.

I would also like a way to specify a priority like “nice to have” vs. “needs to be done at some point”.

It could be worth exploring adding some additional “Flags” to logs specifically, like the ones you describe. This needs to be done via a module, but it is pretty simple.

Perhaps longer term there could be a Maintenance Plan type provided by a new module, which allowed you to sketch up ideas for future maintenance logs, but doesn’t actually create the logs until they are ready to be scheduled.

Just some ideas… I like where you’re heading with this!

2 Likes
3

Thanks. I was thinking this would be a module.

Most of the things I would put on this list are from my wife who says “It would be nice to have…” or “we really should do…”

1 Like
4

Haha yes! I have plenty of those too. :smile:

5

Hi @tlcarpenter69 ! My family property has similar needs. Basically trying to keep my dad organized on what needs to get done. Edit: It seems we’ve posted at the same time - yes exactly, my mom trying to keep my dad organized! :smiley:

About a year ago I started a module that adds a “Project plan”: https://www.drupal.org/project/farm_project_plan that is suuuuper simple. Basically a way to group logs associated with any generic “project”. As this module stands, it would let you create projects and later associate logs to the project as the project comes to life. But also there is no current release of this module so it is not officially ready to be used!

I would also like a way to specify a priority like “nice to have” vs. “needs to be done at some point”.

Right now these project plans can only have an “active” or “archived” status, but I like your idea of something that indicates something in the future… perhaps “planned”? This combined with a flag for “priority” or “nice to have” seems useful. In our work with Rothamsted we have actually added a “Planning” status for their Experiment plans. Perhaps this “Planning” status could be added to farmOS core for all Plans types?

Overall I think this ability to associate logs with a plan is really something that will be required for almost all types of plans (by default all plans do have a plan.log field to store this relationship!). We’re just missing the UI to make this association. My Project plan provides a simple solution, an “Add to project” bulk action for logs, but this isn’t perfect. Ideally such a feature could be reused for a Maintenance plan, too.

But I also I think there is a need for this suuuuper simple generic plan type as well. Maybe “Project” isn’t the best name for it but that’s where I landed at least… don’t we all have a backlog of “projects”…? :smiley:

Unfortunately life things have delayed our family from using farmOS + this module that I started a year ago, but recently I did get an instance set up for them! So if this does sound useful to you it would be good motivation for myself to revisit and tag a release of this Project plan module :smiley:

5 Likes
6

But I also I think there is a need for this suuuuper simple generic plan type as well.

Instead of pursuing this module I’ve started, perhaps we could add an initial Project plan (naming?) to farmOS core? The code is really quite simple and shouldn’t be much work to maintain in farmOS core, I think it’s more the principal of having a basic plan type in farmOS core that we need to think about.

In the long run I do think there should be separate types of plans for specific purposes (Maintenance, cropping, grazing, etc) but I don’t think there is much harm in having a basic plan type as well. People might use a basic plan to represent something now that would be better suited as a specialized plan type in the future but at least an option would be available now. It seems there will always be a use-case that doesn’t have a perfect fit anywhere too… so having a (simple) default place to put that information is useful.

Most exciting is that having a basic plan type might help spur ideas for additional specialized plan types. And I’m particularly curious how we can make some of these additional features generalized for multiple plan types (UI to add/remove logs, recurring logs, etc); having a basic plan type might help validate if a feature is generally applicable?

2 Likes
7

A basic plan functionality would be very welcome :+1:

2 Likes
8

I like the idea of a basic “Project Plan” module in core! I’m curious exactly what it would do and how it would work though.

A basic plan functionality would be very welcome :+1:

What comes to mind when you think about this @pat?

My Project plan provides a simple solution, an “Add to project” bulk action for logs

It sounds like the main problem this solves is it adds an additional way to “group” logs together (under a “Plan”). But the plan itself doesn’t do anything on its own.

The code is really quite simple and shouldn’t be much work to maintain in farmOS core, I think it’s more the principal of having a basic plan type in farmOS core that we need to think about.

My concern would be adding something that just creates more questions. I think we should make sure it solves a real problem before adding anything new to core. The risk is it becomes a dead-end that we stop recommending to people (once new plan types are added), without being able to remove.

I’d love to talk more about these ideas! I agree with the premise of having a basic plan type in core, but I think it deserves some user journey / UX thinking to make sure it provides enough value to justify. :slight_smile:

2 Likes
9

@paul121 Maybe it would make sense to tag a release of your contrib module and distribute it to a few of the folks in this thread (I’m happy to enable it on a few Farmier instances just to test). Then we can get some feedback on next steps?

This also affords us the ability to make it clear that “we might not support this in the future”, and help migrate to something better.

2 Likes
10

My concern would be adding something that just creates more questions

This is a good concern

It sounds like the main problem this solves is it adds an additional way to “group” logs together (under a “Plan”). But the plan itself doesn’t do anything on its own.

Correct! I think it’s valuable & has a clear use-case for that, but maybe it is confusing. As it stands there just isn’t a good way to group logs for these purposes:

For a second I was worried plans didn’t at least have a notes field… Without that the project plan wouldn’t be very useful! But can confirm they do have all the following base fields:

  • status
  • flag
  • notes
  • file
  • image
  • asset and log reference* (these are default bundle fields)
3 Likes
11

Funny: In the course of our year-end Operations Review, my Market Gardener and i were just today discussing the need to make a distinction between Projects vs Operations… a distinction that is, which farmOS does not support in any way, as it stands.

In our context, a Project might be something like the OP describes (we also have a roof that must be replaced some year soon!), but an agricultural experiment (e.g. a garden bed that is treated in a different way vs the norm) is far more common. Both test and control beds being planted-up w/ the same plant type at the same time, we’ll want to compare the effect of the alternative treatment on yields, but also look at other variables (e.g. soil tests) and observations over time, which implies a need for looking at other logs besides just transplanting and harvest logs (the only two log-types we’ve been routinely creating every week over the last 18 months of Operations).

So: while a Crop Plan may be one special type of module, and Maintenance Plan a second, it does seem to me that a more general type, whose characteristics could be inherited by those two subtypes, makes logical sense… But then i am no developer, and i don’t know if that’s how these things work.

Anyway: i think your model is moving in the right direction, @paul121 , though i think it may need some additional fields- two essential attributes of a project being (1) end state (i.e. “new roof installed”, or “evaluation of test & control beds complete”), and (2) review date (which might be estimated time of completion, or perhaps re-evaluation of the pending project’s priority).

If such a module were to be made available for test on Farmier, @mstenta, you can count me in as a tester.

3 Likes
12

Thanks for the input @walt !

The agricultural experiment is an exciting one. We are working on an Experiment plan for Rothamsted that is quite specific to their needs but we’re curious how it could be abstracted to support more general experiments too. A big part of this is ensuring that data is input in a standardized way (logs/quantities with comparable labels & values) which is why we’re also building many quick forms along with their experiment module.

Yep! Right now we have a lot of that data structure in place to be inherited. I think a next step is creating more re-usable UI components but this might be challenging depending on what behavior different plans provide.

Yes! These seem useful for a Project plan. A couple suggestions:

  • Could “end state” be a short text field called description or goal?
  • Could “review date” be generalized to due_date/end_date or maybe simply timestamp, with an applicable description?

These fields and some type of planning state would be useful additions to a Project plan. They also seem generally useful.

3 Likes
13

Another aspect of projects is dependencies/prerequisites :sweat_smile:

1 Like
14

Well, to be honest, It’s a bit hard to tell… :thinking:

I was quite interested in the crop plan module when I started using FarmOS (A few days on v1 before I migrated) I was never able to try it out. It’s been in the back of my head since then.

I like the idea of a maintenance plan. Containing what needs to be done, and maybe when the plan should complete.

It could be a general plan for the farm:
Painting buildings every 10th year, (Farmhose next year, barn 3 years after that…)
Cleaning field boundaries every 5th year,
Inspecting ditches every year

Or machine maintenance:
Yearly tractor service. (When done, a new job is created)
Repair seed-drill before next season.

The tasks within the plan may/may not have a due date. Painting

Plan/project functionality should somehow be able to view it’s content in a timeline of some sort. If not, couldn’t we just create logs in a specific category?

I tend to think of a project/plan as an asset.
If I open the asset, I can see the tasks/logs as usual.
But maybe there could be some extra views to visualize.
Tasks with a due date could be grouped in months.
Other tasks in “month 13”

I also think of a plan as somehing to repeat.
Or a list of things to do. For example before every winter, before calving.
Things to check before sending the harvester to work.

Count me in for testing too.

A timeline could be interesting in more settings.
It could visualize the workload during a crop season. Especially here in Norway where the seasons are short and come with a lot of variations.

Hope I made some sense. Way over time here…

2 Likes
15

I’m happy to hear @paul121 of this potential synergy with an actual project that is moreover about the AgExperiment UseCase. Exciting indeed! To your questions:

I would say that ‘goal’ nails it perfectly. Description should be used as it is on all sorts of data types for elaboration that could be fairly lengthy (or not), but Goal should be as a rule quite succinct and unambiguous, if it is to be uses as a test for Project completion.

I like ‘due_date’, because it could be used for either a deadline, an estimated date of completion, or a planned review date, as the case may be -3 distinct cases that might be addressed in some other way (i.e. a tag?).

Indeed: i would go a step further, and say, for any farm that has projects on the go (don’t we all?), some provision for Projects in our farmOS is really needed… And for that model to serve well any PM use case, those fields of ‘goal’ and ‘due_date’ are most essential, whatever you may chose to call them.

Taking a page from the “Getting Things Done” (or GTD) canon, its creator David Allen says “Projects are defined as outcomes that will require more than one action step to complete and that you can mark off as finished in the next 12 months.”
Regarding those 3 criteria in boldface, the last one about time is in a sense arbitrary, in that DA considers that no project should go more than one year w/o being subject to review/revision, but that “Due Date” can of course be shorter; the point is, there must be one. Even more fundamentally, it must involve a series of Actions (else it is simply a one-step Task) and a Defined Outcome (i.e. Goal) -else it is just a dream, nothing more.

Also of possible interest, the next point in DA’s advice about Projects is: “2. Think of your Projects list as a current table of contents of the current outcomes on your plate.” Having such a list would be most useful at review time (like DA, i think systematic review is the key to success in PM) -even more useful if coupled with a timeline, as @pat suggests.

And if a project has dependencies (as is typically the case), then Morgan is right:

… But i don’t know if that is always the case -and when it is, could that be addressed with links in the “asset and log reference” (default bundle fields), as Paul suggests?

Now i’m getting out of my depth here, talking about such details of implementation. I’m just excited to see where this is going!

4 Likes
16

Great feedback @pat and @walt!! I think this illustrates just how many different directions a “simple” Project plan could go in. :slight_smile:

I see two ways forward, which could take place in parallel:

  1. Incremental (baby step) additions to a “barebones” plan type, like the one Paul started, with beta testers trying it out and suggesting next steps.
  2. A holistic process to elucidate what “planning” means to different people, and for different use-cases, and where there are differences and overlap.

Feels like #2 could be a really good focus of an OpenTEAM HCD (human centered design) process to spec out requirements. It would require a lot more than a single one hour session, though, and bringing in more stakeholders would be critical.

I’m particularly interested in thinking about “planning features” that might be reusable across different plan types. For example, “recurring tasks”, “timeline visualization/gantt chart”, “quick form plan integrations”, etc are all things that seem to come up as ideas in different planning contexts. I think farmOS core’s focus should be on providing common building blocks like these, and leave it to downstream plan-type-providing modules to use these pieces (and build their own) to create use-case-specific UI/UX workflows.

I will say that the “recurring tasks” request has come up a lot - and could be a good candidate for a core plan type IMO: https://www.drupal.org/project/farm/issues/2962368

I want to acknowledge that all of these things are much more than what @tlcarpenter69 was originally asking about, though… which I think literally boils down to a “wishlist” (not in the farmOS feature request sense, but in the literal “wishlist of things to do on the farm” sense). So we may have blown up the scope on this thread a bit. :slight_smile:

17

That was my thinking too yesterday…
The first thing that came to mind when I read @tlcarpenter69’s topic was to use a log category, if not a flag.
Simple way to get started.

I initially wanted flags for Farm Quality Assurance, but ended up with categories as a better way.
Too many flags may get confusing, besides categories can have sub-categories.

But maybe categories is a bit out in the “not so simple” plan architecture

1 Like
18

I like where this has gone. Many times the initial question gets the ball rolling. For me, things start with the idea, which needs to get recorded somehow. But then since all projects require some type of resourcing (time, money, material), it’s nice to then be able to attach research notes and cost/time estimates as part of the plan (example: Put fencing around a garden. What does the fence look like. What materials and quantity and source. What is the cost associated with each) as well as a rudimentary project plan (maybe not Gantt chart level). In the end, I want to be able to know that a project is feasible and reasonable, can be resourced with materials, time and money, and has a plan that won’t result in a half-baked effort.

5 Likes
19

I can see how the scope for this could easily explode. I also wonder if anything already exists that could either be repurposed or used as a starting point - such as this tool which offers drag-and-drop calendar and kanban style tools for managing what needs to happen when.
https://www.drupal.org/project/content_planner - unfortunately the documentation it links to is ‘in maintenance mode’ but i found other links including this video which gets interesting around 24 mins in when the Calendar and Kanban are both demo’ed quickly.

(Note: I have not yet downloaded FarmOS but have been building Drupal and CiviCRM systems for many a year - and have been an on/off grower for even longer and finally have some land (again) that has a long wishlist associated with it)

5 Likes
20

@petednz Interesting module.

I’ve been thinking a bit on the simple route. Just to get some basic funtionality.
If we use a “plan” category, and various subcategories. A sub category could say something about importance, or a time scope.
Then we can produce logs, and put them in categories.

If there was a way to save filters and show them in the dashbard, we could have a good start.
The filters in the dashboard could just be url’s to a filtered log view.

This could be useful for other things too, given the powerful filtering.

Example:
User install plan module.
This provides a Plan flag.
A basic set of categories is setup.
A Plan dashboard module is setup

A dead simple mockup of the dashboard module:

Plans
Logs not categorized (but flagged with Plan)
Important plan logs
Must be done soon plan logs
Maybe do sometime plan logs.

Naming would be “Category name” + “plan logs”
The dashboard module would have an url for each Plan subcategory.
The user could add/change subcategories as needed. Of course a deleted subcategory could be a problem.

1 Like