[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Simplify contribution by using user-friendly bug tracker and git int
|
From: |
Ekaitz Zarraga |
|
Subject: |
Re: Simplify contribution by using user-friendly bug tracker and git interface |
|
Date: |
Sat, 31 Aug 2024 15:05:58 +0200 |
Hi,
On 2024-08-31 14:05, Jan Wielkiewicz wrote:
Hello again,
On Sat, 31 Aug 2024 01:45:04 +0200
Ekaitz Zarraga <ekaitz@elenq.tech> wrote:
Hi Jan,
First, there are tags in the issue system:
https://issues.guix.gnu.org/search?query=tag%3Aeasy
Missed this completely. Where is this documented?
In the bottom of the search box, you can show hints and then it suggests
to use them.
The issue of friendliness has been brought up in the past, I suggest
you to search in the mailing list for previous interactions in the
topic.
In fact, I took part on a discussion about more general topics and I
mentioned we should be more empathetic with other people's needs:
https://lists.gnu.org/archive/html/guix-devel/2023-09/msg00488.html
Okay, will read this later.
Tedious and counterintuitive are very loaded words, and not very
objective either. The intuitiveness of things is based on the
previous context people has. This is a GNU project, and the context
for many GNU developers is autotools, mail based workflow and so on:
maybe for GNU developers that's the most intuitive thing. Who should
we please?
I used these words because they convey my feelings related to the
current process. The discoverability of the system is low - every time
I send patches I need to reread documentation to then finding out my
email provider does not cooperate (failing SMTP, having to re-enable
email client support to proceed). So I probably need to change my email
provider in order to contribute to Guix smoothly.
This was literally my situation not that long ago. I'll explain more below.
I'm aware this is a GNU project, I'm a free software enthusiast and
GNU/Linux user myself, but I'm not an epic GNU hacker and you can't
expect all contributors (who simply want to update a package they use)
to be epic GNU hackers.
I agree with this. We are not expecting that either. That's why I was
trying to push for a better documentation. I read your original message
as coming from frustration and I don't think you were very empathetic
when you wrote it.
In my case, I find the Github-like PR based approach quite
counterintuitive, but I got used to it before collaborating in Guix
and now I don't dislike it. Starting using PRs for everything made me
a little bit reluctant to try the email based approach. Surprisingly,
it happens to be way easier than it looks, and it's actually quite
cool.
Wasn't easy to learn it at first, but running "git push origin" to
update a remote branch linked to a PR is pretty straight-forward.
As simple as `git send-email HEAD~`. Our way is not more complex, it's
just different.
You should give it a go: https://git-send-email.io/
(If you don't like or you can't use that, you can paste the patches
in an email, or send them as attachments, which is as difficult as
taking part in this mailing list.)
I have this installed and use it, can't send patches to Guix
otherwise...
The link is a very good tutorial on how to use git-send-email. I like to
share it because it made a huge difference to me. It's just a very short
tutorial that explains very well the workflow in a practical way.
Once you use it for as long as you used other options, I'd love to
have this conversation with you again (I'm not saying you'd change
your mind, but the conversation would be fairer).
I will share some thought here that I know many people in the
community doesn't agree with (and I'm kind of a 50-50 on it) but I
think it's worth sharing:
So, it is true that making the access to things harder than the
possible minimum is simply stupid. There's no discussion there.
That being said, it would be very sad if a seasoned software
developer, who proved to be able to write code for a complex project
like Guix, is not able, is discouraged to, or is afraid of sending
the patches via email (but is ok opening an account, making a fork,
making a pr and so on).
I'm apparently smart enough to install Guix as my daily driver distro,
learn Emacs with Paredit and hack together packages, and then an
email-based system filters me out...
This is a very interesting point and I encourage you to dive deeper on
it. In my case I had pushed for a less emacs-centric approach in the
docs, and I wrote some parts of the documentation for people that used
other editors. I'm not smart enough to use emacs, and I gave up on it,
but with the tutorial above I overcame my fears with the email based
approach.
Putting it in a different way: not every contribution is worth
attention. If people who want to contribute are not able to send an
email, I don't think their potential contributions would be that
interesting or worthy. The skills needed to be able to participate in
Guix are quite advanced, I don't think the email is a burden for
people that have them.
So let's say, yes: we do migrate to codeberg.org. And now what? Do
you think the amount of contributions will skyrocket? Do you think
the amount of meaningful contributions will be higher?
Guix is not one thing - updating packages is not the same kind of task
as for example hacking on low-level system or package manager
functionality. I believe simplifying or making contributions more
similar to what other projects have would indeed help. One example
would be a free software game project I take part in. The original
founder of the game did not know git and maintained the game using
GitHub's online editor. Then when he stepped down, we moved the project
to Codeberg. In the very same project we also taught a literal Windows
user how to use git and command line which then enabled him to make
cool and meaningful contributions. And then I myself did several
contributions to Guix while barely knowing what I'm doing. So I'd be
careful with underestimating the power of inexperienced users.
Yeah, I can agree with you, but we should as a whole make a cost-benefit
analysis of this. Maybe making our current audience uncomfortable just
for potential contributions that we don't know how many they can be is
not a good idea. We should think about this deeply, and I opposed your
email just because it was too categorical and I wanted to share the
other side of the coin with you.
I know what I say here might smell like some intellectual classism or
something, but if we slow down a little bit: implying that there's a
lot of people wanting to contribute to Guix and they cannot overcome
the burden of the tooling we use is a little bit condescending to
them.
I'm doing my best to overcome the burden of tooling, but in the very
same time I could just make my own channel with software I want updated
on Codeberg, instead of contributing them to upstream Guix.
This is fine, Guix's nature does not only allow this but also encourage
it. In the moment you want to upstream your changes, you'll have my help
in the IRC or in the Mailing List to guide you over the process.
*People are smart*. They'll figure out. Our process could be better,
specially the documentation for newcomers (which btw improved a lot
recently, and mumi is great), for sure, but, in summary:
Yeah, the current format of the document makes it easy to overlook
important things, for example there's no header called "Canceling Your
Issue", "Updating Your Patch Series", etc. Codeberg's user interface
makes these things discoverable under nice green/red buttons.
This is way more constructive than your previous email and is very
interesting. Suggestions like this help a lot to make a better
documentation and become more welcoming and are not radical changes that
require a huge agreement in the community. This we can do, right now.
About those specific issues, debbugs allows to close the issues by
email. Guix documentation shows how to do it with mumi:
mumi compose --close
But I agree we could do better, and I suggest you to point out all the
things you'd like to have and I commit myself to updating the
documentation with them.
- I don't dislike the PR style
- I doubt if using a PR based approach would result in more and
better contributions
- Just because something is more popular that the other thing it
doesn't mean the latter is less intuitive
- Our process is not more complex, but it might be *new* for people
- If we provide GOOD documentation, people will understand it
- We have communication channels (that work) for the cases when
people gets stuck
Those are my thoughts.
In the end you could argue that it's my own fault for using a
broken/incompetent email provider, but then it's the contribution
system of Guix that exposed this issue as opposed to alternative
systems like web GUIs that usually just work. Perhaps adding "your
email provider may be broken, try using a different one" and "make sure
to enable support for a standalone email clients in your email
settings" to the documentation would help? I spent more time than
needed in my life looking for solutions to fix email sending.
I have had SMTP problems with my previous email provider (protonmail)
and I had to paste the patches in the body of the emails, or add them as
attachments. It worked, but this was one of the main things that
prevented me from trying git-send-email.
I am familiar with your issue, and it's really disappointing. I finally
changed my provider and my quality of life was improved dramatically.
If you don't want to change your provider, which is perfectly ok, you
are probably going to find some things a little bit more uncomfortable,
but it's still possible.
When I had issues with all this, people in the Guix community helped me
with the setup, corrected my patches, and encouraged me to be do it
better next time. I wasn't scared off by people: nobody here wants that.
What I got were some mentors that encouraged me to give the best of
myself, not only in this project but also in others.
Please correct me if I'm wrong but from your previous message I read you
were frustrated and maybe angry about it. From this message I read what
you need is just some support. I think I can help. If you want, we can
guide you to be more comfortable with the platform and document
everything that made your life easier in order to make next person's
approach to Guix smoother.
So yeah, that's pretty much it
What do you think?
Should we start?