From: Ekaitz Zarraga <ekaitz@elenq.tech>
To: Jan Wielkiewicz <tona_kosmicznego_smiecia@interia.pl>,
guix-devel@gnu.org
Subject: Re: Simplify contribution by using user-friendly bug tracker and git interface
Date: Sat, 31 Aug 2024 01:45:04 +0200 [thread overview]
Message-ID: <57b92ff9-6c6f-2c1b-6c3b-4c3d9daecce2@elenq.tech> (raw)
In-Reply-To: <20240831003521.5c956363@interia.pl>
Hi Jan,
On 2024-08-31 00:35, Jan Wielkiewicz wrote:
> Hi,
>
> I feel that emails are not the best system for interacting with the
> project. The issue tracker is not helpful, it's hard to find anything
> there, there are no tags/labels/milestones... Sending patches also
> involves using a tedious and counterintuitive interface, scaring off
> possible contributors.
>
> I think a good solution would be hosting a forgejo instance [1] or
> making a codeberg mirror [2] where users could send their pull
> requests to. These have a friendly user interface with labels, a bug
> tracker, etc. Well, unless the point of the email interface is to
> gatekeep and scare off contributors...
>
> [1] https://forgejo.org/
> [2] https://codeberg.org/
First, there are tags in the issue system:
https://issues.guix.gnu.org/search?query=tag%3Aeasy
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
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?
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.
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.)
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).
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?
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.
*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:
- 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.
next prev parent reply other threads:[~2024-08-30 23:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-30 22:35 Simplify contribution by using user-friendly bug tracker and git interface Jan Wielkiewicz
2024-08-30 23:45 ` Ekaitz Zarraga [this message]
2024-08-31 12:05 ` Jan Wielkiewicz
2024-08-31 13:05 ` Ekaitz Zarraga
2024-08-31 13:44 ` Jan Wielkiewicz
2024-08-31 21:14 ` Suhail Singh
2024-08-31 21:42 ` Ekaitz Zarraga
2024-09-01 16:13 ` Steve George
2024-08-31 19:26 ` Attila Lendvai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57b92ff9-6c6f-2c1b-6c3b-4c3d9daecce2@elenq.tech \
--to=ekaitz@elenq.tech \
--cc=guix-devel@gnu.org \
--cc=tona_kosmicznego_smiecia@interia.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.