[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Concerns about community contributor support
Thomas S. Dye
Re: Concerns about community contributor support
Sat, 17 Apr 2021 13:29:23 -1000
mu4e 1.2.0; emacs 26.3
As a long-time follower of this list and a devoted, if often
ignorant or confused, user of Org mode, I'd like to give my
perspective on your concerns, which I find genuine and IMHO
intended to further the Org mode project.
I was drawn to Org mode when Eric Schulte and Dan Davison were
implementing Org babel. At the time, I had dabbled in literate
programming and was using reproducible research practices in my
work, so the babel project made sense to me and I was thrilled to
find a couple of terrific programmers working on what to my mind
was a beautiful implementation of these ideas.
I knew about Carsten Dominik from his work with RefTeX, which I
also used in my work,
but got to know him better as the creator and maintainer of Org
mode. My impression of Carsten was an indefatigable worker whose
vision of what Org mode might be kept growing as the user base
expanded and diversified.
The mailing list was a different place back then, less technical
and open to more noise than it is today. It was a place that
understood the importance of kindness for a collaboration of
volunteers. I think the list has done an admirable job of
maintaining the ethos of kindness, but Org mode development is in
a new phase that *requires* technique and is quicker to identify
and filter out noise. When Bastien took over as maintainer after
Carsten exhausted himself working on Org mode (my interpretation),
Nicolas Goaziou took over most of the coding work. His brief was
clearly to put the Org mode code into better order, which he did
with astonishing efficiency and expertise (at least from my often
ignorant and confused perspective). His work on the syntax,
exporter, linter, and manual represents IMHO an outstanding
contribution to Org mode. I'm sure there are other important
contributions that I'm not remembering right now. My point is
that the project changed from one that was expanding its own
vision of what it might be to one that was working to ensure that
it wouldn't collapse from its own weight.
Kyle Meyer is the next step in this direction, whose efforts have
helped tame the discussions on the Org mode list with a remarkable
facility for threading together the various strands of discussion,
some of which have histories that comprise several years.
Combined with a command of git, his work has brought the
discussion into closer contact with the development of the code
These changes mean that contributions need to be checked for
contributions to Nicolas' project and also fit into the history of
discussion and development. The Org mode project now resembles a
scholarly discipline that moves slowly and deliberately toward a
more or less well defined goal. The days when Carsten would bang
out a new feature during his train ride home from work are gone.
Bastien did recently call for maintainers, though IIRC he was
interested in ox-* and ob-* maintainers more than org-*
maintainers. If enough good programmers heed his call, then there
might be some progress on the concerns you raise. But, my sense
is that patches to Org mode proper will continue to be adopted
slowly and deliberately. It would be a shame if that pace put off
talented programmers, but my sense FWIW is that the pace might be
necessary until the code base is fully tamed.
All the best,
Timothy <firstname.lastname@example.org> writes:
Over the last few months I have felt an increasing level of
the lack of response to patches. This email is rather long, but
bear with me. The goal is to start a discussion on the problems
creates, and consider short and long-term solutions.
When both community and maintainer response to new patches is
many first-time contributors are actively dissuaded from
again. Furthermore, each patch represents a considerable time
--- particularly if it's from an individual who is new to the
list / patch workflow. Org-mode is not "done" and still requires
support of long-term contributors to keep improving, anything
discourages them from contributing back to the community needs
carefully understood and resolved if we want to continue
Take for example Jay Bosamiya's patch from September last year
appears to be his first submission to this mailing list, and yet
has been absolutely no response to it. There are currently 24
patches listed on the updates.orgmode.org which have seen no
from this community, some of which are from first-time
There are 36 other patches with at least two replies, but yet to
resolved. Bastien's updates.orgmode.org is fantastic in helping
contributions slip through the cracks, but it is also
lack of community response to a significant number of patches.
This mailing list was my first experience with an email+patch
contribution workflow. Thankfully, I received prompt and
feedback and was guided through the adjustments needed so it
merged in a timely manner. Should my patch have been similarly
I would have been quite disheartened; it is not an overstatement
I would likely have written off this mailing list and not tried
Simply put, this is not good enough. This does a disservice to
that have dedicated time and effort to try and better this
to be ignored. Not rejected, not even acknowledged, nothing.
It is imperative that this community improves our response to
contributions for the long-term health of this project. Do not
to be a doomsayer; I have faith that Org is going to keep on
regardless. However, failing to welcome and encourage
contributors has a
deleterious effect on the health of the project.
I do not blame the maintainers in the slightest. As Bastien
in a recent worg discussion, as time goes on we find ourselves
more and more life responsibilities. Therefore it's in our best
to delegate some of the maintainer responsibilities to
active, and supportive community members to "pass down the
torch" so the
community and platform can continue to expand with grace and
What can the community do?
I don't know of any silver bullet, but I believe there are some
which could help, namely:
+ The development and publication of "reasonable expectations"
contributors should have when submitting a patch, and that the
maintainers should strive to uphold (e.g. "expect a response
+ A community effort/sprint to respond to those patches that
+ Onboarding of new maintainers, when reasonable and suitable
exist (I'd very willingly throw my hat in the ring for
If it's too much work, spread it out as much as possible.
If any other ideas come to mind, please share them so we can
Finally, it's not all bad.
While this discussion has called for some criticism, I don't
give the false impression that I think nothing is working and
supporting contributors. This is not the case at all, there are
standout individuals one the mailing list who have been
to you all.
My best to everyone,
Thomas S. Dye