New section to easily reference Debbugs URLs within Emacs Debbugs

[Maxim Cournoyer]

Hello,

If you use Emacs and Emacs-Debbugs, you may be interested in applying
the settings newly documented in the 'Viewing Bugs within Emacs' section
of the manual; see it at the bottom of info "(guix) The Perfect Setup").

I hope that's useful,

-- 
Thanks,
Maxim

Re: Guix Survey (follow up on "How can we decrease the cognitive overhead for contributors?")

[MSavoritias]

Sounds like a great idea!

I agree that exclusivity and how we can improve contribution should be 
included.


Also communication channels of course. Maybe also what communication 
channels people would like to see?



Just thinking out loud for questions. I would also be glad to be of help 
with 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 point[0] there was a discussion on having a survey to get
a better picture on and quantify what potential blockers are to engage
with/contribute to Guix; which seems, if done right (as surveys have to
be carefully crafted), a good idea; especially with the prospect of
repeating it annually as a means to check if issues got
better/priorities in Guixes userbase change and so on. If there's a
consensus on doing this, I'd be happy to contribute some of my time to
get things going (would creating a issue on guixes bug tracker for this
topic be a good idea? how are these non-code contrib. topics handled?).

Before writing this mail, I had a look on how other projects handle
these kind of surveys, in particular:

- the emacs user survey[1]
- the nix community survey[2]
- the curl user survey[3]
- the fennel survey[4]

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/list of what, in my subjective opinion, stood out and what most
surveys had in common should do to hopefully get a discussion on this
started:

- the emacs user survey specifically asked for elisp profiency; mapping
   out the Guile profiency of guixes community could be feasible.
- fennel as well as emacs had questions on which programming languages
   their community uses; in the regards on recent discussions on
   guix-devel on developer ecosystems[4] this could help to identify if
   there are any shortcomings in providing importers/packages for certain
   languages that may be used by guix users.
- the nix survey specifically asked for the environments and context nix
   is being used in; it'd be interesting to see where and for what
   purpose people are using Guix.
- most surveys had, some more some less extensive, demographic
   questions and questions mapping out how many years people have been
   programming.

Specifially in the lights of the original discussion/regarding
contributions:

- I think that the "Where do you discuss Fennel or interact with other
   Fennel developers" question of fennels survey should be asked for guix
   as well, to get a grasp on which platforms are being used to discuss
   all things guix.
- the curl user survey[6] did a pretty good job in mapping out what
   prevents users from contributing (p.20) as well as mapping out what
   areas of the project are regarding as good/which have room for
   improvements (p.24-26)
- fennel asked for "the biggest problems you have using Fennel", it had
   a "If you haven't hacked on Fennel itself, why not?" question as
   well. I personally think this could be good to assess potential pain
   points/blockers for Guix as well. Fennel also asked for "favorite
   features" which could be a nice way to map out which parts of Guix are
   popular.

Last, the nix user survey allowed free-form responses. Having a
qualitative research component to a survey could help getting better
results (especially when identifying problems in using guix/blockers in
contributing and so on); but evaluating these is pretty time extensive
and dependant on how much resources people have to compile a list of
findings/results from a prospective survey.

What could the next steps be to get this going?

[0]: https://lists.gnu.org/archive/html/guix-devel/2023-09/msg00086.html
[1]: https://emacssurvey.org/
[2]: https://discourse.nixos.org/t/2022-nix-survey-results/18983
[3]: https://daniel.haxx.se/blog/2022/06/16/curl-user-survey-2022-analysis/
[4]: https://fennel-lang.org/survey/2022
[5]: https://lists.gnu.org/archive/html/guix-devel/2023-07/msg00152.html
[6]: https://daniel.haxx.se/media/curl-user-survey-2023-analysis.pdf

Re: How can we decrease the cognitive overhead for contributors?

[Liliana Marie Prikler]

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 account on the platform that
the project chooses to host its source on, fork it, and push your own
fork with whatever changes you have for the world to see, thereby
marking you a "developer", whatever that means.  To write an email, you
simply overcome your crippling social anxiety and write an email. 
Indeed, that's still a hard thing to do on its own, but the separation
of developers and users is not a thing you have to think about here.

Cheers

Re: How can we decrease the cognitive overhead for contributors?

[MSavoritias]

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, define superior.

No, I won’t.  I think it’s obvious that our review process isn’t
working *well*.  So the argument that our current workflow allows for
effective review is dubious.  Not saying that you made that claim,
just that it’s hard to convince others of adopting our ways when the
results just aren’t great.

What do you consider "the results" here?  The rate at which patches are
merged?  This is hardly an issue our project alone is fighting and I'm
not convinced that technology, more or less, will shift it in either
direction.


That's one thing yeah.

There are multiple people in the thread pointing out issues with 
contributing that create friction.


Including an committer. And the fact that guix doesn't get have many 
committers and contributors are scarce, speaks for itself. If you don't 
see it I suggest asking people in social networks/forums why they 
*don't* get involved in guix.



Let's take our importers as an example.  Bugs aside, they allow us to
bump any package to the newest released version.  Naturally, similar
tools have evolved over in the forge world as well.  The end result?
Bots are now writing merge request that end up ignored much like there
are bugs in Guix that receive little attention due to what might as
well be unfortunate timing.

I'm also not sure how we can tie back contribution throughput to
cognitive overhead.  In fact, there might well be a Jevons paradox
hiding somewhere in that less overhead per patch means that more
patches can be written, which results in the same overall cognitive
overhead in the long run.

Now, you are probably right in that our review process probably isn't
working well for some value of well that yet needs to be defined.
However, without any frame of reference it is also a statement that can
neither be verified nor falsified.  I could be sitting in a burning
house claiming "this is fine" or sitting in the finest restaurant
claiming "this place sucks" and since you can't see me, there's no way
for you to infer that I'm a cat.

Cheers

Frame of reference should be what other projects have done. Its not like 
this hasn't come up before in other projects.


For example Debian moved to Gitlab. Same for gnome and kde.

I'm not saying we should copy them but we should at least ask "Why?" and 
how did they come to those conclusions.


Then we should also do a survey of people outside of guix that may be 
interested in it. What stops you from doing so? (spoiler: its the email 
among other problems :) )



Personally free software means that there shouldn't even be a separation 
of Dev and user. But that's another topic.

Re: How can we decrease the cognitive overhead for contributors?

[MSavoritias]

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 feature evolved and why changes
were made, but the fact that new commits are pushed on top of the
branch is not an obstacle in practice, because the commits don’t
matter.

(I know, it hurts me too, but I don’t make the rules, okay?)

Well, thanks to Guix inventing the time machine, individual commits do
matter to us.


And in these review interfaces we can mark individual comments as
resolved.  So the flat list of changes with annotations *does* in
fact provide a clearer organization than a tree of emails.

Note also that we don’t usually review commits by starting one new
thread for each issue we address, so we don’t benefit from automatic
branching of sub-discussions.

To be fair, the summarizing of changes followed by comments to
individual bits are a point that the forges at least get right.
However, unless you rework a single line multiple times – which
admittedly happens more often in the "push the change on top" model of
the forges than in the "condense your changes to logical units" model
we use – a branching discussion per commit still comes quite close in
practice.  Also, when there are multiple reviewers notice different
things, you also get the branching tree.


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, squash, and merge.

This workflow is more familiar to some and alienating to others, but
both of these workflows would work fine for Guix.  But today our
tools can only accommodate *one* workflow.

I'd imagine that rebase, squash and merge would exacerbate the workload
on the committer side and I think that most popular projects on those
forges already experience similar effects to us despite folks just
merging the requests as-is and in part even getting paid by big tech
for doing so.  (Perhaps I exaggerate at getting paid for processing
merge requests, I haven't worked for any of these companies, but
especially at the ones more oriented towards doing business, I'd
imagine that you can at least buy yourself a sandwich from the work you
do from time to time.)


It happens to be the one I’m used to, but let’s please not pretend
that it’s inherently *better* than the other.

I mean, when we say better, we would have to refer to some metric of
goodness.  And the metric I personally choose is somewhere in the
intersection of accessibility and interoperability, because that is
what matters to me.  With Github, Gitlab and whatever other forges you
have, you are more or less bound to their web interface.  If that works
for you, it works.  If it doesn't, it doesn't.  With the email-based
workflow, I can use whichever tools I am comfortable with, as long as
they work for sending mail (as a contributor) or eventually invoke `git
push' on a bunch of signed-off commits (as a committer).  This both
increases the chances of things working and gives me the tools to build
things that work for myself (and potentially others as well).

Cheers


That's the thing though, its not more accessible.

For multiple reasons including:

- knowledge accessibility

- accessibility for people with disabilities

- accessibility for people that don't have the time

and so on.


So the argument for accessibility is very much wrong. Now if you want to 
argue that its better for


some people because they can tweak their Emacs, sure I agree. I am one 
of those people.



But the web and html has orders of magnitude better accessibility than 
anything email. as a medium.


I mean we don't even have much accessibility to speak of in guix but 
that's another topic.



MSavoritias

Guix Days and Fosdem 2024

[Manolis Ragkousis]

Hello everyone,

It's that time of the year again. We should start preparing for the Guix 
Days 2024 and a Declarative and Minimalistic Computing devroom proposal.


I have created the pages at [1] devroom proposal and [2] Guix days. I 
copy pasted the text from last year and updated the year.


We need to update the topic and possible talks, decide on who to honor 
in the devroom, etc.


Please update the pages with any input you have or ping us.

Looking forward to seeing you all again soon!

Manolis and Pjotr


[1] https://libreplanet.org/wiki/FOSDEM2024-devroom-proposal
[2] https://libreplanet.org/wiki/Group:Guix/FOSDEM2024

Re: Can we provide another UI for patches than just email ?

[Simon Tournier]

Hi Liliana,

On Sun, 17 Sep 2023 at 00:19, Liliana Marie Prikler  
wrote:

> Am Donnerstag, dem 14.09.2023 um 19:48 +0200 schrieb Simon Tournier:

>> a.  … send an Email to guix-patc...@gnu.org #only once
>> b.  $ git config sendemail.to 12...@debbugs.gnu.org #only once
>> c.  $ git send-email --base=auto -v  origin
>> 
>> and the order is flipped:
>> 
>>     a == 3   #only once
>>     b == 1   #only once
>>     c == 2
>
> I mean, the real benefit of git send-email is that these three steps
> compress into a single one if you have a series that consists of a
> single patch.  In fact, mumi send-email already implements this
> workflow in a somewhat clunky way that works, but it requires the use
> of yet another tool that isn't well known outside of Guix (at least
> with git send-email you can point at how kernel devs do stuff).

I agree.  My explanations was trying to make clear, side by side, the
difference and similitude between the two main ways people are
exchanging code.  For sure, the PR model would be “inefficient” for the
“one single patch contribution” case.  If one would speak on the
concrete, one should do some stats about the number of patches per
contribution. ;-)

> Maybe we should actually fix that debbugs bug

IMHO, the issue is that Debbugs is out of the Guix project control but
run and administered by GNU folks (maintaining Savannah etc.).  Even, I
am not sure the exact version of Debbugs which is currently running is
publicly known; the current Debbugs version of the GNU instance diverged
from the Debian versions.

Last, I agree with the rest of your message. :-)

Cheers,
simon

Re: How can we decrease the cognitive overhead for contributors?

[MSavoritias]

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,
which can't really be called a solution.

Are we really talking about changing the official Guix forge:
https://savannah.gnu.org/projects/guix?

I definitely am.

The real place to put efforts toward that goal should be in the GNU
project; this way we can continue to maintain shared resource, knowledge
and tooling as a project.  I think packaging either sourcehut or gitea
and writing a Guix System service for it would provide opportunities to
experiment and perhaps one day move in that direction, so that's
something concrete that you can direct your efforts too.

Agreed. and speaking of that it seems its already something in the works 
as it was pointed elsewhere:


(as trial at least.)

sourcehut.gnu.org

sourcehut.gnu.org hub <#>

🔗 https://sourcehut.gnu.org/ 

Re: How can we decrease the cognitive overhead for contributors?

[MSavoritias]

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 emacs to ease the
dev
experience.


One of the benefits of my being able to attend Guix Days was seeing
peoples' workflows and stacks in person.

As such, one of my conclusions having (already) committed to Guix was
that I needed to master Emacs prior to Guile
(Im highly flow orientated).

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 alternative.

It's not accessible and imposes a barrier in some people.

Yeah agreed. And we should be consious of that.
Ironically by mandating Emacs and Email we force people to use specific
tools while at the same time even though the same people will complain(!) 
against vendor lock-in
like github.

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
know and can easily recommend.  If Visual Code (or editor X) was
packaged in Guix and had great support for working with Guile, we could
also mention it in our manual or in the cookbook.

Notice I use recommend rather than mandate; these are just
recommendations that try to be helpful.  If it's not helpful to you, you
are free to select your own tool box and share how it works (via patches
to the contributing section or a blog post for example).


There are two problems here though. Let me elaborate:

1. The "recommendations": (This is just an example)

I am a new person wanting to get involved or just tweak my config in 
guix/guile.


I go to the manual to learn package management, 
https://guix.gnu.org/en/manual/devel/en/guix.html#Package-Management


Apparently i have to either use the terminal or something called emacs. 
If I follow the guide located here: 
https://emacs-guix.gitlab.io/website/manual/latest/emacs-guix.html#Installation


It says to install emacs-guix. Okay. So apparently it is an Emacs thing, 
whatever that means. And when you start Emacs after installing the 
package, you are going to end up with Emacs in its plain form. 
Unfamiliar keybindings, no autocomplete, etc. Well thats no to Emacs 
then. The other thing is the terminal apparently. Horrible, but at least 
it works.


So what if I want to mess around with guile and the guix config directly?

If we check here it says to use something called Emacs again. So Im 
guessing its the same Emacs that was also apparent in the previous step 
with the config. but not there are more tools.


2. The contribute yourself your tools.

My point with all this is not to say its your fault or really anybody 
specific. Its more to say that:


Recommendations in an abstract sense work fine. But not in the real 
world. You proposed:


> If it's not helpful to you, you are free to select your own tool box 
and share how it works (via patches to the contributing section or a 
blog post for example). are free to select your own tool box and share 
how it works (via patches to the contributing section or a blog post for 
example).


How many people actually have the time and energy and know-how to do 
this? In the original email it was about a mother who on her spare time 
contributes to guix. Or as another example it could be about a person 
that just starts programming. Or it could be about a person that works 
and has few spare time.


Of course I saw in an email earlier in the thread that: "If you don't 
have time (as I do) then don't contribute." Which at the very least i 
find gross and not at all what guix is about.


Guix is supposed to be about equity. We are not all privileged (not 
saying you are or anybody else in this thread is.) enough to have the 
time and knowledge to learn Emacs, git-mail, find an email client that 
works (still havent found one. previous email was with the wrong email 
and threads are a nightmare.), and set up geiser and such.


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 force every volunteer of course to do "work". What I am 
saying is:


- Guix recommendations in the manual, in the cookbook and other places, 
carry weight. In the sense that if to use something else than Emacs i 
have to write my own scripts or go to some random tutorial in a search 
engine then we have effectively pushed Emacs as the main guix platform. 
For better or worse. And we have excluded a portion of contribu

Re: How can we decrease the cognitive overhead for contributors?

[MSavoritias]

On 9/7/23 23:38, Katherine Cox-Buday wrote:

On 9/5/23 2:43 PM, Liliana Marie Prikler wrote:

Am Dienstag, dem 05.09.2023 um 19:40 +0100 schrieb (:

Liliana Marie Prikler  writes:

Uhm, we have snippets?


Well, those are exclusive to Emacs :)  And without regard to /that/
issue, I do think that there's a problem if the commit format is so
complex that it's not trivial for anyone new to the project to write
them out manually.

By definition, no amount of typing is non-trivial, safe for the empty
amount, which good luck trying to commit your changes by pure mouse
movements, I guess?

Now, if you excuse my French, I think the problem isn't really as much
that people struggle to type out the perfect ChangeLog on the first
try, which also makes it odd to request a linter.  Bear in mind that
committers will sign off anything that appears convincing enough, even
if there are smaller mistakes in the message.  Trust me, I've been
there and seen that; and also done it myself.

Instead, we have seen in this thread appeals to age, appeals to
perceived lack of personal benefit, and now appeals to typing effort,
none of which 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 to take a step back and instead 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?”  We have drifted much from the original post that discussed
moms with full-time jobs, who struggle to do “difficult” tasks
(simplified wording; may change the meaning of the OP a little).  Now,
I personally struggle to see how your personal preference for
communication media, commit message style, and other things that were
discussed in any of the preceding threads actually correlate with being
a parent.  However, I do know that with its 150 million users, most
people of the world don't have a Github account.  Being one of the 4
billion email users out there is a comparably low barrier of entry
imho.  So, whose cognitive overhead do you want to reduce (besides the
obvious "my own", which everyone always tries)?


Liliana, many of your responses in this thread are not OK. They have 
been dismissive and have strayed into personal attacks. At times I'm 
not sure if you're intentionally misinterpreting the conversation to 
try and make a point.


If you disagree with something, or have a point to make, please do so 
directly, and without attacking anyone's character or making veiled 
innuendos about their motives or capabilities.


Speaking for myself, I think if you asked me questions instead of 
inferring narratives, you'd find that our values and preferences are 
probably more closely aligned than you realize.


We're all here to try and make Guix better, but we can't do that in a 
hostile environment.



Completely agree with this too. I wanted to say that Katherine is not 
alone in feeling that some comments


in the thread have been dismissive or even elitist in a lot of cases. 
and one of the main people posting these


have been Liliana.

Re: How can we decrease the cognitive overhead for contributors?

[MSavoritias]

On 9/6/23 23:10, Wojtek Kosior via Development of GNU Guix and the GNU 
System distribution. wrote:

Hello,

I wanted to add to this thread my 2 cents. As a person who has recently
(last months) made the first attempts at contributing.

To me, registrations and reliance on JS had always been an obstacle to
using web-based forges. This is one of the reasons I haven't been
contributing to existing projects in the past.

With Guix this issue is gone but there's also another thing that
incentivized me — that, since joining the Guix mailing lists, I am
seeing activity all the time, right at my fingertips (because I have my
email client opened most of the time).

So far I have sent patches 4 times. Once it was a simple update that got
accepted quickly, once I was addressing a problem that turned out to be
better solvable another way and 2 submissions are still waiting for
someone to review them.

Although I had to learn to use `git format-patch` and related tools, I
don't consider it a problem. Actually, I wanted to learn email-based
workflow anyway because it seems to be a more KISS way of software
development.

The amount of new stuff to learn can, however, be a bit overwhelming. I
did learn to use git to send emails but haven't yet started using any of
the templating packages for Emacs that were recommended in Guix
documentation. It would be just too much to process at once.

Do I think Guix has a problem with cognitive overhead? Not at all.
Rather, it seems to be addressing the problems really well.
1. It makes it easy to hack on itself without the need to clone the
repo first. That's what helped me get familiar with it before I
could even try to contribute anything.
2. It, by default, updates to the most up-to-date version.
3. It has some detailed documentation.
4. It eases the setting up of one's development environment.

I fact, I suspect the email-based workflow might be automatically
filtering out some bad submissions that would have been made otherwise.
The geeky nature of the project does put it in a kind of a niche where
only geeks dwell. But this is somewhat benefitial because geeks are
those who can build it.


Arguments that its a good thing its hard for people to contribute to the 
project don't really help.


Because among others it promotes gate-keeping and elitism. Im not saying 
you specifically are that person,


but that is how a person that wants to contribute will get the argument.


The part about email working for you, I am glad it does :)

We need to care for the people that may like a different style of 
contributing too though.


Because the more people guix can attract the better for the project.


MSavoritias



Lastly, sorry if something I wrote is a duplicate of other's opinions —
the thread got s long it'd be hard to read through 100% of it

Best,
Wojtek

-- (sig_start)
website: https://koszko.org/koszko.html
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
follow me on Fediverse: https://friendica.me/profile/koszko/profile

♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ==
✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8=
-- (sig_end)


On Tue, 05 Sep 2023 22:43:04 +0200 Liliana Marie Prikler 
 wrote:


Am Dienstag, dem 05.09.2023 um 19:40 +0100 schrieb (:

Liliana Marie Prikler  writes:

Uhm, we have snippets?

Well, those are exclusive to Emacs :)  And without regard to /that/
issue, I do think that there's a problem if the commit format is so
complex that it's not trivial for anyone new to the project to write
them out manually.

By definition, no amount of typing is non-trivial, safe for the empty
amount, which good luck trying to commit your changes by pure mouse
movements, I guess?

Now, if you excuse my French, I think the problem isn't really as much
that people struggle to type out the perfect ChangeLog on the first
try, which also makes it odd to request a linter.  Bear in mind that
committers will sign off anything that appears convincing enough, even
if there are smaller mistakes in the message.  Trust me, I've been
there and seen that; and also done it myself.

Instead, we have seen in this thread appeals to age, appeals to
perceived lack of personal benefit, and now appeals to typing effort,
none of which 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 to take a step back and instead 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?”  We have drifted much from the original post that discussed
moms with full-time jobs, who struggle to do “difficult” tasks
(simplified wording; may change the meaning of the OP a little).  Now,
I personally strugg