Hi Katherine,
I haven't had too much time lately in regards of the survey, but hope
I'll be able to commit more time to it throughout the next weeks. Thanks
for reviewing the first rough draft of the questions!
Katherine Cox-Buday writes:
> Does the GNU project have a "general translation" te
Tao Hansen writes:
> Hello, I hope it's ok I'm replying to this email as a follow-up to
> decreasing the cognitive overhead for new users. I'm also brand new to
> the Guix community and ecosystem. I wanted to share a perspective from a
> user on a Lemmy instance who wrote why the Guix ecosystem
Hi,
On Mon, 09 Oct 2023 at 12:29, Katherine Cox-Buday
wrote:
> Is this rough list of questions our first pass at what the survey should
> contain?
>
> Have you done any more research on what other communities are doing?
>
> What are next steps?
Well, from my opinion, since the idea is to send
On 10/2/23 5:24 AM, Wilko Meyer wrote:
- Where solicitations to complete the survey are broadcast is very
important. E.g. if we only send it to guix-dev, this skews the
responses to questions like "where do you talk about Guix".
Definitely, I'm not entirely sure on how to solve this; pub
To counter this point:
> But the present organisation looks defunct. There’s no strong leadership.
A lack of central-ised leadership is a good thing
If this is their only reason for calling the organisation defunct then this
point is invalid however I am unsure if this is where the critique lies
I
Hello, I hope it's ok I'm replying to this email as a follow-up to
decreasing the cognitive overhead for new users. I'm also brand new to
the Guix community and ecosystem. I wanted to share a perspective from a
user on a Lemmy instance who wrote why the Guix ecosystem was not
friendly enough to m
Hi Katherine,
Katherine Cox-Buday writes:
> This is awesome, thanks Wilko!
>
> I've been talking with my wife who is the field of psychology. As part
> of her degree, and as part of her ongoing education, she's studied how
> to design studies/surveys so that they're not biased and don't produc
> 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
On 9/22/23 18:14, Imran Iqbal wrote:
On Sun, Sep 03, 2023 at 05:45:41PM +, Ekaitz Zarraga wrote:
I use protonmail and they don't provide smtp access so I can't do git
send-mail as easy as other people do.
A mail provider not allowing SMTP is a git forge that does not allow git
push.
This
Hi,
> On Sun, Sep 03, 2023 at 05:45:41PM +, Ekaitz Zarraga wrote:
>
> > I use protonmail and they don't provide smtp access so I can't do git
> > send-mail as easy as other people do.
>
>
> A mail provider not allowing SMTP is a git forge that does not allow git
> push.
This is a feeling
Imran Iqbal writes:
> Personally I don't think its fair to ask Guix to move away from emails
> because folks are more familiar with using web browsers for everything.
Imran, you bring up good points. I wanted to state that I share this opinion:
Guix should not move away from emails.
I view thi
On Sun, Sep 03, 2023 at 05:45:41PM +, Ekaitz Zarraga wrote:
> I use protonmail and they don't provide smtp access so I can't do git
> send-mail as easy as other people do.
A mail provider not allowing SMTP is a git forge that does not allow git
push.
> This is not Guix's fault, but it's a prob
This is awesome, thanks Wilko!
I've been talking with my wife who is the field of psychology. As part
of her degree, and as part of her ongoing education, she's studied how
to design studies/surveys so that they're not biased and don't produce
contaminated data. She's not an expert at this, bu
Hi Simon,
Simon Tournier writes:
> I would add the questions as:
>
> + the kind of contributions: patches, translation, bug report,
> discussions on guix-devel or help-guix, else
>
> + the number of contributions using some ranges 1, [2-9], [10-100], 100+
>
> + channels of communication: I
Hi,
Really cool! Thank you.
On Sat, 16 Sep 2023 at 14:59, Wilko Meyer wrote:
> I identified a few key themes that could be useful for a guix user
> survey as well. I plan on doing a more extensive summary on this later
> this weekend if my time allows it, for now a loose collection of
> ideas/
Hi Simon,
On Mon, Sep 18 2023, Simon Tournier wrote:
>
> To be clear, I dismiss only these two sentences:
Having read your message from earlier today [1] in which I think you
questioned the continued utility of this thread ("could we stop this
useless and unproductive flamewar?") it seems fair to
en then, the use of another forge
appears almost incidental at times; our vetting process has similarly
been criticized for its perceived inefficiencies).
Now, I'd like to call back to a point I made earlier:
Am Dienstag, dem 05.09.2023 um 22:43 +0200 schrieb Liliana Marie
Prikler:
> Maybe
s would drag up and
engage potentially fruitful discussions. Maybe, that's what you
wanted to express?
Anyway. That's how I view the things from my perspective.
It is my last email in this thread too.
Cheers,
simon
1: Re: How can we decrease the cognitive overhead for contributors?
MS
On 9/18/23 20:13, Simon Tournier wrote:
On Mon, 18 Sept 2023 at 18:35, MSavoritias wrote:
I was talking from my experience. If you don't share it that is fine.
Share what? Your experience? How can I? Instead, I share facts
backed by numbers.
It is fine to share how you perceive, encoura
On Mon, 18 Sept 2023 at 18:35, MSavoritias wrote:
> I was talking from my experience. If you don't share it that is fine.
Share what? Your experience? How can I? Instead, I share facts
backed by numbers.
It is fine to share how you perceive, encouraged even! It is not fine
to make bold clai
On 9/14/23 11:24, Ricardo Wurmus wrote:
Fannys writes:
But again, even if this is a great option for you, it might be a really bad
option for some other people. Everybody does not have the time to spend
learning emacs, or other specific tool. It's ok if the workflow suggests that
but it's no
left behind (?) and wanting to
prove that email is better or something. Personally i don't care what is
better.
What i care is that some people prefer web-based so we should
accommodate them :) plain and simple.
MSavoritias
Cheers,
simon
1: Re: How can we decrease the cognitive ov
Hi,
On Sun, 17 Sep 2023 at 14:29, MSavoritias wrote:
> The reason I have come to guix is because it strives to actually make it
> easier for people to change things. with guix shell and such. So making
> it easier for people to contribute is absolutely a part of it. Im not
> saying we should
some stats; e.g., [4]. In summary,
“email vs. web-forge” is a fake-problem, IMHO. Last, the talk [5] by
Enrico Zini appears to me much more fruitful. The question is about
sustain the community. And this sustainability does not clearly depend
on any tool.
Cheers,
simon
1: Re: How can w
Wilko Meyer writes:
> Hi Guix,
>
> I haven't had enough time to read up on every topic that has been
> mentioned in the "How can we decrease the cognitive overhead for
> contributors?" discussion as at some point it got quite a lot to
> follow. At one point[0]
this.
MSavoritias
On 9/16/23 15:59, Wilko Meyer wrote:
Hi Guix,
I haven't had enough time to read up on every topic that has been
mentioned in the "How can we decrease the cognitive overhead for
contributors?" discussion as at some point it got quite a lot to
follow. At one poi
Am Sonntag, dem 17.09.2023 um 19:20 +0300 schrieb MSavoritias:
> Personally free software means that there shouldn't even be a
> separation of Dev and user. But that's another topic.
I mean, the pull request model has this separation baked into it. To
create a pull request, you must have an accoun
On 9/10/23 01:20, Liliana Marie Prikler wrote:
Am Samstag, dem 09.09.2023 um 21:40 +0200 schrieb Ricardo Wurmus:
Liliana Marie Prikler writes:
Must we force a single workflow on everyone, even if our track
record in reviewing and merging doesn’t clearly show that our way
is superior?
Again
On 9/8/23 21:50, Liliana Marie Prikler wrote:
Hi,
Am Freitag, dem 08.09.2023 um 16:44 +0200 schrieb Ricardo Wurmus:
I often have to review Github Pull Requests, and I don’t go commit by
commit by go through the diff and annotate the changes. I *read* the
commits to get a sense for how the fe
On 9/12/23 17:51, Maxim Cournoyer wrote:
Hi,
Csepp writes:
Giovanni Biscuolo writes:
[[PGP Signed Part:Undecided]]
Hello Csepp,
Csepp writes:
[...]
I don't think repeating that no forge sucks less advances the
conversation towards any solution other than keeping the status quo,
whic
On 9/13/23 18:42, Maxim Cournoyer wrote:
Hi Fannys,
Fannys writes:
Ekaitz Zarraga writes:
This is what I mean when I say many times emacs is kind of mandatory,
and
this thread is kind of a demonstration of what I meant because the main
discussion evolved to: you can use this or that in e
gainst the
ChangeLog style, especially when they come in combination with a
refusal to make use of already provided tools. I think we're starting
to see the moving of the goal post as the actual game here.
Maybe it's time to take a step back and instead of asking “How can we
decre
h a
refusal to make use of already provided tools. I think we're starting
to see the moving of the goal post as the actual game here.
Maybe it's time to take a step back and instead of asking “How can we
decrease the cognitive overhead for contributors?”, we should perhaps
ask “For which c
Hi Guix,
I haven't had enough time to read up on every topic that has been
mentioned in the "How can we decrease the cognitive overhead for
contributors?" discussion as at some point it got quite a lot to
follow. At one point[0] there was a discussion on having a survey to get
a be
Hi,
On Thu, 14 Sep 2023 at 23:19, Sarthak Shah wrote:
> I believe that it should not be very hard to create a user interface (web,
> ncurses or GUI) that searches for a package's location (the package record
> has a field that accommodates this) and then displays it, which the user
> can then ed
I think that quite a few Guix users end up not committing to Guix because
of how daunting and strange the process seems.
In particular, having an alternate, easy-to-use interface for updating
package definitions specifically could be very useful.
The greatest strength of Guix is that it can be ver
Fannys writes:
>> But again, even if this is a great option for you, it might be a really bad
>> option for some other people. Everybody does not have the time to spend
>> learning emacs, or other specific tool. It's ok if the workflow suggests that
>> but it's not great if we have no other alt
MSavoritias writes:
> Simon Tournier writes:
>
>> Hi,
>>
>> On Tue, 29 Aug 2023 at 12:53, MSavoritias wrote:
>>
>>> Do you know if there are any plans to write a scheme bug/patching
>>> system? Because looking a bit into it, it doesn't seem like its that
>>> actively developed so maybe we wou
Hi,
On Wednesday, September 13th, 2023 at 3:42 PM, Maxim Cournoyer
wrote:
>
> There's no lock-in. You can use any tool you want. Most people hacking
> on Guix do so with Emacs and Geiser because these are currently the best
> tools (that I know of) to do the job; these are the tools many of us
Hi Fannys,
Fannys writes:
> Ekaitz Zarraga writes:
>
>>> > This is what I mean when I say many times emacs is kind of mandatory,
>>> > and
>>> > this thread is kind of a demonstration of what I meant because the main
>>> > discussion evolved to: you can use this or that in emacs to ease the
>>>
is about Python build system improvements
> that I am necessary following. However, if I see the subject,
>
> guix: toml: Add TOML parser.
>
> then I open the message and read it.
>
> Therefore, I do not see any “good” solution for this point #22. One
> idea would be t
I dont think we need to compare things here. Of course we should be able
to make lives easier for reviewers and contributors. There is no need
here to compare them. Remember that making lives easier for contributors
will make lives easier for reviewers too after all :) Because more
correct pathce
Simon Tournier writes:
> Hi,
>
> On Tue, 29 Aug 2023 at 12:53, MSavoritias wrote:
>
>> Do you know if there are any plans to write a scheme bug/patching
>> system? Because looking a bit into it, it doesn't seem like its that
>> actively developed so maybe we would be better served by one in sc
Ekaitz Zarraga writes:
>> > This is what I mean when I say many times emacs is kind of mandatory,
>> > and
>> > this thread is kind of a demonstration of what I meant because the main
>> > discussion evolved to: you can use this or that in emacs to ease the
>> > dev
>> > experience.
>>
>>
>>
Ekaitz Zarraga writes:
>> > This is what I mean when I say many times emacs is kind of mandatory,
>> > and
>> > this thread is kind of a demonstration of what I meant because the main
>> > discussion evolved to: you can use this or that in emacs to ease the
>> > dev
>> > experience.
>>
>>
>>
Hi Ricardo,
Ricardo Wurmus writes:
> Giovanni Biscuolo writes:
>
>> AFAIU mumi does not (still?) have ad authentication/authorization,
>> right?
>>
>> If so how do you plan to deal with users posting SPAM or similar
>> unappropriate content?
>
> It only sends email on behalf of commenters, so w
Re,
On Wed, 13 Sep 2023 at 09:57, Simon Tournier wrote:
> Somehow, the line is drawn using a two-axis plot of “easy vs boring”
> when instead we should draw a two-axis plot of “complexity vs capture
> the values”.
I meant, the thread is considering a one-axis plot using a subjective
parameter f
Giovanni Biscuolo writes:
> AFAIU mumi does not (still?) have ad authentication/authorization,
> right?
>
> If so how do you plan to deal with users posting SPAM or similar
> unappropriate content?
It only sends email on behalf of commenters, so we’re using the same
email mechanism to deal wit
Hi Katherine,
On Tue, 12 Sep 2023 at 10:05, Katherine Cox-Buday
wrote:
> And these are subjective statements, which are bad to rest decisions on.
> I have the opinion that this style of commit message is difficult and
> doesn't have a lot of value; others think it's easy and find a lot of
>
re drifting. :-)
This branch of the long thread starts with:
Re: How can we decrease the cognitive overhead for contributors?
Attila Lendvai
Fri, 25 Aug 2023 08:07:53 +
id:JRUs8LVm3AtAh0MnHjE5rnhB4sNET0vWTOO2N3w2KfvKoM3CALRNwHTmwJ0Y9Bg3ZDWCs8j-1bMCo9aRiaoac
On 9/8/23 2:37 PM, Ricardo Wurmus wrote:
Liliana Marie Prikler writes:
Am Freitag, dem 08.09.2023 um 17:27 +0200 schrieb Ricardo Wurmus:
I have the same positive view on our faux ChangeLogs commit messages,
though I also would like to have them generated. The benefit is
still there: I still
On 9/8/23 5:28 AM, Ricardo Wurmus wrote:
Katherine, I’m very happy you brought this up and continue to respond in
this thread to clarify and steer the discussion into a fruitful
direction. I know I couldn’t do it. I thank you for this work, and I
hope that the project can come up with ways to
On 9/8/23 6:40 AM, Giovanni Biscuolo wrote:
Ricardo,
Ricardo Wurmus writes:
Giovanni,
You are obviously free not to contribute your patches upstream but the
fact that you decided not to because it's "too hard" (my executive
summary about your complaints about Change Log content rules) to wr
On 9/11/23 6:19 AM, Giovanni Biscuolo wrote:
If you want I can add a little bit of Italian attitide at discussing in
detail tiny variations of the same thing :-O... just joking, eh! ;-)
One of the reasons I love working with people from around the world is
the delight in discovering that desp
Hello Ricardo,
Ricardo Wurmus writes:
> Giovanni Biscuolo writes:
>
>> […] actually Debbugs or Mumi web interfaces are read-only: you cannot
>> open a bug report or comment it, you have to send an email; this is a
>> _feature_, not a bug since we don't need a _complex_ web based
>> authenticati
Hi,
Csepp writes:
> Giovanni Biscuolo writes:
>
>> [[PGP Signed Part:Undecided]]
>> Hello Csepp,
>>
>> Csepp writes:
>>
>> [...]
>>
>>> I don't think repeating that no forge sucks less advances the
>>> conversation towards any solution other than keeping the status quo,
>>> which can't really
Hi Simon,
Simon Tournier writes:
> Hi Liliana,
>
> On Mon, 11 Sep 2023 at 19:53, Liliana Marie Prikler
> wrote:
>
>> For "patch does not apply", the forge solution is typically to send a
>> notification to the issuer.
>
> No, that does not match my small experience. Because often the issuer
>
Giovanni Biscuolo writes:
> [[PGP Signed Part:Undecided]]
> Hello Csepp,
>
> Csepp writes:
>
> [...]
>
>> I don't think repeating that no forge sucks less advances the
>> conversation towards any solution other than keeping the status quo,
>> which can't really be called a solution.
>
> Are w
Hello Csepp,
Csepp writes:
[...]
> I don't think repeating that no forge sucks less advances the
> conversation towards any solution other than keeping the status quo,
> which can't really be called a solution.
Are we really talking about changing the official Guix forge:
https://savannah.gnu
Giovanni Biscuolo writes:
> [[PGP Signed Part:Undecided]]
> Hi Liliana,
>
> Liliana Marie Prikler writes:
>
> [...]
>
>> For example, whenever people say that "forges would improve stuff", my
>> reply is (modulo phrasing) "yes, for the people who are already used to
>> forges".
>
> I just want
rkflow is far to help us for
having smooth reviews so it’s hard to convince folks already familiar
with other workflows to adopt our. Not saying that these other
workflows are better either.
Cheers,
simon
1: Re: How can we decrease the cognitive overhead for contributors?
Ricardo Wurmus
Fri, 0
Hi Simon,
Am Montag, dem 11.09.2023 um 12:36 +0200 schrieb Simon Tournier:
> Today, the review and commit process have many steps, more or less
> simple, not all sure!, well at the end, we have something complex.
>
> One trivial step is to apply the patch (or series) to your local
> checkout and
Hi Liliana,
Liliana Marie Prikler writes:
[...]
> For example, whenever people say that "forges would improve stuff", my
> reply is (modulo phrasing) "yes, for the people who are already used to
> forges".
I just want to point out that actually Guix _do_have_ a forge. the
software is Savane an
Hello,
(I find it difficult to efficiently follow this thread and to keep up to
date with reading it, so please forgive me if someone else already
addressed my considerations)
Simon Tournier writes:
[...]
> « For which contributors do we want to/can we decrease the cognitive
> overhead? », so
Hi Liliana,
On Sun, 10 Sep 2023 at 00:20, Liliana Marie Prikler
wrote:
>> > > Must we force a single workflow on everyone, even if our track
>> > > record in reviewing and merging doesn’t clearly show that our way
>> > > is superior
>> >
>> > Again, define superior.
>>
>> No, I won’t. I think
Hi Efraim,
Efraim Flashner writes:
[...]
> On the other hand, if we do manage to automate writing of commit
> messages, it makes one less thing for committers to manually fix before
> pushing the commit.
It would be lovely! It could also be done by a client-side git hook,
provided in the Guix
On Fri, Sep 08, 2023 at 04:20:30PM +0200, Ricardo Wurmus wrote:
>
> Josselin Poiret writes:
>
> > Regarding the “mom argument”, I would disagree and say that this is
> > completely related: interruptions are more costly, you're more likely to
> > have less attention span, and overall you probabl
Am Samstag, dem 09.09.2023 um 21:40 +0200 schrieb Ricardo Wurmus:
>
> Liliana Marie Prikler writes:
>
> > > Must we force a single workflow on everyone, even if our track
> > > record in reviewing and merging doesn’t clearly show that our way
> > > is superior?
> > Again, define superior.
>
> N
Simon Tournier writes:
> On Fri, 08 Sep 2023 at 17:27, Ricardo Wurmus wrote:
>
>> Now, this is no longer a problem for me because I’ve been writing so
>> many commit messages over the years (and because I no longer try to
>> adhere to some poorly specified format), but it *is* a problem for
>>
Liliana Marie Prikler writes:
>> Must we force a single workflow on everyone, even if our track record
>> in reviewing and merging doesn’t clearly show that our way is
>> superior?
> Again, define superior.
No, I won’t. I think it’s obvious that our review process isn’t working
*well*. So th
Am Donnerstag, dem 07.09.2023 um 14:39 -0600 schrieb Katherine Cox-
Buday:
> > Somehow, that’s the remark by Liliana [1],
> >
> > Maybe it's time to take a step back and instead of asking
> > “How can we decrease the cognitive overhead for
> >
d submitting for example – and it brings no
value at all for the project. Other, as commit message format, also
leads to some friction but it also brings value for the project.
For these latter case, the improvement is not clear for me.
Cheers,
simon
1: Re: How can we decrease the cognitive
Hi Katherine,
On Thu, 07 Sep 2023 at 14:39, Katherine Cox-Buday
wrote:
>> Maybe it's time to take a step back and instead of asking “How can
>> we
>> decrease the cognitive overhead for contributors?”, we should
>> perhaps
>>
Am Freitag, dem 08.09.2023 um 22:24 +0200 schrieb Ricardo Wurmus:
>
> Liliana Marie Prikler writes:
>
> > > On Github, Pull Request branches are like our WIP branches. They
> > > are how we arrive at acceptable changes. Picky people like me
> > > would then go back and write new atomic commits
Am Freitag, dem 08.09.2023 um 17:39 +0200 schrieb Ricardo Wurmus:
>
> Liliana Marie Prikler writes:
>
> > To be completely honest, mumi recalling everything at 0 precision
> > is my biggest pet peeve at the moment
>
> Can you please make a test case for this and add it to the mumi
> tests? We
Liliana Marie Prikler writes:
> Am Freitag, dem 08.09.2023 um 17:27 +0200 schrieb Ricardo Wurmus:
>> I have the same positive view on our faux ChangeLogs commit messages,
>> though I also would like to have them generated. The benefit is
>> still there: I still get to *review* an effective sum
Liliana Marie Prikler writes:
>> On Github, Pull Request branches are like our WIP branches. They are
>> how we arrive at acceptable changes. Picky people like me would then
>> go back and write new atomic commits for the effective diff, but in
>> my role as a reviewer I usually rebase, squas
Am Freitag, dem 08.09.2023 um 17:27 +0200 schrieb Ricardo Wurmus:
> I have the same positive view on our faux ChangeLogs commit messages,
> though I also would like to have them generated. The benefit is
> still there: I still get to *review* an effective summary of the
> changes before pushing or
Hi,
Am Freitag, dem 08.09.2023 um 16:44 +0200 schrieb Ricardo Wurmus:
> I often have to review Github Pull Requests, and I don’t go commit by
> commit by go through the diff and annotate the changes. I *read* the
> commits to get a sense for how the feature evolved and why changes
> were made, bu
Am Freitag, dem 08.09.2023 um 11:16 +0200 schrieb Giovanni Biscuolo:
> [...]
>
> > > On 2023-09-06, Liliana Marie Prikler wrote:
>
> [...]
>
> > > > It's
> > > >
> > > > * file (variable)[field]{do you need 4
> > > > levels?}
>
> The general form of a ChangeLog Style format for Guix code (Gui
Hello Efraim,
Efraim Flashner writes:
> On Fri, Sep 08, 2023 at 11:53:43AM +0200, Giovanni Biscuolo wrote:
> That wasn't my read of it at all.
I don't understand what part of my message is different from your read,
so I cannot comment
> I too have many packages which I haven't upstreamed.
[..
Giovanni Biscuolo writes:
> […] actually Debbugs or Mumi web
> interfaces are read-only: you cannot open a bug report or comment it,
> you have to send an email; this is a _feature_, not a bug since we don't
> need a _complex_ web based authentication+authorization system for bug
> reporters/co
Liliana Marie Prikler writes:
> To be completely honest, mumi recalling everything at 0 precision is my
> biggest pet peeve at the moment
Can you please make a test case for this and add it to the mumi tests?
We have tests for the search feature there.
--
Ricardo
Maxim Cournoyer writes:
> I used to think the same about ChangeLogs style commit messages, but I
> have to admit that it forces some discipline on me by having me review
> my changes in details and write out what I did. It'll sometimes expose
> something that'd be better kept in a separate com
Liliana Marie Prikler writes:
>> one fundamental issue with the email based workflow is that its
>> underlying data model simply does not formally encode enough
>> information to be able to implement a slick workflow and frontend.
>> e.g. with a PR based model the obsolete versions of a PR is h
Josselin Poiret writes:
> Regarding the “mom argument”, I would disagree and say that this is
> completely related: interruptions are more costly, you're more likely to
> have less attention span, and overall you probably don't want to commit
> to 20 steps just to send a contribution.
That’s e
Ricardo,
Ricardo Wurmus writes:
> Giovanni,
>
>> You are obviously free not to contribute your patches upstream but the
>> fact that you decided not to because it's "too hard" (my executive
>> summary about your complaints about Change Log content rules) to write
>> commit messages suitable for
On Fri, Sep 08, 2023 at 11:53:43AM +0200, Giovanni Biscuolo wrote:
> Hello Katherine,
>
> Katherine Cox-Buday writes:
>
> [...]
>
> > By "standard" I mean the GNU Changelog format
> > (https://www.gnu.org/prep/standards/standards.html#Change-Logs). As
> > in: it's expected that commit messages
Giovanni,
> You are obviously free not to contribute your patches upstream but the
> fact that you decided not to because it's "too hard" (my executive
> summary about your complaints about Change Log content rules) to write
> commit messages suitable for contribution it _not_ a Guix maintainers
Hi!
Simon Tournier writes:
[...]
> For example, we communicate in English. It appears to me impossible to
> send a contribution without having some basic knowledge of English.
And, believe me or not, for me /that/ is a **significant** cognitive
overhead not just to contribute to international
Hello Katherine,
Katherine Cox-Buday writes:
[...]
> By "standard" I mean the GNU Changelog format
> (https://www.gnu.org/prep/standards/standards.html#Change-Logs). As
> in: it's expected that commit messages use this format.
[...]
> In my response I was trying to point out a flaw in your co
Hi all!
I think the discussion about ChangeLog Style shows we probably need to:
1. enhance the manual section "22.6 Submitting Patches"
https://guix.gnu.org/en/manual/devel/en/html_node/Submitting-Patches.html
--8<---cut here---start->8---
Please write commit
Simon Tournier writes:
> Since I am French and it is easier for me to comment about my
> disagreements than the converse. ;-)
Feels like literally every national group makes this up about
themselves; British people are stereotypically very prone to
complaining, too :P
-- (
Hi Katherine,
Hi Liliana,
On Thu, Sep 7, 2023 at 1:39 PM Katherine Cox-Buday
wrote:
>
> Liliana, many of your responses in this thread are not OK.
Thank you for your candor! I also sensed some negativity in that
interaction. Both of you, please feel free to direct your comments to
me—privately i
ead of asking “How can we
decrease the cognitive overhead for contributors?”, we should perhaps
ask “For which contributors do we want to/can we decrease the cognitive
overhead?”
That's interesting, because I view this as the antithesis of what Rich
was trying to
come in combination with a
refusal to make use of already provided tools. I think we're starting
to see the moving of the goal post as the actual game here.
Maybe it's time to take a step back and instead of asking “How can we
decrease the cognitive overhead for contributors?”, we
Hello,
On 2023-09-06 04:49, Maxim Cournoyer wrote:
Hi Katherine,
Katherine Cox-Buday writes:
On 9/5/23 10:01 AM, Simon Tournier wrote:
Well, somehow, I consider the commit message format similarly as
coding
style. We can discuss which one is better than the other when at the
end it only
really make that great of an argument against the
> ChangeLog style, especially when they come in combination with a
> refusal to make use of already provided tools. I think we're starting
> to see the moving of the goal post as the actual game here.
>
> Maybe it's time t
Am Mittwoch, dem 06.09.2023 um 10:52 -0700 schrieb Vagrant Cascadian:
> I always get tripped up with phases, modify-phases, etc. as there
> seem to be potentially four or more levels deep in some common code
> patterns... for example, a recent commit mentioning phases:
>
> commit c14c25b4fb625c2a5
Maxim Cournoyer writes:
> Hi Vagrant,
>
> Vagrant Cascadian writes:
>
>> On 2023-09-06, Liliana Marie Prikler wrote:
>>> Am Dienstag, dem 05.09.2023 um 19:41 -0400 schrieb brian
‘* foo/bar.scm new-package (inputs): add input’
stuff. I literally can never remember this format, no
1 - 100 of 252 matches
Mail list logo
