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 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.
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.
Building on it, we could adopt the following workflow:
- new contrib module is published to 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,
recommendedproperty is manually set for it to true.
On the site, we could then display:
- list of recommended modules (ones with
recommendedproperty manually set), - warning that the following contrib modules were not verified,
- list of the remaining contrib modules (ones without
recommendedproperty 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.