Toward a "modern" Emacs

Posted Sep 26, 2020 1:09 UTC (Sat) by marcH (subscriber, #57642)
In reply to: Toward a "modern" Emacs by josh
Parent article: Toward a "modern" Emacs

> Requiring people to submit paperwork first kills casual contribution; you have to be fairly dedicated to get past even that hurdle.

I recently tried to "promote" myself from seasoned user to contributor. Learned a bit more eLisp and some basic troubleshooting techniques. Root-caused a bug or two in tramp, pinpointed what was wrong in the code and started to make some code changes.

Then I discovered I have to surrender copyright, submit paperwork and subscribe to some mailing-lists (13 different ones listed at https://savannah.gnu.org/mail/?group=emacs...) I'm not interested in configuring an email filter so I can ignore emacs-devel discussions, I just want to file a bug and git push a patch to something that runs CI.

I heard the VSCode equivalent of tramp rocks. I'm now seriously considering abandoning a couple decades of Emacs muscle memory.

Toward a "modern" Emacs

Posted Sep 26, 2020 1:34 UTC (Sat) by IanKelling (subscriber, #89418) [Link] (7 responses)

> and subscribe to some mailing-lists

That is not true, I wonder where you got that. Subscription has and never will be required. Just email your patches to emacs-devel@gnu.org, email bug reports to bug-gnu-emacs@gnu.org. People will reply to you.

If you send email from an address the list has never seen before, it can take a few hours before a human looks at it and sends it to the list. That happens regardless of subscription status.

Toward a "modern" Emacs

Posted Sep 26, 2020 1:40 UTC (Sat) by IanKelling (subscriber, #89418) [Link]

I got the address wrong. CONTRIBUTE says "bug reports and fixes, feature
requests and patches/implementations should be sent to
bug-gnu-emacs@gnu.org" and then it has instructions on how to send a
patch. There is nothing about needing to subscribe to do it.

Toward a "modern" Emacs

Posted Sep 26, 2020 2:09 UTC (Sat) by marcH (subscriber, #57642) [Link] (5 responses)

> > and subscribe to some mailing-lists

> That is not true, I wonder where you got that.

That's great, thanks for correcting me but I'm still not interested in using email "the old way". I want to select myself which code reviews and which bugs send me email and I want all the discussion about one particular series to be easy to find in one place. It does not necessarily imply a web interface, it only implies a "modern" database. I haven't tried this myself but I heard some people use github from... Emacs most of the time! http://wikemacs.org/wiki/Github

PS: I "got that" because that is (used to be?) the most common expectation with email-based projects. I (genuinely) wonder where you got the correct information.

Toward a "modern" Emacs

Posted Sep 26, 2020 2:20 UTC (Sat) by IanKelling (subscriber, #89418) [Link] (2 responses)

I will admit that it is a problem that that many lists on the internet require subscription then people come to gnu lists expecting that. Perhaps CONTRIBUTE should mention this fact.

I can't remember exactly where I figured out that 99.5% of gnu.org and nongnu.org lists don't require subscription to post, probably after I became an administrator of them, which is not a good sign.

Toward a "modern" Emacs

Posted Sep 26, 2020 2:36 UTC (Sat) by IanKelling (subscriber, #89418) [Link]

Also, I think there's like 1 in 10 gnu/nongnu lists or so where you don't need to subscribe to post, but you won't get replies because the list is configured so replies only to the list. And you basically have to look at an example reply in the archive to figure it out. So, ya, we should fix that situation.

Toward a "modern" Emacs

Posted Sep 26, 2020 17:21 UTC (Sat) by marcH (subscriber, #57642) [Link]

> I will admit that it is a problem that that many lists on the internet require subscription then people come to gnu lists expecting that. Perhaps CONTRIBUTE should mention this fact.

Yes please.

I suspect the most obvious and common rationale for requiring mailing-list subscription is mitigating spam, which code review databases keep under control by requiring a user account, which is admittedly their biggest road bump for "drive-by" contributors. Security versus usability: always the same trade-off.

The user account road-bump is largely mitigated thanks to federation: I mean for instance you can re-use your launchpad and many other accounts on a number of "foreign" sites.

Toward a "modern" Emacs

Posted Sep 26, 2020 2:40 UTC (Sat) by IanKelling (subscriber, #89418) [Link] (1 responses)

I agree about the database. I'm hopeful that GNU will adopt something for that in the next year or so. Contributions are welcome.

Toward a "modern" Emacs

Posted Sep 26, 2020 17:44 UTC (Sat) by marcH (subscriber, #57642) [Link]

Is gitlab not free enough? Drifting away from the topic but genuine question. It seems increasingly popular with largely-but-not-totally-free projects right now.

Toward a "modern" Emacs

Posted Sep 26, 2020 6:40 UTC (Sat) by eliz (guest, #94829) [Link] (4 responses)

> Then I discovered I have to surrender copyright, submit paperwork and subscribe to some mailing-lists

On 1/3 true: the paperwork, and it's a one-time thing.

The rest is simply misunderstandings: you don't surrender any copyright (the legal paper you get at the end of the paperwork explicitly says that the FSF grants back to you the copyright), and you don't need to subscribe to any mailing lists, because submitting an issue makes sure you are CC'ed on any messages posted to that issue.

Toward a "modern" Emacs

Posted Sep 28, 2020 9:47 UTC (Mon) by farnz (subscriber, #17727) [Link] (3 responses)

Any paperwork is a real hassle for me, however; of my employers over the last 20 years, one would require approval for all OSS contributions, the others only require that I notify them of the contribution and that it's licensed under one of a list of acceptable licences (which include GPLv3). For contributions to most projects, this is enough - I can publish code where my employer is the copyright holder under a Free or Open source licence, they can pull it in, everyone's happy.

However, once you require copyright assignment paperwork (as the FSF does), the hassle level for me skyrockets; I have to get hold of the documentation, take it to legal, give them time to review it, schedule time with legal to discuss what the paperwork means, get legal to produce a document confirming I'm allowed to sign it without compromising my employment, sign it, get legal to sign it, and then return it to the originator. That's an awful lot of work if my patch is going to be a small thing and I don't expect to repeat it any time soon (so may move onto another employer and have to repeat the copyright assignment dance for the next patch).

So, while it might be a one-off per employer for me, it's a lot of effort to go through when I'm not doing a "big" contribution; and because I'm put off from doing small contributions, upstream never gets the chance to encourage me to make bigger ones.

Toward a "modern" Emacs

Posted Sep 28, 2020 12:12 UTC (Mon) by pabs (subscriber, #43278) [Link] (2 responses)

I recommend negotiating copyright ownership of any freely licensed code that you write, then you don't have to involve your employer in copyright assignment paperwork at all :)

https://sfconservancy.org/contractpatch/

Toward a "modern" Emacs

Posted Sep 28, 2020 13:06 UTC (Mon) by farnz (subscriber, #17727) [Link] (1 responses)

Even on code where I own the copyright, I still have to go via my employer to get permission to sign copyright assignment forms, because of the risk of a conflict of interest between the person I'm assigning copyright to, and my employer.

And, of course, such a negotiation involves all the hassle of going through legal to get a contract change *and* then I have to go through all the hassle again to sign a copyright assignment form. Why would I bother doing any of this for a small change?

Toward a "modern" Emacs

Posted Oct 2, 2020 10:37 UTC (Fri) by kpfleming (subscriber, #23250) [Link]

Even if you own the copyrights on your own work, if you are employed as a software developer the FSF will require a disclaimer from your employer confirming that they disclaim any interest in the works you are creating and contributing. As a person at an employer who had to create a process to produce these disclaimers for our employees, it is indeed a hassle.

So, if you are employed as a software developer, you will need to get your employer to sign an FSF document either way: either a copyright assignment, or a disclaimer.