> I think a lot of this discussion is stuck on what is better web or > email. Where it doesn't have to be. > > What we instead need to do is acknowledge that some people like the web > approach. > > And accommodate them so we can have guix used by more people. Simple as that > :D
Exactly. An option is to make some kind of user-story based documentation might help? For example: ------ - If you are used to a web-based git forge such as gitlab or github, Guix's approach to collaboration might seem a little bit hard at the beginning. Guix uses an email based approach, like many other GNU projects do. Email based approach relies on sending commits as patches that can be later applied by commiters and maintainers. Thee patches are sent via email, in plain text, instead of using a website for a Pull- or Merge- Request. You don't have to worry about the format of the emails, as git is able to generate them for you: $ git commit ... $ git format-patch ... If you configure git properly (link to how to do it), git can send those emails to guix automatically (see Using Git Send Mail). If you prefer, you can copy the content of the file `format-patch` generates in a plain text email, or attach it and send it to `guix-patches`. When that email is received a bug report will be opened in guix's issue system, where you can further discuss, as you would do in any other issue board or merge- or pull- -request discussion. The discussion is available at `URL` and looks like `screenshot`. If you want to share a series of patches... ------ Something like that (done with more care and attention than what I just did), might help newcomers. It's mostly the same our documentation says, but our documentation currently (I think) relies too much on the people knowing what everything means. Maybe a deeper contribution guide might be an interesting thing to write down... Also including some introduction to the internals and how to write a build-system... Stuff like that is always useful. It has to be properly maintained though, but even if it is out of date, it's still a valuable resource to have some info about the *concepts*. (we can always put the date of the latest change and a note: this documentation is designed to explain the concepts, the specific details might be out of date, but the concepts remain). Or something, I don't know. But I'm open to try it :) The case of the Changelog commits has been discussed and its important too. We need to be able to make contributors learn how much they need to write down in the commit messages. I tend to write too much, and I don't think any of my patches have been applied without changes in the commit message. For example, in guix we often do (I just invented the name): gnu: Add lolo * gnu/packages/engineering.scm(lolo): New variable. Is that enough to describe the addition of a new package? If you know what you are looking for it might be, but it looks like an automatism commiters have that is not communicated properly. What if there's something in a `let` i changed? I have to list that too? What if...? Some help on that might be useful. And also, explaining how important it is to follow the jargon we use in the commit messages. Or how long should our explanations be... Just to help people don't feel overwhelmed about it, nothing more than that (and nothing less!). I don't know if this adds anything new to the conversation. Cheers!
