Contributing Guidance

[JayRovacsek]

Hi there, firstly; this looks awesome - I'm extremely keen to utilise it in my configurations 😄
In documentation there is instances you mention that PRs are welcome; could you clarify any preferences you would have around:

• commit style (if required such as conventional commits or alike)
• code style enforcement / lint application (noting statix configuration file)
• separating commits per change into a commit each (such as is expected in nixpkgs or alike)
• any services you wouldn't accept into the repo (regarding extractors)

Thanks in advance!

[oddlama]

Good point! I definitely should add a CONTRIBUTING.md. To quickly address your questions, for now I'd say:

• Conventional commits are definitely preferred, not sure about the scoping right now feat(extractors): vs feat(extractors/services): or something else?
• There are already pre-commit hooks in place in the devshell, so alejandra formatting, and statix and deadnix for checks, otherwise open to suggestions. We should maybe add some CI checks for that.
  The formatter is currently alejandra, but I don't have a strong opinion there. Maybe going to adopt whatever nixpkgs does in the future.
• Separating commits into logical changes is certainly a good idea. (Although I have to admit that I already have been a little sloppy in that regard while developing this initial release :P)
• I'm generally happy to accept any extractor, but I would propose the following criterias/restrictions:
  • Must provide an enable option to en/disable them
  • Can be enabled by default if it is a no-op for normal systems (like all of the service extractors right now).
  • The default settings should not cause clutter (I've for example hidden openssh by default, maybe adding specific options for that would be even better)
  • Extractors should be written for stuff available in nixpkgs or community projects, so anything except strictly personal stuff. If it is for a community project (like the microvm.nix extractor) it can also be enabled by default but the extractor must ensure that systems without the community module evaluate fine.
• I'm also open to architectural design changes if there are things that could be improved.

Sounds good?

[JayRovacsek]

Sounds brillianr! Thanks very much!