thoughts on reorganizing https://github.com/LockerProject/Locker ?

[Jeremie Miller]

There's been some bits of conversation around this in a few places recently so I figured an official thread here will be better.

Now that all of the modular code is dynamically loaded into the locker via the registry, having the Apps/* Collections/* and Connectors/* in the main repo is a bit confusing, as that code isn't actually used locally unless it's manually upserted.

One of the proposals is to move those codes into their own repos, with the drawback being the github issues getting spread everywhere being really sucky.  Given how awesome the github issues api is, if we decide to use more repos it might be worth building a simple tool to show an index of all the issues for them together, a simple gist-based prototype being http://bl.ocks.org/1658689 (needs a lot more yet to be useful obviously).

I /think/ it'd make sense to move many of the apps each to their own repos, move each collection (and it's accompanying hello-* app) to it's own repo, and make an overall "connectors" repo to house them all together? I wouldn't be against having a repo per connector either really though, that could even be the better option in the long run.

This would leave the "Locker" repo being the core router, service manager, config, startup, etc only stuff.  It would then get it's own package.json version# as well in case there's any dependency interactions with other packages.

Anyway, just wanted to get the convo in one place, thanks!

Jer

[Forrest Norvell]

I'm in favor of moving stuff out into separate repos as makes sense, and also think it would be fantastic to have the tests living closer to the code they're testing, but I do wonder how far we want to go with this. There's an idea of a "minimum viable locker" knocking around my head that includes some core collections and the dashboard, among other things. It's hard to get a sense of what the locker does just from the locker core, and having a certain amount of the code that runs on core *right there* on the first checkout makes it easier for new developers to get their heads around what we're all trying to do.

That said, there's certainly no inherent reason why, say, the music collection and its attendant connectors needs to be part of that core. Arguably the same could be said about the places collection, although a lot of the energy around the project thus far does seem to be geo-related. So I don't know?

F

[Merci Victoria Grace]

I don't know... it's hard to tell which collections and attendant collectors will appeal to people as the core product. Just my 2 cents. 

[Simon Murtha-Smith]

I am in favor of moving away from running non-core code from the tree, but it doesn't seem like we need to move that code out of Locker yet. As folks join the community, they are likely to be wanting to play with the connector and collection code, rather than core, so it might be helpful to have it around with a simple way to see it, change it, and run it.

I think we should wait a few months and reassess.

[Jeremie Miller]

There's a lot of ways to manage this and I agree it's a bit early to know what makes the most sense yet, but I'd lean towards checking in again in even just a month, any confusion or opportunity to streamline is going to arise pretty fast I think :)

[Matt Zimmerman]

I like the idea of keeping things as self-contained as possible while
they're quickly evolving together. When we need to change the connector
API, say, it would be ideal to be able to update them all at once in one
place, rather than having to synchronize updates across many distributed
modules which might be owned by different people.

Down the road, when things are more stable, it will be more natural to
decouple them, but I'm not feeling it quite yet.

--
- mdz