Hi Katherine, On Wed, Aug 23, 2023 at 9:27 AM Katherine Cox-Buday <cox.katherin...@gmail.com> wrote: > > I'm a Mom
Congratulations, and thanks for dedicating your life to someone else! > Savannah closed my account one or two days later due to inactivity. That happened to me too, although it took a couple of weeks. > I can't ever seem to get the GNU style commit messages correct. Neither can I. The style apparently helps with automated maintenance of the changelog, but I do not understand why a changelog is useful for a rolling release model. No one uses Guix releases other than to install. Even then, we encourage folks to run 'guix pull' at their earliest opportunity. > I don't use the email-based patch workflow day-to-day Yeah, I can deal with small inline patches, but Guix requires changes to be split into many tiny commits. Such a series is then submitted with one message per commit. Then people argue in between and submit multiple versions of the commit series to the same bug. I think it requires a lot of practice to work through that. Some email clients, such as aerc, may help. I don't think people are opposed to better tooling. We just don't have it yet. Mumi could be part of the solution. > My script runs `guix style` According to an authoritative source, hitting TAB on a marked region in Emacs is actually the preferred way to format submissions. > "At every step of the contribution process, I must manually check that > multiple things are correct. With limited available executive > functioning, > and no automation, this is very difficult to do correctly, and an > easy place > for contributors to stop." There is an easy medicine: Lose your worries, and don't be afraid! Just send in what you have. For example, I ask my reviewers to adjust commit messages to their liking. > I have given a list of issues to a group of people who are presumably > analytical, and I think the natural inclination is to go point-by-point > and make > arguments for/against. Instead of that[*], I invite you to address the more > abstract issue: (should/how do) we reduce friction for making contributions? Your broader perspective will probably generate a lot of discussion in which people offer many valuable viewpoints, but it will yield no resolution. There is no central authority in Guix, yet people are afraid to step out of line. In the end, everyone just conforms out of habit. > * Contributing to Guix is not for you Guix has a steep learning curve that is not necessarily limited to contributions. The Guile syntax features, which are so popular in Guix, can be difficult to understand even for people who know Scheme. The file system layout, which is brilliant, also takes time to understand. > * It's OK to make lots of mistakes That headline should be on all of Guix's web pages. Peopl focuss on wayy to meny details in al technicl Forums. > * We could support a managed web-based workflow Mumi needs more love. Or, maybe we can co-opt Codeberg or Sourcehut. > * Encourage upstream communities like "Guix 'R Us" Every contributor should have their own channels for packages [1] and for Guix. [2] Testing patches before they are submitted would vastly improve the code quality in Guix. Just fork my repos on Codeberg and use the 'prebuilt' branches. (Also, please tell me when to advance them to more recent commits.) Here is how you use them via Guix Home. [3] > What do you all think? Does this affect anyone else? For now, it's just you and I—unless others speak up. Thanks for your helpful comments! Kind regards Felix [1] https://codeberg.org/lechner/juix [2] https://codeberg.org/lechner/guix [3] https://codeberg.org/lechner/home-config/src/branch/history/service/channels.scm