Snowfall is excellent, I wonder if we should make it one of our templates too
4 Likes
Happy to announce our templates are live
9 Likes
sweet 
Would it be worth adding how to merge home-manager on top of the existing nix-darwin or system template (and/or vice versa)? When starting out to manage a computer + my homefiles this step will eventually come up.
Small nitpik/ suggestion: Rename the system template to something more descriptive that does not overlap in meaning with the system attribute.
Linux comes to mind but it feels to ambigious. But than the range of supported systems can also be some more wider…
Damn it’s getting late, can’t think of a proper name right now. In case this comment doesnt speak to you, plz disgard it.
2 Likes
Should we move this from documentation to core? This doesn’t seem like a documentation issue to me, and people might get confused what it is
When we were working on the templates earlier, we were using auxports instead of nixpkgs right?
Why do the templates say nixpkgs now? 
Let’s keep it as nixpkgs for now if it is referring to our nixpkgs fork. Otherwise if we are pointing to our “packages” repository we can reference that as “Aux Packages” for now:
2 Likes
Ah! Okay!
I missed this. 
1 Like
I think the original idea of having it in docs is that it’s about onboarding new members & getting a system up and running, but I agree that in isn’t the sort of thing you immediately think of as docs. I have no great objections to core taking over so long as they want it, believe they can maintain it, and the rest of the docs team doesn’t speedily raise some objections I hadn’t thought about
3 Likes
IMO it makes more sense for the folks closer to the technology to own the onboarding process. We can always reference it in docs and quick-start guides no matter where it lives.
I’m certainly happy to take it. But I think that it would be a good idea to share the templates repo between core and docs. Especially since this is the first place users are going to see aux, so I think its a good idea that the docs team were on top of any changes that were to come in and ensure that the information we put there is accurate and easy to understand.
4 Likes
That’s an excellent idea! I’ll immediately give core maintain permissions on there & update the badge, and we can discuss how shared ownership stuff works (or if it’s needed rather than docs watching the repo like hawks) at some later point
2 Likes
(I have done so, SIGCore members on GitHub have permissions to maintain now, SIGCore leaders have administrator rights over the repository)
2 Likes
Now THAT is collaboration 
1 Like
I assume “leaders” are just a team role that exist at the moment? I don’t think we’ve had any proper discussion around leadership responsibilities/nominations yet, unless I missed those.
1 Like
Correct, SIGDocs is currently holding a discussion at Documentation leadership responsibilities and I believe that some other teams (Core) are planning to closely watch it for their own leadership.
You are welcome to participate!
The core idea, from SIG Specific Team Leads, is to avoid a bottleneck with permissions.
We will be electing 2 leads for SIGDocs at SIG Documentation: Team Leadership Election when that discussion has happened. Until that happens, myself and @coded are acting leaders.
2 Likes
Just want to add we also have a open discussion for SIG core: Team Leadership election that is currently on pause whilst documentation for what is expected for a team leadership means.
Nice work 
How would you suggest we structure the non-flake template? Bump directory structure a level and have top level channels & flakes dirs?
1 Like
This is most certainly a TODO, I would love for you to open a PR since I personally have never worked with channels.
2 Likes
Cool. I’ll see about starting a draft this weekend. Obv. suggestions are very welcome
3 Likes