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
This is fair, but I’m afraid I also think the documentation for snowfall, while nice in places, is pretty mid in places. I think there’s things that could be done to reduce that learning curve a fair amount.
A template and a guide would be an awesome start
2 Likes
Without a doubt. I would consider Snowfall Lib’s documentation as one of the lower bars to clear. The quickstarts are barebones, there are no guides, examples for most things don’t really exist, and the most useful part of it is the reference page which is just everything all at once. I would be very happy if we did better than that and, hopefully, we will with more people working on it!
4 Likes
Yeah, I’ve checked out snowfall a ton, but could never get a derivation working because the docs were really sparse. I’d like to write some but I’d need some help understanding it first lmao
1 Like
Our configuration is nice, but also not a particularly common use-case. I think the lessons we’ve learned will be more useful for writing something simple than what we have actually written
Still, no problems with people pulling from it… probably we should relicense under whatever we’re putting templates under
1 Like