That's a good list! I can't think of anything more important after the 1.0 release.
As the MOSS application has to be for a specific topic/task, I would propose to go with the modules. There's just a lot to do, as you outlined, and yet it's all kind of interconnected and regards one specific topic. Maybe we can define the exact goals a bit better, based up on this list.
1. Module publishing/registry
I guess it's easiest to just go with a convention for npm module names (and/or Git repo names) for this. We could also add a wiki page with static links to known modules, too. Why re-invent the wheel and build that stuff ourselves, when we can just use the most popular package registry today. (So maybe not ideal for a grant goal, as it should be easy and quick to do before.)
2. Module concept/layout/scopes/linked-data
I think this is the big one we have to tackle. I can see multiple topics coming out of it:
- Use Linked Data, JSON-LD etc. correctly, decouple schemas from module code, and allow linking between schemas (as per JSON-LD and JSON-Schema specs)
- Generate docs from/for schemas for developers to quickly see what properties they can use and how
- Decide what to publish in the location of the JSON-LD @context URL and implement automation for it
- Rethink the way modules are actually used and defined (e.g. do we even need custom module code for a module that only stores JSON objects in subdirectories, or can that be done via a standard API that does lists/subdirs in addition to schemas/types)
3. Module CLI
Correct me if I'm wrong, but this sounds like the idea for a CLI that lets one create a rs.js module from the command line, including its npm package info, dependencies, a test setup and so on. That would be awesome!
As this only makes sense once we've solved topic no. 2, I think this probably also makes sense to do outside of the grant goals.