path: root/2024/captions/emacsconf-2024-org-update--the-future-of-org--ihor-radchenko--main.vtt

WEBVTT captioned by sachac

NOTE Introduction

00:00:00.000 --> 00:00:03.039
Hello, everyone. My name is Ihor Radchenko,

00:00:03.040 --> 00:00:07.319
and I'm the new official Org Mode maintainer.

00:00:07.320 --> 00:00:09.679
Today, I'll briefly introduce myself

00:00:09.680 --> 00:00:12.319
and then share my ideas about the future of

00:00:12.320 --> 00:00:16.039
Org Mode development. I will start by passing

00:00:16.040 --> 00:00:18.759
the word from Bastien, the previous maintainer.

00:00:18.760 --> 00:00:22.239
Then I will tell you a little bit about my story,

00:00:22.240 --> 00:00:24.119
starting from ordinary Org Mode user

00:00:24.120 --> 00:00:26.039
all the way to the maintainer.

00:00:26.040 --> 00:00:30.839
Then I will detail the new directions of development

00:00:30.840 --> 00:00:33.599
and specific features which I want to see

00:00:33.600 --> 00:00:35.799
in Org Mode in the coming years.

00:00:35.800 --> 00:00:39.659
And I will conclude by asking you, Org Mode users,

00:00:39.660 --> 00:00:42.399
to contribute to Org Mode

00:00:42.400 --> 00:00:46.759
because all the features which are too many

00:00:46.760 --> 00:00:49.259
can only be implemented with the help of the community,

00:00:49.260 --> 00:00:51.879
with the help of more contributors.

00:00:51.880 --> 00:00:53.579
And for that, of course, I will also talk

00:00:53.580 --> 00:00:59.479
about Org community and how I see it evolve

00:00:59.480 --> 00:01:01.199
so that we have a good communication

00:01:01.200 --> 00:01:03.039
between the development of Org Mode

00:01:03.040 --> 00:01:07.559
and the community ideas.

00:01:07.560 --> 00:01:14.279
Let me first pass the word to Bastien.

NOTE Message from Bastien Guerry

00:01:14.280 --> 00:01:17.599
Hello, everyone. Ihor Radchenko is the new Org Mode

00:01:17.600 --> 00:01:18.519
maintainer.

00:01:18.520 --> 00:01:21.039
He's been acting as such for a couple of years now,

00:01:21.040 --> 00:01:23.479
and I'm really glad he's finally agreed to take on the

00:01:23.480 --> 00:01:26.439
role officially. As a maintainer, I've probably done

00:01:26.440 --> 00:01:29.439
a few things right and certainly made many mistakes.

00:01:29.440 --> 00:01:32.319
Here are 4 lessons I've learned in 14 years.

00:01:32.320 --> 00:01:34.319
The first is that maintaining Org Mode

00:01:34.320 --> 00:01:36.439
isn't just about code, it's mostly

00:01:36.440 --> 00:01:40.679
about users. Of course, some of them will never learn how to

00:01:40.680 --> 00:01:43.159
report a bug, some of them will behave like spoiled

00:01:43.160 --> 00:01:46.319
children, and most of them will expect you to work for free

00:01:46.320 --> 00:01:50.439
forever. Nevertheless, the time is as valuable as yours.

00:01:50.440 --> 00:01:53.639
Whatever they request, there is always something that can

00:01:53.640 --> 00:01:57.879
lead to a positive outcome for Org Mode or its community.

00:01:57.880 --> 00:02:00.719
The second lesson is that maintenance isn't just about

00:02:00.720 --> 00:02:04.239
technical choices. It's also about predictability.

00:02:04.240 --> 00:02:07.879
Be very clear and very loud about what users and contributors

00:02:07.880 --> 00:02:11.159
can expect of your time, skills, and motivations.

00:02:11.160 --> 00:02:12.879
Stick to the robustness principle

00:02:12.880 --> 00:02:15.719
by being liberal in what you accept

00:02:15.720 --> 00:02:19.319
and strict in what you produce. Thirdly, it's all

00:02:19.320 --> 00:02:22.319
about learning. Let's build a culture together where it's

00:02:22.320 --> 00:02:25.719
okay to ask stupid questions. No one is born knowing how to

00:02:25.720 --> 00:02:28.639
write in English, how to report a bug, or how to maintain a

00:02:28.640 --> 00:02:32.059
large piece of code. Remember that old-timers were newbies

00:02:32.060 --> 00:02:35.199
and that newbies could become maintainers. We all have a lot

00:02:35.200 --> 00:02:38.759
to learn, even if it's just how to respect each other.

00:02:38.760 --> 00:02:42.239
Finally, as a maintainer, think about the next one. Who will

00:02:42.240 --> 00:02:45.519
be in your shoes next? What kind of maintainer do you want for

00:02:45.520 --> 00:02:48.839
a software you will be using for decades? It's also a

00:02:48.840 --> 00:02:52.159
responsibility of the Org Mode community. How can we

00:02:52.160 --> 00:02:55.999
collectively attract maintainers that want to help us use

00:02:56.000 --> 00:02:59.359
and enhance this wonderful little tool? How can we,

00:02:59.360 --> 00:03:02.199
as Org Mode users, help Ihor pave the way

00:03:02.200 --> 00:03:04.399
for the next maintainers?

00:03:04.400 --> 00:03:08.279
Enough said. I'm confident Org Mode is in good hands and I'm a very

00:03:08.280 --> 00:03:11.559
happy user. Thanks everyone for all these years of fun and

00:03:11.560 --> 00:03:15.919
learning.

NOTE My step-by-step journey to Org maintenance

00:03:15.920 --> 00:03:20.279
Now back to my talk. Let me start by briefly introducing

00:03:20.280 --> 00:03:23.959
myself. I'm actually not a programmer. By training, I'm a

00:03:23.960 --> 00:03:27.519
material scientist. and I only started using Emacs and

00:03:27.520 --> 00:03:30.719
Org Mode and naturally doing programming (because that's

00:03:30.720 --> 00:03:36.799
Emacs) when I was doing my PhD and I wanted to use Org Mode to

00:03:36.800 --> 00:03:40.479
tame my research work. A couple of years I was just an

00:03:40.480 --> 00:03:44.599
ordinary user, until I learned enough and

00:03:44.600 --> 00:03:48.463
got enough courage to report my first bug.

00:03:48.464 --> 00:03:51.639
Then it all evolved over the years.

00:03:51.640 --> 00:03:53.959
I started participating in the mailing list,

00:03:53.960 --> 00:03:56.559
I started learning more about Elisp,

00:03:56.560 --> 00:03:59.839
I reported more complex bugs,

00:03:59.840 --> 00:04:08.879
I eventually got around to go and fix the tricky bugs.

00:04:08.880 --> 00:04:11.719
Then I started participating more in Org mailing list

00:04:11.720 --> 00:04:16.919
in helping fixing bugs in selected areas of Org

00:04:16.920 --> 00:04:22.839
mode and eventually switching to all parts of Org.

00:04:22.840 --> 00:04:27.639
At some point I ended up doing the de facto maintenance job

00:04:27.640 --> 00:04:32.679
together with Bastien and got an actual maintenance offer

00:04:32.680 --> 00:04:38.599
which I accepted recently. The key takeaway I want you to get

00:04:38.600 --> 00:04:40.999
from here is that you don't have to be a programmer, you don't

00:04:41.000 --> 00:04:47.239
have to know Elisp to contribute, and you don't even have to

00:04:47.240 --> 00:04:51.439
be like that to become a maintainer. All it takes is

00:04:51.440 --> 00:04:55.279
slow, methodical, persistent learning over the years,

00:04:55.280 --> 00:04:58.499
participating in the community, and eventually

00:04:58.500 --> 00:05:02.399
submitting your patches upstream. And eventually you can

00:05:02.400 --> 00:05:07.679
become a maintainer, or not a maintainer as you wish.

00:05:07.680 --> 00:05:09.240
Enough about me.

NOTE Priorities for Org maintenance

00:05:09.241 --> 00:05:13.359
Let's talk about what I think should happen with

00:05:13.360 --> 00:05:18.859
Org Mode and what my goals on Org Mode is. The first and top

00:05:18.860 --> 00:05:25.199
priority for me is the basics. The basics, the

00:05:25.200 --> 00:05:26.069
code-based stability.

00:05:26.070 --> 00:05:29.719
Basically, all the foundations, all the APIs in

00:05:29.720 --> 00:05:34.959
Org Mode, all the basic libraries, which everything builds

00:05:34.960 --> 00:05:39.079
upon so that we have fewer bugs and we have more

00:05:39.080 --> 00:05:42.599
understandable code so that others who want to contribute

00:05:42.600 --> 00:05:44.651
have easier time understanding

00:05:44.652 --> 00:05:46.371
what is going on in the code base and

00:05:46.372 --> 00:05:52.259
contribute without much of a problem or confusion.

00:05:52.260 --> 00:05:56.339
Second equally important direction is the Org community,

00:05:56.340 --> 00:06:00.579
because a single person, even a couple of people, cannot

00:06:00.580 --> 00:06:05.599
really develop such a big project as Org Mode. And we always

00:06:05.600 --> 00:06:08.439
want new contributors, which are not coming from nowhere.

00:06:08.440 --> 00:06:10.228
We need to have the community of users.

00:06:10.229 --> 00:06:12.199
We have a community of

00:06:12.200 --> 00:06:15.679
people who participate in discussions, who later submit

00:06:15.680 --> 00:06:19.719
patches and code, and that's where we get most of the new

00:06:19.720 --> 00:06:24.919
features. So I would like to improve the communication

00:06:24.920 --> 00:06:29.879
between Org community and the development. The third

00:06:29.880 --> 00:06:34.259
direction I want to pursue is making life easier for

00:06:34.260 --> 00:06:38.639
third-party packages. Because we don't only have org-mode

00:06:38.640 --> 00:06:41.319
as it's distributed with Emacs. We have a lot of

00:06:41.320 --> 00:06:45.196
ELPA packages. We have a lot of MELPA packages.

00:06:45.197 --> 00:06:47.917
People who want some specific features

00:06:47.918 --> 00:06:49.839
on top of org-mode do develop

00:06:49.840 --> 00:06:54.279
these packages which are widely used or not so widely used.

00:06:54.280 --> 00:06:57.639
It's not only about Emacs. We have a lot of mobile apps

00:06:57.640 --> 00:07:01.879
that can work with Org files, have a lot of parsers which

00:07:01.880 --> 00:07:06.039
enable this mobile apps, or in general, programs outside

00:07:06.040 --> 00:07:11.019
Elisp to understand Org files.

00:07:11.020 --> 00:07:14.959
Fourth direction is the Org markup as a foundation of

00:07:14.960 --> 00:07:18.319
org-mode as a major mode, because we have a lot of

00:07:18.320 --> 00:07:20.573
functionality in org-mode itself inside Emacs,

00:07:20.574 --> 00:07:23.674
but it's all based on the underlying markup,

00:07:23.675 --> 00:07:27.435
and markup should have enough features

00:07:27.436 --> 00:07:32.479
to support the functions we want to see there.

00:07:32.480 --> 00:07:34.919
Last direction, which is somewhat less

00:07:34.920 --> 00:07:37.834
important, mostly because I don't have

00:07:37.835 --> 00:07:40.136
that much time to focus on everything,

00:07:40.137 --> 00:07:44.159
is the new features. I do want to see

00:07:44.160 --> 00:07:46.840
certain important features in Org mode,

00:07:46.841 --> 00:07:50.262
but I usually cannot spend too much time on them

00:07:50.263 --> 00:07:53.084
because of the previous more important parts.

00:07:53.085 --> 00:07:54.999
I do rely on the org community and

00:07:55.000 --> 00:07:57.456
the contributors to implement these new features.

00:07:57.457 --> 00:08:01.915
My idea is that I want to direct which features

00:08:01.916 --> 00:08:03.757
and how they should be implemented,

00:08:03.758 --> 00:08:05.299
but the actual people who implement

00:08:05.300 --> 00:08:09.463
them should come from the community.

00:08:09.464 --> 00:08:11.766
Now let's go into the details.

NOTE Modular Org

00:08:11.767 --> 00:08:15.719
The code base. As a bit of motivation, I would like

00:08:15.720 --> 00:08:19.279
to share this email from Richard Stallman, who a couple of

00:08:19.280 --> 00:08:27.039
years ago asked about improving Org mode by making it

00:08:27.040 --> 00:08:32.839
more modular. That's directly asking about improving the

00:08:32.840 --> 00:08:35.639
foundations of the code. That's what I think is

00:08:35.640 --> 00:08:41.589
an important direction as well. Here's an example.

NOTE Slim down large Org libraries

00:08:41.590 --> 00:08:45.312
We have a lot of really, really large org libraries,

00:08:45.313 --> 00:08:49.376
like org.el, which is like one megabyte or something large,

00:08:49.377 --> 00:08:51.558
org-agenda, org-table, org-list,

00:08:51.559 --> 00:08:52.879
a number of files which are really,

00:08:52.880 --> 00:08:56.599
really, really large. What is worse is they are hard to

00:08:56.600 --> 00:09:00.906
understand sometimes. I even have an example,

00:09:00.907 --> 00:09:04.505
alphapapa complained that part of his motivation

00:09:04.506 --> 00:09:07.867
to write org-ql and specifically his agenda part,

00:09:07.868 --> 00:09:08.879
agenda-like part, was

00:09:08.880 --> 00:09:13.119
because org-agenda is so hard to understand that it's

00:09:13.120 --> 00:09:15.572
easier to start from scratch.

00:09:15.573 --> 00:09:17.079
I don't want such situations

00:09:17.080 --> 00:09:20.374
to happen in future, if possible at all.

00:09:20.375 --> 00:09:21.879
One of the projects

00:09:21.880 --> 00:09:23.116
I'm currently working on,

00:09:23.117 --> 00:09:25.100
it's work in progress now,

00:09:25.101 --> 00:09:28.437
is splitting Org libraries into smaller parts,

00:09:28.438 --> 00:09:31.808
into more documented parts,

00:09:31.809 --> 00:09:34.239
into the APIs which are actually

00:09:34.240 --> 00:09:38.470
documented and explained in the code at least,

00:09:38.471 --> 00:09:42.571
so that people who just open org-mode code

00:09:42.572 --> 00:09:45.239
cannot be scared away and go and

00:09:45.240 --> 00:09:47.999
read the comments and understand what is happening there

00:09:48.000 --> 00:09:52.039
easier. At this point, I have almost doubled the number of

00:09:52.040 --> 00:09:54.839
libraries. It's still work in progress, so there's a lot of

00:09:54.840 --> 00:09:59.999
room for improvement in this area.

NOTE Upstream generic Org libraries

00:10:00.000 --> 00:10:04.599
Another direction which is

00:10:04.600 --> 00:10:09.799
somewhat reasonable in relation to splitting things down

00:10:09.800 --> 00:10:15.159
is that some libraries are really generic in Org Mode,

00:10:15.160 --> 00:10:18.239
because Org Mode often has a functionality

00:10:18.240 --> 00:10:20.100
which is really new, and for that,

00:10:20.101 --> 00:10:22.239
it had to implement some very generic

00:10:22.240 --> 00:10:24.222
functionality that doesn't have to be used

00:10:24.223 --> 00:10:24.903
just for Org Mode.

00:10:24.904 --> 00:10:27.924
This can be generalized for Emacs in general.

00:10:27.925 --> 00:10:29.645
There is a number of libraries

00:10:29.646 --> 00:10:32.999
which we may or may not upstream to

00:10:33.000 --> 00:10:37.559
Emacs, depending on what Emacs maintain, I think. As one

00:10:37.560 --> 00:10:40.719
example is org-capture, because it's a very obvious

00:10:40.720 --> 00:10:43.679
example. org-capture started as support from remember.el,

00:10:43.680 --> 00:10:46.759
which is still a part of Emacs. It has more features than

00:10:46.760 --> 00:10:50.039
remember.el, which we required for Org. But, you know,

00:10:50.040 --> 00:10:55.139
these features can be backported. Why not? And then

00:10:55.140 --> 00:10:58.679
not only Org-mode, but other Emacs libraries can benefit

00:10:58.680 --> 00:11:01.957
from these features we have in Org-mode only.

00:11:01.958 --> 00:11:04.739
Similarly, I have a long list of

00:11:04.740 --> 00:11:12.039
different libraries that can be shared.

00:11:12.040 --> 00:11:14.004
Yeah, for some I'm not sure,

00:11:14.005 --> 00:11:18.959
but in general, there is a lot of

00:11:18.960 --> 00:11:25.399
work that may be done and may be discussed in the future.

NOTE Use modern Emacs APIs and libraries

00:11:25.400 --> 00:11:31.479
The third part about the basics is making use of the new Emacs

00:11:31.480 --> 00:11:36.039
libraries. Org Mode in general is quite well written in terms

00:11:36.040 --> 00:11:40.039
of Emacs integration. We do support many of the Emacs

00:11:40.040 --> 00:11:44.359
features and libraries which are generic. However, in more

00:11:44.360 --> 00:11:47.999
recent Emacs versions, we started getting some new

00:11:48.000 --> 00:11:50.799
features, and we do want to make use of them in Org.

00:11:50.800 --> 00:11:55.879
For example, recently we contributed yank-media support for

00:11:55.880 --> 00:12:00.359
clipboard pasting and drag and drop. Now it is supported

00:12:00.360 --> 00:12:04.399
in Org mode already in the released version. Eventually

00:12:04.400 --> 00:12:08.359
we want to support transient.el, because now Org uses ad hoc

00:12:08.360 --> 00:12:11.999
system. It's of course much better to use existing and

00:12:12.000 --> 00:12:14.839
more powerful menus, which are implemented in

00:12:14.840 --> 00:12:18.159
transient. It even has some initial work-in-progress

00:12:18.160 --> 00:12:20.028
implementation. I hope it can be eventually

00:12:20.029 --> 00:12:23.960
extended to the whole Org Mode

00:12:23.961 --> 00:12:29.359
There are other things like compatibility, which there is

00:12:29.360 --> 00:12:33.519
an excellent Emacs library, compat.el, that provides

00:12:33.520 --> 00:12:37.599
backwards compatibility and Org also has something like this

00:12:37.600 --> 00:12:39.439
in org-compat. We don't have to write it ourself again.

00:12:39.440 --> 00:12:43.741
We can make use of the existing library.

00:12:43.742 --> 00:12:46.043
Similarly, there's a very, very new library

00:12:46.044 --> 00:12:48.759
track-changes for tracking changes

00:12:48.760 --> 00:12:53.159
in real time. Eventually, if you want to support

00:12:53.160 --> 00:12:56.359
context-menu mode, maybe touchscreen, Android

00:12:56.360 --> 00:13:00.999
support, I don't know, but I hope it can be done by someone.

00:13:01.000 --> 00:13:09.319
And some more generic library: select thingatpt.

00:13:09.320 --> 00:13:13.256
That's about using external APIs.

NOTE Improve Org parser APIs

00:13:13.257 --> 00:13:18.557
Now about the internal Org APIs.

00:13:18.558 --> 00:13:19.439
One important, probably one of the most important

00:13:19.440 --> 00:13:23.259
parts of Org is the parser, how Org itself understands the

00:13:23.260 --> 00:13:27.159
Org files. The situation is that we have two parsers in

00:13:27.160 --> 00:13:30.999
Org mode. One is the Org element, the proper parser, which we

00:13:31.000 --> 00:13:34.519
use as a reference, but many parts of Org still use regular

00:13:34.520 --> 00:13:38.079
expressions, which are approximate. These two parsers

00:13:38.080 --> 00:13:41.839
are not exactly consistent, which is really bad, and I hope

00:13:41.840 --> 00:13:47.999
to solve this. I already started doing some work by

00:13:48.000 --> 00:13:54.140
factoring out some part of abstract syntax tree and working

00:13:54.141 --> 00:13:57.519
on real-time parser, incremental parser, which is enabled

00:13:57.520 --> 00:14:00.039
by default in Org 9.6, but there are still parts which I need

00:14:00.040 --> 00:14:02.999
to work on. Eventually I want to get rid of regular

00:14:03.000 --> 00:14:05.439
expression-based parser completely, so that we don't have

00:14:05.440 --> 00:14:10.199
any inconsistencies inside Org Mode. One of the examples of

00:14:10.200 --> 00:14:13.159
these parts that are still using regular expression is

00:14:13.160 --> 00:14:16.719
fontification, which is often simply wrong, especially in

00:14:16.720 --> 00:14:21.639
some edge cases, and we really want to use the proper parser

00:14:21.640 --> 00:14:27.559
in this area. Maybe even editing org files using the parser

00:14:27.560 --> 00:14:31.799
syntax tree, but that might be tricky, although there is an

00:14:31.800 --> 00:14:38.119
existing library that implements some ideas for this.

00:14:38.120 --> 00:14:41.519
The key point is that org-element-api, the parser, should

00:14:41.520 --> 00:14:42.749
eventually be used everywhere

00:14:42.750 --> 00:14:45.730
so that everything is consistent.

NOTE Improve Org babel APIs

00:14:45.731 --> 00:14:50.359
The second important API is the Org babel.

00:14:50.360 --> 00:14:54.414
Currently, Org babel does have some API,

00:14:54.415 --> 00:14:56.195
but first, it's not well documented.

00:14:56.196 --> 00:14:59.039
Second, it's sometimes awkwardly

00:14:59.040 --> 00:15:04.819
designed, especially compared with the exporter.

00:15:04.820 --> 00:15:11.419
I do want Org Babel APIs to be more consistent.

00:15:11.420 --> 00:15:14.879
Another thing about Org Babel, it's not exactly API, but you

00:15:14.880 --> 00:15:18.259
know that documentation for most of the Babel backends are

00:15:18.260 --> 00:15:20.879
not even in the Org manual, even though the backends are

00:15:20.880 --> 00:15:25.559
built-in. They are on Org Wiki, and we do want to move them to

00:15:25.560 --> 00:15:29.919
the manual eventually. That's the important part, and it

00:15:29.920 --> 00:15:34.519
should be done. Those are some obstacles, like not all the

00:15:34.520 --> 00:15:39.399
features are properly implemented, and that's a bit of an

00:15:39.400 --> 00:15:43.159
extra job that should be done. Another small thing which

00:15:43.160 --> 00:15:48.079
thanks to Bruno Barbier is being done, in progress: we

00:15:48.080 --> 00:15:51.599
should have a more robust asynchronous API for babel.

00:15:51.600 --> 00:15:53.600
I hope it can progress further.

00:15:53.601 --> 00:15:57.379
For now, it already progressed quite far.

NOTE Beyond Org code and Emacs: third-party packages, apps, parsers

00:15:57.380 --> 00:15:59.959
That's all about the basics, the underlying

00:15:59.960 --> 00:16:04.799
backbone of the Org codebase. Let's move to the second

00:16:04.800 --> 00:16:09.519
important direction which is

00:16:09.520 --> 00:16:13.739
the third-party packages and basically the parsers

00:16:13.740 --> 00:16:18.279
for mobile apps. I will postpone the community to the end

00:16:18.280 --> 00:16:23.919
because I want to have a call for contribution at the end.

00:16:23.920 --> 00:16:31.199
For third-party packages, I would like to remind you that

NOTE org-contrib

00:16:31.200 --> 00:16:34.239
Org mode used to have something called org-contrib as a

00:16:34.240 --> 00:16:39.799
part of Org mode, which is a collection of small libraries,

00:16:39.800 --> 00:16:44.079
small packages that didn't have a proper

00:16:44.080 --> 00:16:45.495
copyright assignment basically,

00:16:45.496 --> 00:16:49.359
but more or less a part of Org mode. This is

00:16:49.360 --> 00:16:52.119
no longer the case. Now what we did is

00:16:52.120 --> 00:16:56.641
we moved a number of very rarely used libraries

00:16:56.642 --> 00:16:58.759
from Org core itself to org-contrib,

00:16:58.760 --> 00:17:03.779
and now we treat org-contrib as basically the libraries

00:17:03.780 --> 00:17:08.020
that we really want someone to take responsibility for.

00:17:08.021 --> 00:17:10.580
We want to maintain this for everything that is in

00:17:10.581 --> 00:17:18.079
org-contrib, and from me and other Org team, we

00:17:18.080 --> 00:17:21.162
do not spend too much time maintaining this package,

00:17:21.163 --> 00:17:25.286
just do some most basic bug fixing, and that's all.

00:17:25.287 --> 00:17:27.359
If you know, if you see

00:17:27.360 --> 00:17:30.031
some libraries from org-contrib and you use them,

00:17:30.032 --> 00:17:31.991
and you know Elisp, please volunteer to be

00:17:31.992 --> 00:17:34.454
the maintainer, because otherwise

00:17:34.455 --> 00:17:37.819
there will be not much progress in these libraries.

NOTE Org orphanage

00:17:37.820 --> 00:17:40.719
As a natural extension of this and inspired by

00:17:40.720 --> 00:17:46.199
Tarsius's Emacs Orphanage idea, we also maintain a small

00:17:46.200 --> 00:17:50.359
page basically listing the libraries, some others like

00:17:50.360 --> 00:17:55.439
packages, Emacs packages that are not really maintained.

00:17:55.440 --> 00:17:59.239
If you are a maintainer of a library and you don't have time

00:17:59.240 --> 00:18:02.507
to do it, you can write to Org mailing list

00:18:02.508 --> 00:18:05.209
and we can add the library to this page

00:18:05.210 --> 00:18:09.918
so that we can search for new maintainers

00:18:09.919 --> 00:18:12.839
in a more centralized way. If you are an

00:18:12.840 --> 00:18:18.119
Elisp hacker and you want to help something for Org Mode,

00:18:18.120 --> 00:18:25.839
you can check that page and see where you can help.

NOTE Mobile apps and parsers

00:18:25.840 --> 00:18:29.879
Now away from Emacs, or mobile apps.

00:18:29.880 --> 00:18:33.948
We have quite a lot of mobile apps at this point.

00:18:33.949 --> 00:18:35.759
Unfortunately, it's very hard

00:18:35.760 --> 00:18:42.459
for me and many other Elisp contributors to contribute to

00:18:42.460 --> 00:18:46.759
these apps because they are not using Elisp naturally. But

00:18:46.760 --> 00:18:52.359
these applications heavily rely on Org markup. I do hope

00:18:52.360 --> 00:18:55.799
that we can keep Org markup consistent enough and rich

00:18:55.800 --> 00:19:00.599
enough so that people don't have to invent extensions to Org

00:19:00.600 --> 00:19:06.020
like what happened to Markdown.

00:19:06.021 --> 00:19:09.542
I really want to emphasize that

00:19:09.543 --> 00:19:12.359
I want to see more Org parsers in different

00:19:12.360 --> 00:19:13.739
languages so that they can be used by developers.

00:19:13.740 --> 00:19:24.185
For people who are writing these parsers,

00:19:24.186 --> 00:19:27.267
I want to share this link. It is the org-syntax reference.

00:19:27.268 --> 00:19:29.368
It is the official Org syntax,

00:19:29.369 --> 00:19:33.631
which is what we think it should be.

00:19:33.632 --> 00:19:36.212
It's described in plain human language.

00:19:36.213 --> 00:19:39.855
It's not a code. All details should be listed there.

00:19:39.856 --> 00:19:43.557
Please use it as a reference if you are writing a parser.

00:19:43.558 --> 00:19:45.118
Eventually, this document will be

00:19:45.119 --> 00:19:51.672
submitted to IETF, I hope. In the future

00:19:51.673 --> 00:19:56.059
I hope to write a set of tests which will work as benchmarks.

00:19:56.060 --> 00:19:58.839
basically we have some existing tests for our internal

00:19:58.840 --> 00:20:04.319
parser and I want to factor out these tests so they can be used

00:20:04.320 --> 00:20:07.359
by any parser, so that we can compare the performance and

00:20:07.360 --> 00:20:14.579
which parts of Org mode are parsed and which parts are not.

00:20:14.580 --> 00:20:18.999
I mentioned that we want to submit to IETF, which means that

00:20:19.000 --> 00:20:23.868
Org markup will become the actual registered format.

NOTE Long-standing syntax problems

00:20:23.869 --> 00:20:31.279
But before we do that and thus fix Org markup in stone,

00:20:31.280 --> 00:20:34.614
because it's very hard to change things in the IETF,

00:20:34.615 --> 00:20:38.836
it's important to address important problems,

00:20:38.837 --> 00:20:41.217
existing problems with Org syntax.

00:20:41.218 --> 00:20:43.639
There are some problems, like I mentioned the

00:20:43.640 --> 00:20:46.941
inconsistencies between the two existing parsers

00:20:46.942 --> 00:20:51.407
in Org mode. There are also some parts,

00:20:51.408 --> 00:20:53.149
there are some examples, like there are

00:20:53.150 --> 00:20:54.799
problems with numeric priorities, for

00:20:54.800 --> 00:20:58.719
example, which are not treated consistently. There are

00:20:58.720 --> 00:21:02.599
problems, more general problems with syntax when people

00:21:02.600 --> 00:21:07.239
request some edge cases which should be addressed. Like,

00:21:07.240 --> 00:21:10.101
it's very hard to do interword markup.

00:21:10.102 --> 00:21:13.701
We have zero-width space workaround, but many people dislike it,

00:21:13.702 --> 00:21:16.262
so maybe we want to do something about it.

00:21:16.263 --> 00:21:18.079
We have some edge cases when we

00:21:18.080 --> 00:21:22.119
combine emphasis with links. We have some edge cases when we

00:21:22.120 --> 00:21:24.959
have double blank lines inside some source blocks, for

00:21:24.960 --> 00:21:30.079
example, and combination in the list. I hope we can

00:21:30.080 --> 00:21:33.399
somehow address it. It's not impossible to do it, it just

00:21:33.400 --> 00:21:38.919
requires time. One annoying part is the inline task syntax.

00:21:38.920 --> 00:21:41.479
It's annoying both from the programming perspective,

00:21:41.480 --> 00:21:43.919
internally as implementation, and from the UI

00:21:43.920 --> 00:21:47.519
perspective, because there are too many stars. We

00:21:47.520 --> 00:21:50.479
probably should redesign it eventually, maybe in

00:21:50.480 --> 00:21:56.239
backwards-compatible way, but we will see how it goes.

NOTE New syntax features

00:21:56.240 --> 00:22:00.639
Another part is not just fixing the edge cases or problems,

00:22:00.640 --> 00:22:04.039
it's the completely new syntax features. That's probably

00:22:04.040 --> 00:22:07.959
done after we submit to IETF. But there are important things

00:22:07.960 --> 00:22:11.119
that people often request, like time zone support in

00:22:11.120 --> 00:22:15.919
timestamps. Better repeaters, like more flexible

00:22:15.920 --> 00:22:21.799
repeaters, that's really a frequent request also.

00:22:21.800 --> 00:22:28.919
Another idea is some custom markup, which is

00:22:28.920 --> 00:22:31.939
coming to various requests, like, for example, people

00:22:31.940 --> 00:22:37.887
often ask to highlight some words with a color,

00:22:37.888 --> 00:22:40.890
for example, or with some other special way

00:22:40.891 --> 00:22:43.333
and then export it in a special way,

00:22:43.334 --> 00:22:47.239
just as we do with special blocks, basically.

00:22:47.240 --> 00:22:51.061
What I want to introduce is the ability to do it

00:22:51.062 --> 00:22:54.601
on a macro level or inline.

00:22:54.602 --> 00:22:57.879
Of course, a new syntax feature which I wish we could

00:22:57.880 --> 00:23:01.064
have is the multi-line cells in tables.

00:23:01.065 --> 00:23:02.545
It's very frequently requested as well,

00:23:02.546 --> 00:23:07.007
but I really have no clue how to do it.

00:23:07.008 --> 00:23:09.239
We had a discussion about this in previous

00:23:09.240 --> 00:23:13.359
discussions, but there was no conclusion. We don't see a

00:23:13.360 --> 00:23:16.155
good way how to implement it syntax-wise.

00:23:16.156 --> 00:23:19.140
Unlike time zones where we decided exactly the syntax,

00:23:19.141 --> 00:23:22.665
how it could be and we just need patches to be submitted,

00:23:22.666 --> 00:23:25.610
here even the idea of syntax is not clear.

00:23:25.611 --> 00:23:26.771
Please do participate in these discussions

00:23:26.772 --> 00:23:30.502
if you have ideas.

NOTE New features I hope to see in Org

00:23:30.503 --> 00:23:32.519
The last direction is the

00:23:32.520 --> 00:23:36.319
new features. In general, I welcome all kinds of good

00:23:36.320 --> 00:23:39.559
features, but there are certain things which I explicitly

00:23:39.560 --> 00:23:43.919
want to see and I hope to see submitted. If you are

00:23:43.920 --> 00:23:48.559
interested, please do submit patches. One, and probably

00:23:48.560 --> 00:23:50.799
many people are aware about it, is the asynchronous LaTeX

00:23:50.800 --> 00:23:55.319
preview, developed by Timothy and Karthik. I hope it can be

00:23:55.320 --> 00:23:59.279
finalized eventually and upstreamed. It's pretty much in

00:23:59.280 --> 00:24:02.319
ready state, but on the technical level it should be

00:24:02.320 --> 00:24:09.879
discussed further and revised. The second is org-ql by Adam.

00:24:09.880 --> 00:24:17.239
I hope it can be upstreamed. It's also a work in progress.

00:24:17.240 --> 00:24:20.519
It's just a question of free time for Adam mostly, I think,

00:24:20.520 --> 00:24:26.199
and me. That's another important part, new feature. The

00:24:26.200 --> 00:24:30.239
third is the so-called multi-page export. The idea is the

00:24:30.240 --> 00:24:34.319
same as many packages for blog posts, so that you have a

00:24:34.320 --> 00:24:39.479
single Org file and then you can export multiple HTML pages,

00:24:39.480 --> 00:24:42.599
for example, or PDF pages, anything like that. This work in

00:24:42.600 --> 00:24:46.687
progress by Orm, thanks to him,

00:24:46.688 --> 00:24:49.349
although it was a little bit stuck because

00:24:49.350 --> 00:24:52.079
I am not exactly sure how to best integrate it

00:24:52.080 --> 00:24:56.879
into the existing APIs. If you are a developer of one of the

00:24:56.880 --> 00:25:01.079
blogging packages, I would appreciate if you can chime in

00:25:01.080 --> 00:25:06.479
and probably share some ideas here. Next are just some

00:25:06.480 --> 00:25:09.839
wishes I wish we could have, but

00:25:09.840 --> 00:25:11.949
it's not very detailed. One is

00:25:11.950 --> 00:25:14.159
the multi-language support, so that we can have Org

00:25:14.160 --> 00:25:16.879
documents in multiple languages, or maybe even

00:25:16.880 --> 00:25:21.159
translations. The collaborative editing that many

00:25:21.160 --> 00:25:25.359
people would wish to have, I think. Things like tracking

00:25:25.360 --> 00:25:28.999
changes, adding comments, importing from

00:25:29.000 --> 00:25:30.874
some other Org formats with

00:25:30.875 --> 00:25:32.035
the comments and changes

00:25:32.036 --> 00:25:34.018
so that we can actually participate

00:25:34.019 --> 00:25:36.962
with all those Microsoft Word users

00:25:36.963 --> 00:25:39.743
and stuff like that.

00:25:39.744 --> 00:25:43.719
But that's really too much for me alone to handle.

00:25:43.720 --> 00:25:47.839
If you want to see one of these features, please consider

00:25:47.840 --> 00:25:50.039
contributing. Just write the mailing list about your

00:25:50.040 --> 00:25:54.072
interest and we can start from there.

NOTE Org community

00:25:54.073 --> 00:25:57.455
Now, the important part is, you see,

00:25:57.456 --> 00:25:58.635
I keep asking people like,

00:25:58.636 --> 00:25:59.799
please contribute, please contribute,

00:25:59.800 --> 00:26:01.357
but who should contribute?

NOTE Org community forums - Org mailing list

00:26:01.358 --> 00:26:03.799
So I want to improve communication between the

00:26:03.800 --> 00:26:12.479
community and the mailing list. Now, people often

00:26:12.480 --> 00:26:16.799
discuss new features or ideas on all kinds of places like

00:26:16.800 --> 00:26:20.239
Reddit, Mastodon, like all kinds of Matrix/IRC chats,

00:26:20.240 --> 00:26:25.439
even on meetups, some non-English language. That's very

00:26:25.440 --> 00:26:29.479
nice that we have this community, but not all the ideas are

00:26:29.480 --> 00:26:34.499
visible to the developers. I do wish that the most

00:26:34.500 --> 00:26:38.279
important things that people want to see should end up on the

00:26:38.280 --> 00:26:42.331
mailing list, one way or another.

00:26:42.332 --> 00:26:43.519
I'll later talk about some

00:26:43.520 --> 00:26:48.839
ideas how I think it can be done. Another part is

00:26:48.840 --> 00:26:52.554
we have org-wiki and I hope that

00:26:52.555 --> 00:26:55.239
we can make it more centralized

00:26:55.240 --> 00:26:58.476
space for interesting Org mode articles,

00:26:58.477 --> 00:27:00.617
for tutorials, for blog posts,

00:27:00.618 --> 00:27:03.679
at least linked to blog posts. If you have

00:27:03.680 --> 00:27:08.119
some idea about good blog posts, it would be nice if you

00:27:08.120 --> 00:27:13.025
submit a patch to work or at least email about this link

00:27:13.026 --> 00:27:17.159
to the mailing list.

NOTE Org mailing list - world

00:27:17.160 --> 00:27:21.054
Of course, not everyone likes to use mailing lists

00:27:21.055 --> 00:27:23.809
or don't have a good setup to do it,

00:27:23.810 --> 00:27:25.559
or even don't want to read

00:27:25.560 --> 00:27:27.599
everything on Org mailing list, because there are things

00:27:27.600 --> 00:27:31.359
like bug reports, people don't really want to see that. So

00:27:31.360 --> 00:27:35.439
Bastien actually developed a tool that can help with this.

00:27:35.440 --> 00:27:39.239
If you want to monitor Org mailing list, but want to see

00:27:39.240 --> 00:27:42.799
only the most important discussions, and maybe

00:27:42.800 --> 00:27:45.479
participate if you decide to, you don't have to register. We

00:27:45.480 --> 00:27:51.919
have Woof, which is basically a web page that monitors our

00:27:51.920 --> 00:27:55.639
main list, but not every email. That's the most important

00:27:55.640 --> 00:27:58.719
announcements, some blog-like posts, or feature

00:27:58.720 --> 00:28:02.799
requests, or some discussions. Then on this webpage,

00:28:02.800 --> 00:28:06.119
you can see it as HTML, or you can subscribe as RSS, or even

00:28:06.120 --> 00:28:11.119
download in Org or MD format.

00:28:11.120 --> 00:28:15.359
Thanks to Sacha Chua, also weekly news about Emacs in

00:28:15.360 --> 00:28:23.199
general, but Org Mode as well. It also includes the

00:28:23.200 --> 00:28:26.639
new features in Org Mode on the development branch and the

00:28:27.100 --> 00:28:30.199
interesting new blog posts and discussions on various

00:28:30.200 --> 00:28:35.879
Reddit forums or mailing lists everywhere. I did this

00:28:35.880 --> 00:28:39.519
little bit of experimental integration so that many lists

00:28:39.520 --> 00:28:45.159
can also be read, kind of announced on the chats.

00:28:45.160 --> 00:28:48.319
For example, in #org-mode Matrix room, we have a bot that

00:28:48.320 --> 00:28:53.239
connects to Woof RSS so that all the news and discussions are

00:28:53.240 --> 00:28:55.923
notified in the chat so that people

00:28:55.924 --> 00:28:58.764
can see if they are interested

00:28:58.765 --> 00:29:02.519
and maybe, hopefully, participate. I wish

00:29:02.520 --> 00:29:05.599
we could also have similar kind of both for Reddit, Mastodon

00:29:05.600 --> 00:29:10.879
and maybe IRC. That way we have mailing list connected to

00:29:10.880 --> 00:29:17.719
more active and more modern forums and chats.

00:29:17.720 --> 00:29:19.959
More people exposed to what is happening.

00:29:19.960 --> 00:29:26.719
Another part is that we actually have a web interface to Org

00:29:26.720 --> 00:29:29.048
mailing list and you can even reply from there,

00:29:29.049 --> 00:29:31.400
but it's not always obvious, unfortunately.

00:29:31.401 --> 00:29:37.745
We have this public inbox software

00:29:37.746 --> 00:29:39.999
to transform the mailing list into

00:29:40.000 --> 00:29:45.719
HTML pages. That's a decent interface, but it could be

00:29:45.720 --> 00:29:49.199
improved to look more forum-like, so that people can easily

00:29:49.200 --> 00:29:53.079
find the reply button or basically participate without

00:29:53.080 --> 00:29:56.119
too much effort, even if they are not subscribed or they are just

00:29:56.120 --> 00:29:59.079
casually reading. That would be nice if someone

00:29:59.080 --> 00:30:05.579
knowledgeable of CSS could help with this.

NOTE Contribute ideas!

00:30:05.580 --> 00:30:12.199
Again, I cannot emphasize more that most of the Org ideas of

00:30:12.200 --> 00:30:16.974
the new features are coming from people,

00:30:16.975 --> 00:30:23.221
but often they are known either by someone

00:30:23.222 --> 00:30:24.479
submitting a patch to the mailing list or

00:30:24.480 --> 00:30:28.239
submitting an idea to the mailing list. Rarely, it happens when

00:30:28.240 --> 00:30:31.999
someone is reading posts from Reddit that don't share to the

00:30:32.000 --> 00:30:35.639
mailing list. If you think that there is some important

00:30:35.640 --> 00:30:38.599
discussion happening on the forum,

00:30:38.600 --> 00:30:42.415
it would be nice that you can go ahead and share it

00:30:42.416 --> 00:30:46.519
with Org mailing list. We don't care about

00:30:46.520 --> 00:30:49.500
on-topic, off-topic, because unlike

00:30:49.501 --> 00:30:51.385
emacs-devel, we don't focus on development.

00:30:51.386 --> 00:30:54.929
We can discuss some related to Org mode topics

00:30:54.930 --> 00:31:01.519
in open-end list, just like on an ordinary forum.

NOTE How much can a single person do?

00:31:01.520 --> 00:31:08.439
I would like to end my talk with the call for contributions.

00:31:08.440 --> 00:31:13.639
Let me explain a little bit, because you saw now I shared many

00:31:13.640 --> 00:31:19.319
many ideas and I do spend a lot of time on Org Mode. In fact,

00:31:19.320 --> 00:31:21.322
for the last year, I was spending like

00:31:21.323 --> 00:31:23.437
30 hours per week or something.

00:31:23.438 --> 00:31:27.319
Until recently, I can spend a bit less, but still

00:31:27.320 --> 00:31:29.900
even with that much of commitment,

00:31:29.901 --> 00:31:31.479
there is no way I can handle

00:31:31.480 --> 00:31:34.999
everything by myself.

NOTE Contribute code!

00:31:35.000 --> 00:31:38.551
We really, really need more people to contribute

00:31:38.552 --> 00:31:43.633
so that Org mode keeps moving forward.

00:31:43.634 --> 00:31:45.079
Again, I just shared ideas,

00:31:45.080 --> 00:31:46.394
but I have so many more.

00:31:46.395 --> 00:31:48.734
I have more than a thousand ideas noted down.

00:31:48.735 --> 00:31:52.636
Yeah, there's no way I can do it myself.

00:31:52.637 --> 00:31:57.350
I do need help for new contributions, for new features.

00:31:57.351 --> 00:31:57.617
If someone can help fixing bugs, it would be really great.

00:31:57.618 --> 00:32:04.291
If someone knows specialized things,

00:32:04.292 --> 00:32:06.873
like for example Open Document Format,

00:32:06.874 --> 00:32:08.759
which I don't know very well, it would be

00:32:08.760 --> 00:32:12.999
really nice, because things like ODT export requires

00:32:13.000 --> 00:32:14.089
knowing that, and if someone already has the knowledge,

00:32:14.090 --> 00:32:18.081
it would be much easier

00:32:18.082 --> 00:32:23.480
if that person can help with such things.

00:32:23.481 --> 00:32:26.868
Although in the coming years,

00:32:26.869 --> 00:32:28.159
it's very important to have

00:32:28.160 --> 00:32:28.830
regular contributors

00:32:28.831 --> 00:32:31.921
because my life is my life

00:32:31.922 --> 00:32:34.363
and things may happen,

00:32:34.364 --> 00:32:37.244
so it would be nice to have some kind of backup

00:32:37.245 --> 00:32:40.245
so that bugs keep being fixed

00:32:40.245 --> 00:32:40.245
and things like patches being accepted

00:32:40.246 --> 00:32:44.567
and stuff like that,

00:32:44.568 --> 00:32:46.168
so that some person can at least

00:32:46.169 --> 00:32:49.879
temporarily take on my job.

00:32:49.880 --> 00:32:51.510
I would like to emphasize

00:32:51.511 --> 00:32:53.319
that the code contributors are the most

00:32:53.320 --> 00:32:56.212
important contributions for Org Mode.

00:32:56.213 --> 00:33:02.079
All other types are less important, really.

NOTE Why contribute?

00:33:02.080 --> 00:33:03.959
I want to spend a couple of slides

00:33:03.960 --> 00:33:07.719
trying to motivate you to contribute.

00:33:07.720 --> 00:33:11.128
If you ever considered contributing

00:33:11.129 --> 00:33:13.359
or if you ever wished to have some

00:33:13.360 --> 00:33:16.879
feature in Org Mode, really don't wait, because

00:33:16.880 --> 00:33:18.239
most new features are contributed by people.

00:33:18.240 --> 00:33:23.736
They are not contributed by me.

00:33:23.737 --> 00:33:25.199
I contribute a few things, but I am alone.

00:33:25.200 --> 00:33:27.038
I cannot contribute many things.

00:33:27.039 --> 00:33:30.300
Most of the things are contributed by users

00:33:30.301 --> 00:33:33.441
who go ahead and submit patches.

00:33:33.442 --> 00:33:37.323
And even in very commonly requested features,

00:33:37.324 --> 00:33:40.344
it's usually someone who steps up.

00:33:40.345 --> 00:33:42.199
If you want something, don't wait.

00:33:42.200 --> 00:33:44.206
Just go ahead and write to mailing list.

00:33:44.207 --> 00:33:46.207
You don't have to submit a patch immediately.

00:33:46.208 --> 00:33:48.729
You can just say, I am interested.

00:33:48.730 --> 00:33:53.819
We will start from there.

00:33:53.820 --> 00:33:56.043
We'll start because that's my job

00:33:56.044 --> 00:33:57.644
and I will guide you through.

00:33:57.645 --> 00:33:58.990
If you have problems with Org in general,

00:33:58.991 --> 00:34:02.308
I'll explain, because that's what I know.

00:34:02.309 --> 00:34:05.030
I will explain how to implement things better,

00:34:05.031 --> 00:34:06.999
but I need someone to actually do

00:34:07.000 --> 00:34:10.070
the job and write the code.

00:34:10.071 --> 00:34:19.057
Even if you don't have 10 years experience with Elisp,

00:34:19.058 --> 00:34:21.178
it doesn't matter. You can learn on the way.

00:34:21.179 --> 00:34:22.519
There are many examples of this in the

00:34:22.520 --> 00:34:25.642
mailing list when we start slowly,

00:34:25.643 --> 00:34:27.759
fix things one by one, and

00:34:27.760 --> 00:34:29.225
eventually arrive to a good quality

00:34:29.226 --> 00:34:31.707
when the person is not experienced.

00:34:31.708 --> 00:34:34.759
You just need to be ready to learn things,

00:34:34.760 --> 00:34:37.992
Spend your free time (that's as usual, right?),

00:34:37.993 --> 00:34:41.214
and have the interest in specific thing

00:34:41.215 --> 00:34:43.499
you are contributing.

00:34:43.500 --> 00:34:44.475
Don't be afraid to be wrong.

00:34:44.476 --> 00:34:47.578
I will be there to assist.

00:34:47.579 --> 00:34:48.937
If you don't like emails,

00:34:48.938 --> 00:34:51.239
if you don't like patches, it doesn't matter.

00:34:51.240 --> 00:34:55.361
Again, you can share GitHub link. It's okay.

00:34:55.362 --> 00:34:57.684
You can go and modify some workflow directly.

00:34:57.685 --> 00:34:59.565
You submit the modified version. It's also okay.

00:34:59.566 --> 00:35:05.119
It's easy for me to create patches if I need to.

00:35:05.120 --> 00:35:07.279
If you don't like emails at all, you don't want to

00:35:07.280 --> 00:35:11.879
participate in the mailing list, it's not ideal, but I can

00:35:11.880 --> 00:35:16.005
still work with this. I am on IRC, I am on Matrix,

00:35:16.006 --> 00:35:19.799
you can ping me, it's yantar2.

00:35:19.800 --> 00:35:22.347
We also have monthly meetup,

00:35:22.348 --> 00:35:23.987
so you can go and ask by voice,

00:35:23.988 --> 00:35:27.088
we can just talk in person, discuss your ideas,

00:35:27.089 --> 00:35:29.299
it's also fine.

00:35:29.300 --> 00:35:35.159
The key point is that we always welcome new contributors.

00:35:35.160 --> 00:35:40.239
The more contributions to Org Mode is better.

NOTE Benefits for code contributors

00:35:40.240 --> 00:35:41.519
To increase the motivation,

00:35:41.520 --> 00:35:44.919
I'll just try to show some benefits

00:35:44.920 --> 00:35:49.479
of contributing to Org Mode and free software in general.

00:35:49.480 --> 00:35:52.079
It can be actually useful for your CV if you're a programmer.

00:35:52.080 --> 00:35:54.999
It doesn't matter if it's Lisp, because you can have a pet

00:35:55.000 --> 00:35:59.039
project that demonstrates your skills, that you can finish

00:35:59.040 --> 00:36:04.359
something to a usable state.

00:36:04.360 --> 00:36:06.800
A pet project usually demonstrates

00:36:06.801 --> 00:36:08.839
that you can work alone, but it doesn't

00:36:08.840 --> 00:36:12.119
demonstrate anything about you working in a team, in the

00:36:12.120 --> 00:36:15.519
production team. When you contribute to

00:36:15.520 --> 00:36:17.629
Libre software, look,

00:36:17.630 --> 00:36:20.759
you will work with a number of people

00:36:20.760 --> 00:36:24.352
who contribute and comment on your work.

00:36:24.353 --> 00:36:27.073
You'll have to learn a new code base.

00:36:27.074 --> 00:36:30.075
You will have to follow certain standards.

00:36:30.076 --> 00:36:33.239
All these things, by having a public record

00:36:33.240 --> 00:36:37.559
of contribution, will be a valid point that proves your

00:36:37.560 --> 00:36:42.087
knowledge in your CV. I put a small quote

00:36:42.088 --> 00:36:44.869
(which I'm not going to read in the interest of time)

00:36:44.870 --> 00:36:46.279
from Rudolf Adamkovič,

00:36:46.280 --> 00:36:50.159
who is describing these three points in probably a

00:36:50.160 --> 00:36:56.519
more expressive way.

00:36:56.520 --> 00:36:59.939
Another benefit is you can actually get money from this.

00:36:59.940 --> 00:37:03.999
Thanks to a number of Org Mode users who kindly contribute to

00:37:04.000 --> 00:37:07.199
Org development, we have some amount of money

00:37:07.200 --> 00:37:11.009
coming in, and we don't hold on this money.

00:37:11.010 --> 00:37:13.550
If we get another person who contributes

00:37:13.551 --> 00:37:17.511
to Org regularly, we are happy to share this money,

00:37:17.512 --> 00:37:22.539
because we do know that

00:37:22.540 --> 00:37:24.599
getting some extra money, even a little bit,

00:37:24.600 --> 00:37:27.216
does improve motivation.

00:37:27.217 --> 00:37:29.158
We are really ready to share this.

00:37:29.159 --> 00:37:33.523
If you are serious about contributing,

00:37:33.524 --> 00:37:34.919
you can just request this

00:37:34.920 --> 00:37:41.419
and we can share a part of the donations to you.

NOTE Contributing as non-programmer

00:37:41.420 --> 00:37:45.199
For non-programmers, we also have a lot of work to do.

00:37:45.200 --> 00:37:47.092
There's a lot of stuff we can do on the Org wiki,

00:37:47.093 --> 00:37:48.754
especially with CSS styles,

00:37:48.755 --> 00:37:53.178
with updating articles,

00:37:53.179 --> 00:37:54.880
with adding links to tutorials,

00:37:54.881 --> 00:37:56.222
or even writing tutorials about Org Mode.

00:37:56.223 --> 00:38:01.081
It would be nice to have more screencasts.

00:38:01.082 --> 00:38:02.702
It would be nice to improve Org manual,

00:38:02.703 --> 00:38:05.283
because that's the most difficult part for me

00:38:05.284 --> 00:38:07.325
because I'm too familiar with the code.

00:38:07.326 --> 00:38:11.226
Writing the manual when you know things internally

00:38:11.227 --> 00:38:13.727
is very hard. I just know too many things.

00:38:13.728 --> 00:38:16.809
I can assume that people know too much,

00:38:16.810 --> 00:38:20.911
that new users have no idea about certain things.

00:38:20.912 --> 00:38:30.439
I can just omit those without being aware.

NOTE Got no free time, but still want to help?

00:38:30.440 --> 00:38:33.319
The final slide I would go to come back is about

00:38:33.320 --> 00:38:37.919
donations. Again, most important is contributing code,

00:38:37.920 --> 00:38:42.879
but I do hope that donations can

00:38:42.880 --> 00:38:45.445
increase the number of contributors.

00:38:45.446 --> 00:38:47.999
I don't know. I know for sure because some

00:38:48.000 --> 00:38:52.439
people like Timothy, who is participating in this, he did

00:38:52.440 --> 00:38:55.319
find the donations helpful, especially for more boring

00:38:55.320 --> 00:39:00.079
tasks like bug fixing and to move things

00:39:00.080 --> 00:39:07.835
over the long time. If you cannot contribute by other means,

00:39:07.836 --> 00:39:12.996
it would be appreciated to contribute money.

NOTE Thank you

00:39:12.997 --> 00:39:14.817
We came to the end of my talk.

00:39:14.818 --> 00:39:16.277
Thank you for your attention.

00:39:16.278 --> 00:39:19.698
If you have any questions, please feel free to ask.

00:39:19.699 --> 00:39:22.898
I think we can even discuss further

00:39:22.899 --> 00:39:28.180
during the next Org Meetup in the coming week.

00:39:28.181 --> 00:39:30.320
There, if you have more detailed questions,

00:39:30.321 --> 00:39:31.640
we can continue discussing

00:39:31.641 --> 00:39:34.440
apart from what happens after this presentation.