From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: xenodasein--- via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: On Contributing To Emacs Date: Tue, 28 Dec 2021 13:03:42 +0100 (CET) Message-ID: Reply-To: xenodasein@tutanota.de Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36001"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 28 13:05:42 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n2BEb-00097z-Pv for ged-emacs-devel@m.gmane-mx.org; Tue, 28 Dec 2021 13:05:41 +0100 Original-Received: from localhost ([::1]:38472 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n2BEa-0005E6-8Y for ged-emacs-devel@m.gmane-mx.org; Tue, 28 Dec 2021 07:05:40 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:50072) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n2BCl-0003p2-Lf for emacs-devel@gnu.org; Tue, 28 Dec 2021 07:03:47 -0500 Original-Received: from w4.tutanota.de ([81.3.6.165]:40722) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n2BCj-0004SK-Lq for emacs-devel@gnu.org; Tue, 28 Dec 2021 07:03:47 -0500 Original-Received: from w3.tutanota.de (unknown [192.168.1.164]) by w4.tutanota.de (Postfix) with ESMTP id 45F5F1060122 for ; Tue, 28 Dec 2021 12:03:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1640693022; s=s1; d=tutanota.de; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Date:Date:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:Sender; bh=il1kI2psg/bHHu146X6c4VhrcRM9EPUMAlavYZ5i3oc=; b=lpeya5aQuJ/ISEp2SdrQD4ljlPXal1/KXISagIFxauak86wwPd/gYPs1JemZ8O/d tXxj+7eXuIE/IFp5c0xOgwZHGG8R7t7OCFZQwCNeiutMn9RfMEHWdgN2fmzU4NPINje xG5ml90xrgVQK8ovAPYOrxcI/3+eKnJezszKS7sovPAkzKKlVs+uK2JklK0lKDNwEQ5 LrPyq7Z8A9uLD3jkvjQEIUakMiOcjz2zDjt1JRqGqCkXSjtDVRKk3T1sfR+vtdVeBPB C+D/SkDDtMJLdrki8NNb/lzzEYsTg2UC39Xi+UOSKfRm75rfbimcEAb7hWSyMoz+IF5 QUg/Gs0RrA== Received-SPF: pass client-ip=81.3.6.165; envelope-from=xenodasein@tutanota.de; helo=w4.tutanota.de X-Spam_score_int: -1 X-Spam_score: -0.2 X-Spam_bar: / X-Spam_report: (-0.2 / 5.0 requ) DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:283497 Archived-At: Following article is from the original author of package straight.el. They have taken the time and explained the situation in detail. Hopefully we will apply the same level of attention to detail and introspection when evaluating their thoughts and experiences. It's very easy to say "the best choice would have been to fix package.el", and a lot harder to put in the years of work required to actually do that. From a purely technical point of view, I stand by my decision to create a separate project as I believe it was a much more effective way of quickly bringing about positive change in the ecosystem, even if the end result was to merge things back together in the long run. Obviously I didn't make the decision for "career advancement", I made it for what I perceived to be the best interest of the community. Reasonable people can disagree about what is best for the community. However, the problems go much deeper than that and I will elaborate in the rest of this email. > xenodasein: > The problem is what lead you to do that, and what can emacs-devel > do to prevent same thing from happening in the future. Now this is something worth talking about. Yes, indeed, my experiences with emacs-devel and the Emacs core development ecosystem in general have been mostly negative, and have discouraged me from contributing more than I absolutely had to. And yes, indeed, this feeling was part of what motivated me to advocate for installing the absolute minimum patch into Emacs core that would allow me to get on with straight.el development. The idea that there is something culturally wrong with the core development of Emacs is not new; see Open Letter to the Emacs Maintainers from 2016 for one example. But let me give my own impressions. - Development velocity is glacial. With releases around once per year and there being no easily accessible distribution mechanism for development updates, high-velocity projects or projects that must adapt to a changing ecosystem (straight.el satisfies both of those criteria) simply do not have a place in Emacs core as it exists today. - The tools that must be used for contributing to Emacs are extremely antiquated, and difficult to use for most developers, especially newer ones who form the majority of the potential contributor base. I agree with the points in the open letter linked above. - The CLA signing process is inexplicably slow and opaque. With most other projects, you sign the CLA in two minutes through a web interface and you are on your way. With Emacs, you have to send an email, which may or may not eventually receive a reply with the appropriate form, which you then have to manually send back, and the whole process often takes months with no communication whatsoever from the FSF about the reason for the holdup, especially for contributors outside the United States. I can point to a number of documented examples of this (i.e. contributors waiting multiple months with no reply from the FSF, despite many follow-ups). - The mailing list which is the sole form of communication for Emacs core development feels exclusionary to me. There is a heavy backbone of established culture and conventions around the mailing list, which are to my knowledge not documented anywhere and instead exist as unwritten rules of discourse. And that's on top of the fact that all development takes place via a mailing list in the first place, which is a foreign concept to almost every new developer getting into open-source. I can't point to any specific practice that seems problematic, but the fact remains that while I have felt welcomed and included into many other open-source communities, I have never felt this way about my contributions to Emacs core. I know for a fact that I am not the only person who has felt excluded from contributing to Emacs because of one or more of these reasons, especially the last. However, when these issues, especially the last, are brought up, the response usually goes like this: 1. Can you point to a specific example of what the problem is? 2. Well, in that particular example, here's why how we do things is perfectly reasonable. 3. Did you consider doing things this other way instead? I understand this is well-intentioned, and it is usually done in an unfailingly polite manner. But it has usually come across to me as gaslighting, and it's my opinion that the culture surrounding Emacs core development, in aggregate, strongly discourages new contributors from joining the community, especially if they are a member of a group which is traditionally underrepresented in open-source. So if you want the long answer about why I developed straight.el outside of Emacs core? It's because I didn't feel I was up to the task of fixing the cultural problems above, and I don't feel comfortable contributing to Emacs, or suggesting to others that they do so, until they are fixed. Just fixing package management was hard enough, thank you. I hope this is helpful in understanding why things developed as they did, Radon