Following on the discussion in the last monthly call, here are some notes from this week’s dev call with ideas for the first farmOS.org blog posts.
The idea is: we (the core team) can collaboratively write the first one (as a basic intro), and then we can commission future posts from other members of the community, with bounties paid from OpenCollective.
Ideas for first few posts:
Intro to farmOS (see below) - written by core team
How do you get farmOS installed/running?
Demo site (for playing)
Farmier (hosted option)
Self-hosted (not covered? stay tuned for future posts!)
Plant management in more depth
Animal management in more depth
Intro to farmOS (first post)
How to get started with farmOS as a complete beginner
Link to previous post for getting a farmOS instance / point to demo site as a quick suggestion (emphasize data will be lost, great for experimenting)
Quick overview/walkthrough of structure
Brief data model overview (assets and logs)
Basic navigation/pages/hierarchy
Point to docs for user guide / more info
Mapping some locations to start
How to use farmOS map (briefly)
“Locations” (aka Land/Structure assets)
Maybe two pathways/examples:
Plants
Planting quick form (unless using demo site, you may need to install via Settings > Modules)
Submit the quick form once, then go to see the records created
Look at the map to find your plant
Add an input/harvest log?
When your plant is harvested/terminated (assuming it’s an annual), archive it!
Animals
Add an animal asset
Use bulk actions to “Move” them to a paddock
Add an observation log?
When an animal is sold/died/etc archive it!
How to think about data
“Data is intended to be iterative. Assets can be archived. Logs flow into the past. Your records can become better / refine over time!”
Most important: Start putting data in! Even if it isn’t perfect. The process of learning what data needs to be tracked will be a bit different for everyone.
I didn’t get around do doing a concrete breakdown of the remaining technical tasks to prepare farmos.org for the blog’s source repo, as I planned after today’s dev call. It should be rather minimal, as I mentioned earlier, since a lot of the work is done and just needs to be merged, but I still want to look closer at my working branches to make sure I haven’t missed anything.
That said, I did want to just drop the links to those branches so anyone chomping at the bit to see how it works can check it out. Here’s my fork:
The branch you’ll probably want is the blog branch:
It branches from the site-data, which has the changes that restructure source-repos.js and renames it to site-data.js. I just rebased both onto the current main, so they should be good to work with locally.
The source I’m using for testing is here:
It’s listed in site-data.js as jgaehring/farmOS-community b/c I changed the name on GitHub at some point, but you can use it as is or set up your own source repo to test with if you like.
I think those are all the links. Hopefully I’ll get time tomorrow to assess more accurately what work remains. Once I do so, I’ll open a new proposal for the work with time estimates and a quote. once that’s all worked out I can
The one outstanding issue is how we want to structure Front Matter, because that will have a direct impact on the estimates and quotes I provide. I encourage anyone interested to look at our previous discussion about Front Matter, where I laid out some possibilities, but if I don’t hear anything else from anyone on the issue I will just scope it for some minimal YAML properties that seems sensible to me, and we can review/amend before approving that proposal.
I took a stab at a basic introduction post, mostly just focusing on welcoming folks and walking through creating a demo site with some simple example data. I figured that would be more than enough for someone to grok in a single sitting and some of the more involved/exhaustive bullet-points above could be follow-up posts. (Not stuck on that strategy, just trying to keep it simple and have something we could actually post.)
I think it is great as is! The only feedback I would give is make it even clearer that the demo site will not save data long term and you can not export it out later. I know it is mentioned on there already but someone new to farmOS may overlook this.
Well it’s taking me a bit longer to get back to this than I anticipated, but I think the next step needs a repository under the farmOS org for me to open a PR against. @mstenta if you can create an empty repo perhaps named farmOS/blog or farmOS/community-blog, then I can proceed…
I just saw this went live and it looks great! Reading the resale on the Farmier email made me think more about how these can become outdate. Maybe not super relevant to this first post, but does it make sense to not only date the posts but clearly tag them all with a particular version of farmOS that is being used? May help others down the line when looking back through old posts. Just a thought.
@BOTLFarm Yes! It would be great to have a way to signify which farmOS version a post has been “tested against”, so to speak. Seems like this would be easy to add as an additional “front matter” line in the markdown files.
I could also see this being updated from time to time, to signify that it is still relevant with new versions. And/or maybe with just some small tweaks blog posts can be updated more generally. In those cases, it might also be good to have an “Updated” date field as well.
So eg: if a post is a few years old, and just requires a small tweak to make it relevant again, someone could open a PR that fixes the content, sets the “Updated” date, and updates the “Version” to the current version.
I have been testing the FarmOS 2.x release through OpenTEAM’s subscription with Farmier over the past year as an OpenTEAM Fellow.
I have really enjoyed playing around with a personalized FarmOS account (instance) as I test out all the wonderful open-source features that FarmOS offers to a user.
As someone without a technical background related to computer science, I at first felt timid to play around with the platform as I have a perpetual fear of “breaking” my computer. Over the course of the year, I have gotten more comfortable testing out various features offered in the OpenTEAM suite of agricultural decision support tools that they are co-creating with their collaborators, such as the beautifully coordinated and humble decentralized team over at FarmOS.
The FarmOS community’s openness to work with such an amateur (coder) such as myself has been so refreshing and I think may actually be helping me reconsider my relationship with hard-&-soft-ware technologies.
I remember feeling so mesmerized at the OpenTEAM Fellows orientation back in July 2022 when Dorn Cox, founder of OpenTEAM, told the fellows about how you could get a Raspberry Pi to run FarmOS. Besides being a huge fan of raspberries and tasty pies ;), I thought how cool it is to be able to use older technology hardware/software and newer open-source softwares in a way that could be compatible and budget-conscious! I still do not have a Raspberry Pi hosting its own FarmOS server, but that possibility definitely excited this novice technologist as I dove into exploring the agricultural decision support tool (DST) technologies in OpenTEAM’s toolbox.
!