Amazing work @wotnak!!
Where would you prefer feedback? In this forum topic or in GitHub issues?
Couple of quick thoughts here, to be reorganized/addresses later - and apologies if these sound critical - I mean them as a critique for ALL of us who may be helping to maintain this moving forward… 
- If the end-goal is to list these modules on farmOS.org (which we should!) then I do NOT think we should include custom modules/projects. Or, if we do, then they should be in a separate page or section that explicitly states that we do NOT recommend installing them. These kinds of projects may be useful to refer to for other developers, but we do not want to create any expectations that they will work for end-users. In general, I think we should be very careful and intentional about which modules we list on farmOS.org and what expectations we set. The risk is that end-users end up confused/frustrated when they think a module will do something and it doesn’t - or worse: it breaks their install.
- With the above in mind, I wonder if we should establish a process of consent, whereby we ask module maintainers if they want their module listed, along with a process for developers to propose additions. And make it clear to them that this means setting an expectation with the end-users about the stability of their project. Modules that we “recommend” on farmOS.org should meet a certain set of quality standards, IMO. One of which should be: “this module cleans up after itself when it is uninstalled”. Otherwise we also need to educate end-users on how to test modules in a dev instance before installing them in a production instance, etc. There are a few modules I created that are in this list, which I would NOT recommend anyone install. So just generally I’m worried about quality control and the expectations that we set.
- I also worry: “who is going to maintain this?” History has proven that initiatives like this have a lot of interest in the beginning, but can quickly decay and become outdated/unmaintained if no one is staying on top of it. Automating it would be great, but there’s a lot of questions there as well. And I also don’t want anyone to feel obligated to maintain it either. It’s unpaid work. But once we set this ball rolling, maintaining it becomes an obligation for the farmOS community (assuming it becomes part of farmOS.org). I’m just raising that as a consideration - not to dissuade. The “keep it simple” strategy (eg: keeping the list small and focused on contrib modules that are intended for wider use) is one way to minimize this burden.
- One idea: maybe we have some additional attribute that let’s maintainers set expectations with a 1-5 scale… something like: 1 = don’t use this module except as an example for developers, 5 = this is actively maintained and intended for general use. Worth noting drupal.org has a similar system for denoting the maintenance status of modules.
- I notice that the
srcattribute sometimes points to sub-modules within a single repo (eg: https://github.com/wotnak/farmos-community-projects/blob/95e9024ac35b23155626e4812e425bbe8903514e/projects.json#L6). This feels weird to me. I do like the idea of highlighting different modules within a repo, but it seems like this current approach will be hard to use/maintain.
This is very cool! I haven’t used the Project Browser module myself. This is something to keep an eye on - and maybe it will be worth considering for inclusion in farmOS core in the future. I tend to be very careful about adding additional modules/dependencies to farmOS core, though (having spent a good chunk of my time over the past 10 years BLOCKED on major upgrades because of them). If we end up considering this for farmOS core I’ll have a lot more questions…
All the critiques aside, THANK YOU for spending time on this! It is really important that we start to organize what the community is working on - so that everyone can see what’s happening! It’s just the little details and considerations to figure out next. Broadly speaking I think this is a great idea.