1 files changed, 88 insertions, 0 deletions

diff --git a/2021/talks/devel.md b/2021/talks/devel.md
new file mode 100644
index 00000000..b3c197f4
--- /dev/null
+++ b/2021/talks/devel.md
@@ -0,0 +1,88 @@
+[[!meta title="Don't write that package! or: How I learned to stop worrying and love emacs-devel"]]
+[[!meta copyright="Copyright © 2021 Stefan Kangas"]]
+[[!inline pages="internal(2021/info/devel-nav)" raw="yes"]]
+
+<!-- You can manually edit this file to update the abstract, add links, etc. --->
+
+
+# Don't write that package! or: How I learned to stop worrying and love emacs-devel
+Stefan Kangas
+
+Emacs' greatest strength is also its greatest weakness: it is **too** hackable.
+
+We have a great community that experiment with new features that are still
+lacking in Emacs core.  They write up a package and develop the living daylights
+out of it, until it is basically amazing.  (I'm looking at you Magit.)
+
+There are other examples such as helpful.el - great package, but why are those
+features not in core?  What about projectile?  And so on.
+
+Core demands copyright assignments (CLA).  This is a fact of life.  While I
+mostly agree with the people saying it is not helful, they are there to protect
+Emacs from copyright issues in the future.  So my suggestion here is simple:
+just **sign the papers**.  It is just a formality, and you should only need to do
+it once.
+
+I suggest that any ambitious feature that we **might** want to see shipped in the
+default Emacs distribution should by default go to GNU ELPA.  You don't need to
+do this, of course, and I respect your decision, but I urge you to do it.
+
+GNU ELPA does not have an exceptionally high standard, but we do try to give any
+new package a proper code review.
+
+MELPA is excellent.  We love MELPA.  They don't have a criterion for their
+packages that is important to the FSF, which is to not recommend non-free
+software.  Therefore, we could not recommend it by default, and had to build
+NonGNU ELPA.
+
+NonGNU ELPA will be used for packages that we don't have an assignment for but
+would still like to distribute.  It should ideally only be for old packages
+where getting a CLA is impractical.
+
+It is sometimes perceived as hard to contribute to Emacs core.  This impression
+is largely wrong.  If I can do it, you can too.
+
+We do have a problem in that our tools and methods (mailing lists, the bug
+tracker) are out-dated.  This is largely correct.  We want to migrate to
+something else, and the best candidate is probably Sourcehut.  Please volunteer
+to help!
+
+We sometimes see people adding stuff to their Init file to fix this or that
+annoyance, or even bug.  The more ambitious would go on to package up such fixes
+in what I call "patch packages". "Hey, foo-mode doesn't have support for
+'bookmark-set', let's write a package!"  I am here to suggest that you submit a
+patch to Emacs instead.
+
+Fixing an issue for one person is good, and fixing it for more people is even
+better.  Fixing it for everyone?  Priceless.
+
+emacs-devel is not that scary, nor is email.  We are really quite friendly and
+easy going, but the communication we prefer (for reasons of efficiency - the
+volume is very high) is often very brief and to the point.  We are trying our
+best at communicating, but sometimes fail.
+
+And we need more contributors.  We need a successful Emacs on this planet.
+
+So should you really write a package, or should YOU become a core contributor?
+
+
+
+# Outline
+
+- I will urge people to consider contributing to Emacs instead of
+  writing small packages, and explain GNU ELPA, MELPA, CLA.
+- I will go into greater detail about emacs-devel, how it "works"
+  (e.g. is Emacs conservative without reason?), how to get things
+  done and the necessary mindset.
+
+<!--
+-   40 minutes: (brief description/outline): All of the above, and I will show a
+    demonstration and give instructions for how to use M-x debbugs to read the bug
+    tracker, how to send emails, patches, and our workflows. More on what to
+    expect.
+-->
+
+
+[[!inline pages="internal(2021/info/devel-schedule)" raw="yes"]]
+
+[[!inline pages="internal(2021/info/devel-nav)" raw="yes"]]