Hi,
On Sun, 17 Sep 2023 at 19:20, MSavoritias <em...@msavoritias.me> wrote:
> 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.
--8<---------------cut here---------------start------------->8---
$ git shortlog -sn --all | wc -l
952
$ git log --format="%ce" | sort | uniq -c | wc -l
104
--8<---------------cut here---------------end--------------->8---
Please point one project where:
+ more than 900 people have contributed to the project,
+ more than 100 people had or have write access in the repository.
It is fine to discuss how to improve and what we could do better. It is
incorrect to say “guix doesn't get have many committers and
contributors” and it is not fine to frame it negatively.
> For example Debian moved to Gitlab. Same for gnome and kde.
As I pointed in my very first reply [1] in this thread:
For instance, Debian is based on Gitlab since their switch from Alioth
to Salsa. It would be interesting to know if this “new” web-based
workflow using Merge Request is increasing the number of submissions
and/or increasing the number of occasional contributors.
As far as I have read all this thread, no one provides numbers. The
answer by Vagrant (Debian Developer and Guix contributor) appears to me
interesting [2]. Therefore, could we stop this useless and unproductive
flamewar? Many Guix channels are hosted on Gitlab, Github or Sourcehut
and they are not receiving so much more contributions. As Katherine
pointed [3],
I know everyone is focusing on email vs. web-forge, but I am trying to
draw attention to the root causes of the complexity, and enumerating
possible solutions to these.
and I think that kind of mindset is very helpful; it is engaging. Well,
to my approximate recollection, there is a talk at each DebConf about
reflecting on newcomers backed by 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 we decrease the cognitive overhead for contributors?
Simon Tournier <zimon.touto...@gmail.com>
Thu, 24 Aug 2023 20:53:14 +0200
id:871qfsuvad....@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2023-08
https://yhetil.org/guix/871qfsuvad....@gmail.com
2: Re: How can we decrease the cognitive overhead for contributors?
Vagrant Cascadian <vagr...@debian.org>
Sat, 02 Sep 2023 18:05:40 -0700
id:87wmx8m5gb.fsf@wireframe
https://lists.gnu.org/archive/html/guix-devel/2023-09
https://yhetil.org/guix/87wmx8m5gb.fsf@wireframe
3: Re: How can we decrease the cognitive overhead for contributors?
Katherine Cox-Buday <cox.katherin...@gmail.com>
Tue, 05 Sep 2023 13:15:48 -0600
id:13416fee-8c7d-b145-48b9-0fbec2251...@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2023-09
https://yhetil.org/guix/13416fee-8c7d-b145-48b9-0fbec2251...@gmail.com
4: https://debconf23.debconf.org/talks/32-teams-newcomers-and-numbers/
5: https://debconf23.debconf.org/talks/2-adulting/
