# Contrib modules/tools list

**URL:** <https://farmos.discourse.group/t/contrib-modules-tools-list/1531>\
**Category:** Using farmOS\
**Created:** [February 16, 2023, 9:21am UTC](https://farmos.discourse.group/t/contrib-modules-tools-list/1531 "2023-02-16T09:21:54Z")\
**Posts on this page:** 1\
**Showing post:** 9

<div class="post-metadata">

**Author:** ![wotnak](https://yyz2.discourse-cdn.com/free1/user_avatar/farmos.discourse.group/wotnak/32/1103_2.png) [@wotnak](https://farmos.discourse.group/u/wotnak)\
**Post date:** [February 21, 2023, 3:50pm UTC](https://farmos.discourse.group/t/contrib-modules-tools-list/1531/9 "2023-02-21T15:50:56Z")

</div>

List of custom modules/projects could be helpful as a reference for developers but also for end users to see what’s possible with farmOS, but I agree that there need to be a clear warning that those are not recommended to install and can cause problems. Putting them on a separate page with a warning on top would be probably the best option. We could also keep it in the repo as a separate list to further emphasize that these are not the same as contrib ones.

When it comes to contrib modules, I think we could require them to be published on [drupal.org](http://drupal.org) to be included in the list. This would ensure every contrib module is installable using composer and can have translations contributed using [localize.drupal.org](http://localize.drupal.org).

I also really like @paul121 ideas around automating some parts of the list maintenance [Query drupal.org for contrib projects · Issue #4 · wotnak/farmos-community-projects · GitHub](https://github.com/wotnak/farmos-community-projects/issues/4).  
Building on it, we could adopt the following workflow:

- new contrib module is published to [drupal.org](http://drupal.org) and assigned to farmOS ecosystem,
- it is automatically added to the list,
- github issue is created for manual verification/review of the module,
- if it is verified to follow stability/best practices guidelines, `recommended` property is manually set for it to true.

On the site, we could then display:

- list of recommended modules (ones with `recommended` property manually set),
- warning that the following contrib modules were not verified,
- list of the remaining contrib modules (ones without `recommended` property set),
- link to the separate page with custom modules.

This approach would allow for adding new contrib modules without maintainers time being the blocking factor, but also set clear expectations which modules are vetted and recommended.

---

_[View the full topic](https://farmos.discourse.group/t/contrib-modules-tools-list/1531)._