add eval, hyperamp, poltys, table, test, unentangling

1 files changed, 77 insertions, 0 deletions

diff --git a/2023/talks/unentangling.md b/2023/talks/unentangling.md
new file mode 100644
index 00000000..4f0764ab
--- /dev/null
+++ b/2023/talks/unentangling.md
@@ -0,0 +1,77 @@
+[[!meta title="(Un)entangling projects and repos"]]
+[[!meta copyright="Copyright © 2023 Alexey Bochkarev"]]
+[[!inline pages="internal(2023/info/unentangling-nav)" raw="yes"]]
+
+<!-- Initially generated with emacsconf-publish-talk-page and then left alone for manual editing -->
+<!-- You can manually edit this file to update the abstract, add links, etc. --->
+
+
+# (Un)entangling projects and repos
+Alexey Bochkarev (he/him) - <https://www.bochkarev.io>, @bochkarev@qoto.org (Mastodon)
+
+[[!inline pages="internal(2023/info/unentangling-before)" raw="yes"]]
+
+Emacs provides a few excellent tools for working on projects through
+all their key stages. Orgmode is great for brainstorming, structuring
+and maintaining TODO lists, tracking time, organizing notes, and
+writing memos or reports. Many major modes help writing code, magit
+makes version control almost frictionless, and projectile helps with
+project management and navigation. However, I found a few situations
+when I wanted to separate the concepts of "project" and "source
+storage" (say, having a few version control repositories associated
+with a single "generalized project").
+
+In this talk, I would like:
+
+1.  to describe a specific example of such situation,
+
+2.  discuss a workflow aimed at managing such "generalized" projects
+and present my solution, based on a very simple ELisp "glue" on top of
+the functionality provided by package projectile.
+
+For example, consider a research project (think: applied mathematics with
+a heavy part of computational experiments). It might consist of:
+
+-   The \`\`paper'' draft: some sort of final report source, usually in
+    LaTeX format, or orgmode exported to PDF via LaTeX. Version controlled
+    by git.
+
+-   Numerical experiments: a separate folder, or even a separate git
+    repo. Contains the source code for numerical experiments and the
+    related technical documentation. Will be published along with the
+    paper.
+
+-   A collection of intermediate memos (notes) sent to collaborators.
+
+-   A collection of "raw" notes (lab journal), regarding what did I try
+    and especially what did NOT work and in which ways.
+
+This setting raises a few problems that all boil down to the necessity
+of having an easily accessible private notes file(s) associated with a
+few repositories at the same time outside of these repos. This way one
+can:
+
+-   Maintain more granular project structure and TODOs while still having
+more concise TODO lists for the colleagues on a per-repository basis.
+
+-   Maintain (project-specific) private technical notes, and maybe a full
+    lab journal both describing the "big picture" of the project and
+    containing the technical information.
+
+-   Keep time tracking data private and outside of the source repositories,
+
+-   Capture thoughts and TODOs to a single place from across a few
+    specific repositories.
+
+I propose to solve this problem by associating a single "notes folder"
+and a main `.org` file to each repository using the standard mechanism
+of directory-local variables on top of what is already provided by
+projectile package.
+
+
+
+[[!inline pages="internal(2023/info/unentangling-after)" raw="yes"]]
+
+[[!inline pages="internal(2023/info/unentangling-nav)" raw="yes"]]
+
+