all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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.


  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.