Update my talk description in 2021/talks/devel.md

1 files changed, 24 insertions, 74 deletions

diff --git a/2021/talks/devel.md b/2021/talks/devel.md
index b3c197f4..015e8118 100644
--- a/2021/talks/devel.md
+++ b/2021/talks/devel.md
@@ -8,80 +8,30 @@
 # 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.
--->
-
+We need a successful Emacs on this planet.  This means that we need an
+excellent out-of-the-box experience -- one that just works, but that you
+can still hack and customize.  There is so much great experimentation
+and work going on out there in the wider Emacs community, but we would
+be even better off if more of that could go into Emacs itself.
+
+Emacs' greatest strength is unfortunately sometimes also its greatest
+weakness: it is **too** hackable.
+
+On occasion, people out there add stuff to their Init file to fix this
+or that annoyance, or even bug.  The more ambitious might go on to
+package up such fixes: "Hey, `foo-mode` doesn't have support for
+`bookmark-set`, let's write a package!"  I am here to suggest that you
+should not do that.
+
+You should submit a patch to Emacs!  Maybe more people have that same
+problem or annoyance, and would benefit from your solution?
+
+It is sometimes perceived as hard to contribute to Emacs core.  I want
+to encourage more people to get involved, and show that the barrier to
+entry is really not that high.  If I can do it, you can do it too!
+
+So should you really write that package, or should you stop worrying and
+learn to love emacs-devel?  Listen to my talk to find out more!
 
 [[!inline pages="internal(2021/info/devel-schedule)" raw="yes"]]