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
I agree! I think NixOS, AuxOS or whatever we decide to call it would be a good template name instead of system.
3 Likes
Freshwater is the current most likely, I don’t believe it’s been officially decided on. However we needed something to get it started
Names for projects haven’t been decided on yet, so until we get to Phase 2 we are using generic “Aux X” names as placeholders. When we get to hard fork we can differentiate the projects by name.
1 Like
I’ve learned of snowflake pretty early after getting into nix, I love it now, but some of the things are different from a “normal” flake setup and did take some time and a the occasional cry for help in Jake’s direction to figure everything out.
Even now as I’ve gotten used to it, some things are not as easily transferable from other flakes.
I was hoping I could create some templates for very easy example configs with snowflakelib already but I was super busy with work recently so I didn’t have time yet. There is a lot of potential there, but like with anything nix, the learning curve is steep
1 Like