| [11:12:05] | <Greg[m]> | Hey all - I have several questions for today's call. I'm working with Nano and Fabri in Argentina and working to set up and instance for them. |
| [11:12:05] | <Greg[m]> | 1. Quick forms - I |
| [11:21:27] | <Greg[m]> | * Hey all - I have several questions for today's call. I'm working with Nano and Fabri in Argentina and working to set up and instance for them.... (full message at <https://matrix.org/oftc/media/v1/media/download/AcMkEYTiTyWVdyC1a7IaPCmX...) |
| [11:23:38] | <Greg[m]> | <Greg[m]> "Hey all - I have several..." <- Actually mstenta do you have reference to the quickforms you've made, or maybe ones that Paul has made? I think those are really good training examples I'd like to start with before trying to do this in Claude. Especially the RDC ones, I think those are great. |
| [11:25:32] | <mstenta[m]> | Greg[m]: Start here: https://farmos.org/development/module/quick/ |
| [11:26:13] | <mstenta[m]> | mstenta[m]: Each farmOS core quick form is provided by a separate module, and they vary in complexity, so they are great examples to learn from |
| [11:26:40] | <mstenta[m]> | mstenta[m]: Here are all of the core quick forms (each directory is a separate module): https://github.com/farmOS/farmOS/tree/4.x/modules/quick |
| [11:27:13] | <mstenta[m]> | mstenta[m]: You might also find the contrib Precipitation and Eggs quick forms to be useful examples... |
| [11:27:28] | <mstenta[m]> | mstenta[m]: https://github.com/mstenta/farm_eggs |
| [11:27:32] | <mstenta[m]> | mstenta[m]: https://github.com/farmOS/farm_weather |
| [11:28:51] | <mstenta[m]> | > 2. Farm-level data - I'm curious if there has been consensus made around where to put farm-level data (for example... farm address, farm name, certification status, farm description, etc.). In this case, we're using the multi-farm module, so I would expect it would be in the 'attributes' of the organization itself... but maybe the community has progressed on this since last we talked. |
| [11:28:51] | <mstenta[m]> | farmOS v4 shipped with the base `organization` entity type and `farm` bundle (sub-type), but did not get any further in terms of adding more `attributes` (base or bundle fields). |
| [11:29:22] | <Greg[m]> | mstenta[m]: awesome, thank you |
| [11:29:45] | <mstenta[m]> | I would probably recommend adding those via a custom module for now, with a namespace prefix so that they can potentially be migrated to core fields in the future if more consensus builds and they are added in core data model. |
| [11:29:52] | <Greg[m]> | Greg[m]: do you have the CD quick forms also? Those had some particular structures (more complicated) that I feel are good examples when you have more detailed or complex information. |
| [11:30:20] | <mstenta[m]> | Greg[m]: The farmOS Conservation Planner (`farm_rcd`) module is here: https://github.com/farmier/farm_rcd |
| [11:30:28] | <mstenta[m]> | mstenta[m]: Technically, none of the forms in that are "quick forms"... |
| [11:30:43] | <mstenta[m]> | mstenta[m]: They are Drupal Form API forms. |
| [11:30:46] | <Greg[m]> | mstenta[m]: oh... got it. They are just using Drupalto build custom pages |
| [11:30:51] | <Greg[m]> | Greg[m]: got it |
| [11:30:56] | <mstenta[m]> | Greg[m]: But Quick Forms are basically just a wrapper around Drupal Form API with some opinions. |
| [11:31:12] | <mstenta[m]> | mstenta[m]: So a lot of the same code would work in a quick form |
| [11:31:16] | <Greg[m]> | mstenta[m]: ok... well... maybe that's actually a better fit for claude, because it's pretty well documented. Do you feel that something like an AI would be better to just use Drupal Form API (?) |
| [11:31:36] | <mstenta[m]> | Greg[m]: Possibly |
| [11:31:54] | <Greg[m]> | mstenta[m]: interesting. Maybe the wrapper provides enough context that it can just keep that in mind as it developers natively in the drupal form API |
| [11:31:56] | <Greg[m]> | Greg[m]: dunno... |
| [11:31:59] | <mstenta[m]> | Greg[m]: And from there they could probably be turned into quick forms pretty easily. |
| [11:32:06] | <Greg[m]> | mstenta[m]: right |
| [11:32:22] | <Greg[m]> | Greg[m]: that's good, better to share that way |
| [11:32:37] | <mstenta[m]> | Greg[m]: The wrapper basically just tells farmOS to add them to the standard "Quick Forms" menu path. It also provides some helper traits for saving entities and associating them with the quick form. |
| [11:33:18] | <mstenta[m]> | mstenta[m]: So eg: in the future I want to add an "Assets" and/or "Logs" tab to quick forms so you can easily see the entities that were created by it previously. |
| [11:33:19] | <Greg[m]> | mstenta[m]: got it! Ok, so it's not like adding custom farmOS business logic like 'do this, don't do this' stuff |
| [11:33:30] | <mstenta[m]> | Greg[m]: This would only work for your forms if you use the helper traits. |
| [11:33:39] | <Greg[m]> | mstenta[m]: mmm... can you put that in api language for me :) So custom module == <add custom organization--farm.attributes values> correct? |
| [11:34:04] | <Greg[m]> | mstenta[m]: mmm... can you put that in api language for me :) So custom module == <add custom organization--farm.attributes values> correct? |
| [11:34:10] | <mstenta[m]> | mstenta[m]: Everything that farmOS adds on top of Drupal Form API for Quick Forms is just enhancement stuff, yes... you don't need it. But it might be helpful/beneficial. |
| [11:34:14] | <Greg[m]> | Greg[m]: also... what's a namespace prefix? |
| [11:34:31] | <Greg[m]> | mstenta[m]: cool, that's great |
| [11:34:49] | <mstenta[m]> | Greg[m]: yes. this page describes how modules can add base/bundle fields: https://farmos.org/development/module/fields/ |
| [11:35:04] | <mstenta[m]> | mstenta[m]: those fields show up in `attributes` / `relationships` in the API |
| [11:35:23] | <mstenta[m]> | mstenta[m]: a namespace prefix would be something like: `mymodulename_myfieldname` |
| [11:35:51] | <mstenta[m]> | mstenta[m]: So instead of adding a field called `address` you might call it `foo_address`, where `foo` is the name of your module |
| [11:36:09] | <mstenta[m]> | mstenta[m]: That ensures that it doesn't conflict with a field named `address` that gets added to core in the future potentially |
| [11:37:05] | <mstenta[m]> | > 3. I have a specific mike question about hosting - what level of access do we get with the custom hosting Farmier (down to user 1, access to Administration tab, etc.? |
| [11:37:05] | <mstenta[m]> | Farmier never grants user 1 access. You would need to self-host for that. |
| [11:37:28] | <mstenta[m]> | mstenta[m]: This is for security, but also simplicity/sanity for me to maintain lots of instances. |
| [11:37:35] | <Greg[m]> | mstenta[m]: yeah, I thought so... so no access to Administration at all correct? |
| [11:38:07] | <mstenta[m]> | Greg[m]: Probably not... but it depends on what page(s) you're talking about specifically. |
| [11:38:18] | <mstenta[m]> | mstenta[m]: Everything in Drupal is protected by specific permissions. |
| [11:38:38] | <mstenta[m]> | mstenta[m]: If you're hosting a custom module, you might create a role in that module that grants access to certain permissions. |
| [11:39:23] | <mstenta[m]> | mstenta[m]: I would review those, though, and won't allow access to anything that might introduce vulnerabilities or security concerns. |
| [11:40:11] | <mstenta[m]> | mstenta[m]: eg: if you want access to things like Field UI, Views UI, etc... you should do that in a dev environment, and commit it to your module... Farmier is not a dev environment |
| [11:40:39] | <Greg[m]> | mstenta[m]: I think it's ok... we'll do all that work locally anyway, and then the hosted instance is just so we can test things 'in the wild'... if we have major mods or want to use the Administration funds, we can do so locally, update our modules, and then ask you to update them. Does that sound about like the right workflow? |
| [11:40:48] | <Greg[m]> | Greg[m]: right! Yes, ok, we were on the same page ;) |
| [11:41:26] | <mstenta[m]> | Greg[m]: yep that's the right workflow! |
| [11:42:12] | <mstenta[m]> | > 4. We will need to do translation to spanish... I was curious about 1) translation for the application in general and 2) translation for specific taxonomy lists... like is it possible to have a single taxonomy list in which there is one term (ie one slug) with multiple languages as labels? Is this something that people have thought about in FarmOS or in drupal generally with taxonomy terms? Any suggestions on this? |
| [11:42:12] | <mstenta[m]> | I can install the farmOS Localization module and the Spanish language translations on individual instances. This provides _interface_ translations (where available), but it does NOT provide _content_ translations... so no you can't have taxonomy terms in multiple languages. |
| [11:42:44] | <Greg[m]> | mstenta[m]: I'm excited to get people like Nano in here and working, feeling like they can contribute and get things done. The potential is there, my hope is this really lowers the bar in a good way. We shall see tho, obvs. this is all very much a test |
| [11:42:52] | <mstenta[m]> | mstenta[m]: Generally speaking we've decided that supporting _content_ translations is probably not going to happen. The complexity is high, and there hasn't been any real demand for it. |
| [11:43:25] | <Greg[m]> | mstenta[m]: Interface translations are done in the core module though... we could contribute to that and improve it as part of this process right? I think I looked and spanish is <50% completed. |
| [11:43:41] | <mstenta[m]> | Greg[m]: Drupal does support it though, so you're free to experiment! But probably not on Farmier, because that means I need to maintain it. :-) |
| [11:43:52] | <Greg[m]> | mstenta[m]: haha, kk |
| [11:43:56] | <mstenta[m]> | Greg[m]: Interface translations are maintained in localize.drupal.org |
| [11:44:02] | <mstenta[m]> | Greg[m]: Anyone can contribute to any language there! |
| [11:44:13] | <Greg[m]> | mstenta[m]: yes, that's perfect. We definitely could contribute here |
| [11:44:26] | <mstenta[m]> | Greg[m]: And then all I do is enable the language in the instance and it downloads translations from localize.drupal.org |
| [11:44:34] | <Greg[m]> | mstenta[m]: neat |
| [11:46:38] | <mstenta[m]> | > 5. Is anyone at this point using Claude to develop in FarmOS... if so, what is their experience? These tools often very dramatically based on the size and number of examples of recent code, quality of documentation etc so before we dive in, I'd love to hear any feedback from folks. |
| [11:46:38] | <mstenta[m]> | I dunno! But I can understand how the quality can vary dramatically. |
| [11:47:46] | <mstenta[m]> | mstenta[m]: One of the reasons Drupal has a steep learning curve to begin with is because it has been around a long time and has changed a lot over the years, so there is quite a bit of documentation and examples out on the web, but it spans many versions of Drupal and sometimes its hard to tell exactly what version it works with |
| [11:48:10] | <Greg[m]> | mstenta[m]: yeah... it's critical to have a good agents.md file |
| [11:48:16] | <mstenta[m]> | Greg[m]: So I could see that making it more difficult for an LLM as well |
| [11:48:22] | <Greg[m]> | mstenta[m]: I've been doing a lot of back and form with OFN, and that has become apparent |
| [11:48:41] | <Greg[m]> | Greg[m]: the potential is there for sure... but it's not magic. You really have to be thoughtful about training and context and prompting |
| [11:48:43] | <mstenta[m]> | Greg[m]: But I'm sure there are a lot of people experimenting with Drupal and LLMs generally nowadays, so maybe you just need to do some research on that... |
| [11:48:58] | <Greg[m]> | mstenta[m]: The recent claude leak reinforces that a lot btw. Most of their value was in very custom prompting and scaffolding around the core model |
| [11:49:04] | <Greg[m]> | Greg[m]: yeah, will do |
| [11:49:52] | <mstenta[m]> | Greg[m]: first i've heard of the leak... interesting |
| [11:50:16] | <Greg[m]> | mstenta[m]: kind of a massive deal. What's great tho is all their learnings are not basically public |
| [11:50:31] | <Greg[m]> | Greg[m]: and since it was instantaneously converted to python, it's now all out of copyright |
| [11:50:43] | <Greg[m]> | Greg[m]: so poof, no every model has claude-level scaffolding (now people call this a 'harness') |
| [11:50:50] | <Greg[m]> | Greg[m]: which is amazing |
| [11:51:46] | * FredtheFarmOSBot[m] has joined #farmos |
| [11:52:33] | <mstenta[m]> | @room The farmOS weekly dev call starts in < 10 minutes. All are welcome! https://meet.jit.si/farmos-dev |
| [11:52:41] | <Greg[m]> | Greg[m]: PS... doing some testing by adding AI directly into matrix. It's all connected to my email FYI and will start in planning mode only (ie no autonomous talking without my review). But just FYI, I want to make sure it can read conversations here because that's important. |
| [11:53:36] | <mstenta[m]> | Greg[m]: Logs are here too FYI: https://irc.farmos.org |
| [11:54:06] | <Greg[m]> | mstenta[m]: oh that's fantastic! |
| [11:54:18] | <mstenta[m]> | Greg[m]: Going all the way back to the beginning :-) |
| [11:54:53] | <mstenta[m]> | mstenta[m]: Just don't let your agent write a hit-piece on me... 🫣 |
| [11:55:04] | <mstenta[m]> | mstenta[m]: (context: https://theshamblog.com/an-ai-agent-published-a-hit-piece-on-me/) |
| [11:55:10] | <Greg[m]> | mstenta[m]: I won't, I promise |
| [11:55:13] | <Greg[m]> | Greg[m]: tight leash, this one |
| [11:55:29] | <Greg[m]> | Greg[m]: I'm not just running it on a computer and paying for tokens :) I'm too cheap for that |
| [12:59:15] | <FredtheFarmOSBot[m]> | Hi, I'm Greg's dev bot called Fred 👋 |
| [13:00:19] | <Greg[m]> | FredtheFarmOSBot[m]: cool. FYI guys this is Fred, he's my claude code in the terminal (hopefully sometime soon an open weights locally run model). At some point I'll probably let him interact a bit more freely here, but for now I have to approve everything. |
| [13:08:22] | <symbioquine[m]> | <Greg[m]> "cool. FYI guys this is Fred, he..." <- I will say that a fully open source LLM where the software and data to train and run the LLM where it is trained and run with renewable energy removes pretty much all but my quality-related concerns with LLM-driven development. |
| [13:08:45] | <Greg[m]> | symbioquine[m]: fair! Let's get there. |
| [13:08:56] | <symbioquine[m]> | Greg[m]: Just quality and figuring out ways to minimize the social harms such that people keep thinking for themselves. |
| [13:09:59] | <mstenta[m]> | symbioquine[m]: It's only a matter of time IMO... |
| [13:10:19] | <mstenta[m]> | mstenta[m]: Local LLMs will always be behind the big ones, I'm sure, but bound to gain power over time |
| [13:11:38] | <Greg[m]> | mstenta[m]: 100% I have really big issues with AI, actually. It's odd because in the cases I'm using it in, it's powerful and empowering and I'm learning how to use it without degrading my brain ( a real thing you can feel ps )... or I'm trying at least. |
| [13:11:38] | <Greg[m]> | On the flip side, I think it is furthering the consolidation of power and way beyond what many people will be able to deal with. |
| [13:11:38] | <Greg[m]> | I don't know. But I am working on making raw hide tents for me and my community to live in, if and when needed. So I'm working on other paths beyond this one :) |
| [13:19:17] | <paul121[m]> | If AI bots will become very active in this chat, I will mute/remove myself :-) |
| [13:19:17] | <paul121[m]> | We kicked the idea around before but maybe we need a more dedicated dev chat |
| [13:20:35] | <FredtheFarmOSBot[m]> | paul121[m]: happy to follow whatever the rules are. Right now I'll make sure to review anything I post (leashed) and not post unless really needed and efficient. |
| [13:20:51] | <FredtheFarmOSBot[m]> | FredtheFarmOSBot[m]: ha, whoops - this is actual greg, not the bot ;) there's probably number one is getting the right login when posting! |
| [13:22:03] | <mstenta[m]> | Yea we discussed this on a recent dev call too |
| [13:22:19] | <mstenta[m]> | pcambra pointed us to Drupal's official policies, which are helpful starting point: https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquett... |
| [13:25:32] | <mstenta[m]> | This position may be untenable, but my gut is: all community interaction must be done by humans directly. |
| [13:26:03] | <mstenta[m]> | If you are asking for humans to spend time helping you, then you need to spend your own human time to be a part of that. |
| [13:26:11] | <mstenta[m]> | Otherwise it becomes asymmetric. |
| [13:26:29] | <mstenta[m]> | The cost of automated interactions will drop exponentially. |
| [13:26:39] | <mstenta[m]> | But the cost of human interaction remains the same. |
| [13:27:57] | <FredtheFarmOSBot[m]> | I think that's true, it can become overwhelming to maintainers, especially if AI is involved in a chat location like this. However, a lot of AI is more similar to copy paste than to independent thought. I don't think you'd require someone to re-write something from one window to another - you use copy paste. Similarly, if you use AI to summarize something you've done and paste that... and then there are steps beyond that. It's |
| [13:27:57] | <FredtheFarmOSBot[m]> | not that obvious where the line is really. |
| [13:28:05] | <FredtheFarmOSBot[m]> | ah shoo... posting as fred again |
| [13:28:45] | <Greg[m]> | But all this response is helpful to me to hear so I appreciate it |
| [13:29:52] | <mstenta[m]> | By that logic, I might as well have AI write all my responses. :-) |
| [13:30:43] | <mstenta[m]> | And if that's where this is all headed (agents maintaining open source code for other agents) then it is what it is... I'll find something else to spend my time on. |
| [13:31:13] | <Greg[m]> | mstenta[m]: don't take this the wrong way - but if you think that then you haven't used these tools enough.... (full message at <https://matrix.org/oftc/media/v1/media/download/ASmaye-g-mPa9ressSegStao...) |
| [13:31:23] | <mstenta[m]> | Most of the reason I do this is because I like helping people directly. |
| [13:32:17] | <mstenta[m]> | Greg[m]: I'm not talking about coding... just community interaction, to be clear. |
| [13:32:36] | <mstenta[m]> | mstenta[m]: Chat, forum, issue queue, etc |
| [13:33:02] | <Greg[m]> | mstenta[m]: yeah - well that I can see, and actually would be a reasonable and enforceable policy I think. I think conversations on an issue queue or PR may need to be more flexible. |
| [13:34:00] | <Greg[m]> | Greg[m]: here are some examples from me:... (full message at <https://matrix.org/oftc/media/v1/media/download/AXRo8dwAVXMxWNS5Z5H1Fz1Z...) |
| [13:37:49] | <Greg[m]> | <mstenta[m]> "Most of the reason I do this..." <- AI's aren't humans. They are the things I use to try to use these very complex tools. The make contributing accessible to a large number of people. But they aren't themselves people, and ultimately there are people using them that 100% should be engaging and paying attention. So hopefully we maintain that distinction and the feeling of helping (and being helped) doesn't change. |
| [13:41:38] | <mstenta[m]> | How about this as a simple first step: anything contributed by agents must be declared as such, and must declare the human who is responsible for it :-) |
| [13:42:08] | <mstenta[m]> | Specifically in issue queues and forum posts |
| [13:43:42] | <mstenta[m]> | I like Drupal's guidelines a lot (https://www.drupal.org/docs/develop/issues/issue-procedures-and-etiquett...) |
| [14:42:11] | <Greg[m]> | <mstenta[m]> "I like Drupal's guidelines a lot..." <- me too. They are clear in principles which is nice |
| [14:49:55] | <symbioquine[m]> | <mstenta[m]> "How about this as a simple first..." <- I'd personally argue for sharing which agent vendor/model/version and what the prompt(s) were. |
| [14:50:22] | <symbioquine[m]> | That feels akin to citing sources |
| [14:56:51] | <mstenta[m]> | "show your work" :-) |