Merge branch 'master' of git.emacsconf.org:emacsconf-wiki

6 files changed, 203 insertions, 3 deletions

diff --git a/2022/talks/detached.md b/2022/talks/detached.md
index 4707a9fb..15f592cd 100644
--- a/2022/talks/detached.md
+++ b/2022/talks/detached.md
@@ -7,7 +7,7 @@
 
 
 # Getting detached from Emacs
-Niklas Eklund (he/him)
+Niklas Eklund (he/him, <mailto:niklas.eklund@posteo.net>)
 
 [[!inline pages="internal(2022/info/detached-before)" raw="yes"]]
 
diff --git a/2022/talks/fanfare.md b/2022/talks/fanfare.md
new file mode 100644
index 00000000..111ba56e
--- /dev/null
+++ b/2022/talks/fanfare.md
@@ -0,0 +1,48 @@
+[[!meta title="Fanfare for the Common Emacs User"]]
+[[!meta copyright="Copyright &copy; 2022 John Cummings"]]
+[[!inline pages="internal(2022/info/fanfare-nav)" raw="yes"]]
+
+<!-- Initially generated with emacsconf-generate-talk-page and then left alone for manual editing -->
+<!-- You can manually edit this file to update the abstract, add links, etc. --->
+
+
+# Fanfare for the Common Emacs User
+John Cummings
+
+[[!inline pages="internal(2022/info/fanfare-before)" raw="yes"]]
+
+
+# Table of Contents
+
+
+
+Emacs enables Emacs developers to produce some very impressive and
+useful things.  It can also inspire examination and discussion of
+profound ideals.  But what about the everyday user who may not always
+feel that they live up to these examples? What about the "dark matter"
+of the Emacs universe? There's a lot of us out there, and we have an
+important effect, but it may be hard to see it. What about life after
+the EmacsConf inspiration has started to fade, and we find ourselves
+working much the same way as we always have? In this
+not-very-technical short reflection (perhaps just a personal
+projection pep talk), I want to recognize and celebrate the experience
+of these users.
+
+Colored by my personal unremarkable usage of Emacs, I'll describe some
+of the practices and "imperfections" that everyday Emacs users might
+experience &#x2013; trying to create and remember keybindings, writing many
+quick hacky functions to solve miscellaneous problems, trying to learn
+more than we forget, half-implemented ideas, messy organic .emacs,
+etc. I'll frame these positively, as a great way to use Emacs for our
+own personal mundane needs, and a sign of our own dedication and
+pragmatism. I'll opine on how Emacs is, conversely, a perfect platform
+for this kind of usage in addition to highly-organized packages and
+modes.
+
+
+
+[[!inline pages="internal(2022/info/fanfare-after)" raw="yes"]]
+
+[[!inline pages="internal(2022/info/fanfare-nav)" raw="yes"]]
+
+
diff --git a/2022/talks/indieweb.md b/2022/talks/indieweb.md
new file mode 100644
index 00000000..0d451b9d
--- /dev/null
+++ b/2022/talks/indieweb.md
@@ -0,0 +1,41 @@
+[[!meta title="Putting Org Mode on the Indieweb"]]
+[[!meta copyright="Copyright &copy; 2022 Michael Herstine"]]
+[[!inline pages="internal(2022/info/indieweb-nav)" raw="yes"]]
+
+<!-- Initially generated with emacsconf-generate-talk-page and then left alone for manual editing -->
+<!-- You can manually edit this file to update the abstract, add links, etc. --->
+
+
+# Putting Org Mode on the Indieweb
+Michael Herstine (IRC: sp1ff)
+
+[[!inline pages="internal(2022/info/indieweb-before)" raw="yes"]]
+
+
+# Table of Contents
+
+
+
+Many of us maintain personal websites using Org Mode. While an
+Org-generated static site has advantages over full-blown Content
+Management Systems, its simplicity comes with costs such as fewer
+features. The first feature I missed was supporting comments on my
+site, but I quickly began to feel isolated on the web altogether.
+
+Enter the Indieweb: the Indieweb is a collection of protocols for
+connecting to other independent sites, pushing your content to social
+media sites, collecting likes, comments & responses from other sites
+<span class="underline">back</span> to yours, and many other things as well.
+
+In this talk, I'll briefly sketch out the dilemma of the independent
+web site & how the Indieweb tries to address it. The focus, however,
+will be on how Emacs, Org Mode, and a few Unix tools suffice to get
+your static Org Mode site onto the Indieweb.
+
+
+
+[[!inline pages="internal(2022/info/indieweb-after)" raw="yes"]]
+
+[[!inline pages="internal(2022/info/indieweb-nav)" raw="yes"]]
+
+[[!taglink CategoryOrgMode]]
diff --git a/2022/talks/maint.md b/2022/talks/maint.md
new file mode 100644
index 00000000..48440cc4
--- /dev/null
+++ b/2022/talks/maint.md
@@ -0,0 +1,77 @@
+[[!meta title="Maintaining the Maintainers: Attribution as an Economic Model for Open Source"]]
+[[!meta copyright="Copyright &copy; 2022 Sid Kasivajhula"]]
+[[!inline pages="internal(2022/info/maint-nav)" raw="yes"]]
+
+<!-- Initially generated with emacsconf-generate-talk-page and then left alone for manual editing -->
+<!-- You can manually edit this file to update the abstract, add links, etc. --->
+
+
+# Maintaining the Maintainers: Attribution as an Economic Model for Open Source
+Sid Kasivajhula (any pronouns, commonly he/him)
+
+[[!inline pages="internal(2022/info/maint-before)" raw="yes"]]
+
+
+# Table of Contents
+
+
+
+The problem of supporting open source software and contributors is a
+pressing one, and one for which we don't have good solutions.
+
+So many developers today pour their creative energies into
+freely-distributed works only to have those same works of passion turn
+into a pain in the neck when they find themselves eternally on the
+hook to provide support in exchange for minimal or no compensation,
+and often with limited assistance.
+
+Fundamentally, the reason it's this way is that traditional economic
+systems operate on <span class="underline">supply and demand</span> as the basis of value. In such
+systems, open and unlimited availability translates into zero market
+value, and consequently, open source enterprises are not economically
+sound. Even in high profile projects, developers make a living purely
+through value added services rather than from the core of the value of
+their contributions &#x2013; that is, from the code they wrote. Since, from
+a market value standpoint, <span class="underline">that code is worthless</span>.
+
+Copyright and patents (not to mention proprietary software) are an
+attempt to address this within the existing economic model by imposing
+artificial scarcity in order to induce market value. In principle,
+they also provide safeguards against appropriation. On the other hand,
+the unlimited availability of creative works is a profoundly good
+thing from the perspective of maximizing value, and thus suppressing
+it is deeply misguided. Organizations like the Free Software
+Foundation have campaigned against such restrictions for some time
+now, for related reasons; nevertheless, the problem of providing a
+viable economic basis, aside from these crude attempts, remains
+unaddressed.
+
+Attribution-based economics is a new model that aims to remedy this
+state of affairs by changing the basis of value from supply and demand
+to <span class="underline">collective recognition</span>. This is facilitated by a process of
+"inheritance attribution" where we collectively agree on the extent of
+inherence of ideas and works in other (e.g. derivative) ideas and
+works, by means of transparent and evolving standards. This model is
+capable of recognizing a much larger set of valuable contributions,
+including forms of value that cannot be coerced into a
+supply-and-demand equation. That is, in this model, there is no need
+to artificially restrict availability in order for something to be
+considered valuable. By virtue of the curious property that
+innovations on the process are themselves subject to the process of
+recognition in a self-reflective way, we gain accuracy, and by the
+property that agreed-upon standards apply equally to all, we gain
+fairness &#x2013; guarantees that are at best tenuously present in today's
+economic systems.
+
+This talk introduces some early experiments with attribution-based
+economics in the Emacs community, and some initial proposals that
+point the way forward on how, with your help, such a system might
+scale up to larger projects and communities far beyond open source.
+
+
+
+[[!inline pages="internal(2022/info/maint-after)" raw="yes"]]
+
+[[!inline pages="internal(2022/info/maint-nav)" raw="yes"]]
+
+[[!taglink CategoryCommunity]]
diff --git a/2022/talks/school.md b/2022/talks/school.md
index c5d1e239..78ce072b 100644
--- a/2022/talks/school.md
+++ b/2022/talks/school.md
@@ -5,9 +5,8 @@
 <!-- Initially generated with emacsconf-generate-talk-page and then left alone for manual editing -->
 <!-- You can manually edit this file to update the abstract, add links, etc. --->
 
-
 # Back to school with Emacs
-Daniel Rösel (ˈrøːzl̩)
+Daniel Rösel (ˈrøːzl̩, IRC: velocitatem, <mailto:daniel@alves.world>, <https://daniel.alves.world>)
 
 [[!inline pages="internal(2022/info/school-before)" raw="yes"]]
 
@@ -30,7 +29,9 @@ Outline:
         -   Show applications in various regions of academics
         -   External input from other users
 
+# Resources
 
+<https://gitlab.com/velocitatem/lectorg>
 
 [[!inline pages="internal(2022/info/school-after)" raw="yes"]]
 
diff --git a/2022/talks/workflows.md b/2022/talks/workflows.md
new file mode 100644
index 00000000..20d082dc
--- /dev/null
+++ b/2022/talks/workflows.md
@@ -0,0 +1,33 @@
+[[!meta title="Org workflows for developers"]]
+[[!meta copyright="Copyright &copy; 2022 George Mauer"]]
+[[!inline pages="internal(2022/info/workflows-nav)" raw="yes"]]
+
+<!-- Initially generated with emacsconf-generate-talk-page and then left alone for manual editing -->
+<!-- You can manually edit this file to update the abstract, add links, etc. --->
+
+
+# Org workflows for developers
+George Mauer (he/him/they/ze)
+
+[[!inline pages="internal(2022/info/workflows-before)" raw="yes"]]
+
+
+# Table of Contents
+
+
+
+We all know org-mode is great but much of the discussion often
+focuses on the agendas, todo lists, and project planning. These are
+all valuable. yet rarely do we talk about workflows that do work, not
+just plan it. Inspired by literate programming ideas, this talk will
+demonstrate a grab-bag of workflows developed over the years that are
+of use not only for planning, tracking, note keeping, and ops work,
+but in actual day-to-day enterprise software development.
+
+
+
+[[!inline pages="internal(2022/info/workflows-after)" raw="yes"]]
+
+[[!inline pages="internal(2022/info/workflows-nav)" raw="yes"]]
+
+[[!taglink CategoryOrgMode]] [[!taglink CategoryCoding]]