hello all,
zig is a wonderful platform and an evolving language, with a great / helpful community.
I thought I would create a GitHub organization for some small (in concept) / fun projects around replacing certain cough tools cough with unwise but much cooler zig equivalents.
Was wondering if anyone has a started a zig based (or other) GitHub “Organization”, what are some tips and tricks you have learned that would be wise to consider?
Ty in advance.
A little more information may be helpful here - are you including git-specific tools (such as workflows) or perhaps we’re talking about linting… etc? How specific to Zig are we talking here?
I’m asking because there are many tools that git offers that people may find useful in general that don’t specifically apply to Zig.
For sure ! Yes, precisely - curious about practical experiences leveraging GitHub Organization, and very specific to zig, but not necessarily (as far as I know) git specific – more GitHub specific.
I am pretty new to iit but familiar, somewhat, with the concept.
Wondering what is a good idea re linters/auto formatters - is it ‘Danny, you’re a young man, don’t do it!’ or is it cats meow?
What workflows/pipelines have folks setup that worked pretty well, has anyone had luck with automatically releasing a repo to various package managers (brew etc), any watch items or gotchas to be aware of, etc etc etc?
git tips/tricks are welcome too…thinking three branches (main/test/next) tie to zig release, bug fixes & next version of zig (my own lesson learned there).
Sure, so I’ll just give some advice that I think is generically sound.
The main pain points you’ll have with any large project is the structure of the project itself. Properly putting things into the right places and linking them together is going to be more helpful to the longevity of your project than any linting or workflow features. I’d argue that a well constructed project without linting is better than a well-linted project with poor structure.
I can’t speak for everyone, but here’s my experience - start with a project that has minimal features and eventually work it into a proper library (especially if you’re learning the platform). There’s a temptation to make something “look” like a professional library upfront (a former mentor of mine called that “get-there-itis”). I think it’s totally fine to have a project where you’re thinking out-loud for a long time before deciding on what external workflows and processes make sense.
If you come to find that people are interested, perhaps decide on a standards document. For instance, you may want to do snake-casing instead of pascal-casing or something else like that. That helps you decide what “linting” even really means.
You can also require the tools that you personally find helpful. Take code formatting for instance - If you don’t have auto-formatting enabled and a contributor does, the git diff will be awash in formatting changes that can obscure what substantive changes occurred.
Either way, I wish you luck on your project 
use zig fmt
I would say that a CI that runs zig build test is essential, past that it really depends on the project. As for getting your stuff packaged I have no wisdom to share as I’ve never done it, but chances are that if your project is serious enough eventually somebody familiar with a given ecosystem will show up and help you with it.
For your CI workflow make sure to the mlugg/setup-zig action.
Another lesson learned for me is to ignore semantic versioning and use zig version numbers.
Great point about fmt! I am not anti-linter but who actually leaves them on? zig fmt seems like a good step though.
Pros know the truth of uhhhhh professional libraries 
. Passion projects are often more professional 
re standards, they are really for me. So that is a great point … the barrier to contribution has to be non-existent in the beginning. People everywhere don’t have a lot of time, so it has got to be simple.
Agree re structures…what to you, would be well structured?
Thank you! Perfect.
GitHub’s reusable workflows are very handy. Set up a central repository with workflows like “lint”, “build”, “release”, and allow some inputs (target list for cross-compilation, etc.). Deploy Dependabot, making sure it will keep the dependencies of that workflow repo updated. This would eliminate the need to bump action deps in each organization/user repo—just resolve PRs in the actions’ repo, which all other repositories are using.