* Re: Offering support to mitigate Pandoc's Issue/PR backlog
[not found] ` <2cdf2453-8021-43d8-a69b-8b6d3d260374n-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
@ 2023-11-06 12:47 ` Stephan Meijer
[not found] ` <13581e70-a573-414a-ab05-bfa9f73b9259n-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
2023-11-06 15:31 ` Albert Krewinkel
1 sibling, 1 reply; 4+ messages in thread
From: Stephan Meijer @ 2023-11-06 12:47 UTC (permalink / raw)
To: pandoc-discuss
[-- Attachment #1.1: Type: text/plain, Size: 2626 bytes --]
I would like to draw attention to the current status of our contributions
to the Pandoc project. At this moment, we have three open pull requests:
1. #9170 <https://github.com/jgm/pandoc/pull/9170>
2. #9162 <https://github.com/jgm/pandoc/pull/9162>
3. #8998 <https://github.com/jgm/pandoc/pull/8998>
Our team has been contemplating forking as a way to keep our projects
moving along, but we're fully aware of the maintenance challenges this
could introduce, especially when it comes to staying in step with the
updates from the main Pandoc repository.
We're invested in supporting the Pandoc community and would much prefer to
work within the existing framework to get these PRs processed. We're on the
lookout for any advice on how to make this as smooth and unobtrusive as
possible for everyone involved.
Could you guide us on the best way to move forward with these
contributions? Any pointers on how to streamline our PRs or suggestions on
alternative approaches that could help lighten the load for the Pandoc
maintainers would be much appreciated.
On Monday, 6 November 2023 at 13:37:06 UTC+1 Stephan Meijer wrote:
> *This is mainly directed to @jgm / John MacFarlane and/or Pandoc
> maintainers.*
>
> I am reaching out on behalf of our team, which frequently utilizes Pandoc
> for numerous conversion tasks. We have been closely following the project’s
> progress and have observed the growing number of open issues (947 to date)
> and pull requests (77 at the current count). Recognizing the immense value
> that Pandoc provides to the community, we are keen to explore how we might
> contribute to the project's health and sustainability.
>
> Understanding that managing such a popular project can be challenging, we
> are curious about the underlying factors contributing to the backlog. Could
> the project be facing constraints in terms of time, resources, or funding?
> We are contemplating what actions our team could take to assist effectively.
>
> We are eager to give back to the Pandoc community that has offered us so
> much. Please let us know the most impactful way we can lend our support.
>
> Stephan Meijer
>
--
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/13581e70-a573-414a-ab05-bfa9f73b9259n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 3176 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Offering support to mitigate Pandoc's Issue/PR backlog
[not found] ` <2cdf2453-8021-43d8-a69b-8b6d3d260374n-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
2023-11-06 12:47 ` Stephan Meijer
@ 2023-11-06 15:31 ` Albert Krewinkel
1 sibling, 0 replies; 4+ messages in thread
From: Albert Krewinkel @ 2023-11-06 15:31 UTC (permalink / raw)
To: pandoc-discuss-/JYPxA39Uh5TLH3MbocFFw
Stephan Meijer <me-nPKYAObcRdo6Blr+0TYHagC/G2K4zDHf@public.gmane.org> writes:
> This is mainly directed to @jgm / John MacFarlane and/or Pandoc maintainers.
>
> We have been closely following
> the project’s progress and have observed the growing number of open
> issues (947 to date) and pull requests (77 at the current count).
> […]
> Understanding that managing such a popular project can be challenging,
> we are curious about the underlying factors contributing to the
> backlog.
For general issues I suspect popularity and complexity as the main
causes, while the main issues for me personally are funding, time, and
focus.
You already noted above that pandoc has become a central part in many
workflows. This has led to a ever-growing request for features, which
leads to the invariable increase in complexity and bugs. The bigger the
code-base, the harder it becomes to change anything, and the less
attractive the project becomes to new contributors. Still, Haskell is a
big help here, and while it can't stop the trend, it does slow down the
rate at which things become harder.
As for my personal reasons:
1. Funding – I'm doing freelance work, and am lucky enough to have
companies and projects fund some parts of my work. For example, some
improvements to table handling, to JATS, functions in the Lua
subsystem, the initial development of Docker containers, and figure
processing have all been funded (partially or fully) by companies,
universities, and other organizations.
There are also a number of people who are kind enough to sponsor me
on GitHub. Using current industry rates, this allows me to around 30
minutes of "paid" work each month.
2. Time – while pandoc sits somewhere between "job" and "hobby" for me,
it is still much closer to "hobby". About a year ago I took a look at
the numbers of hours that I spend on pandoc, comparing paid and
unpaid hours. Most of my pandoc-related work (~60%) was still unpaid.
This is not a problem per se, as I generally enjoy all the time I
spend on pandoc. But it also means that pandoc is one of the places
where I tend to reduce my involvement whenever time is scarce. And
time has been a lot scarcer lately.
3. Focus – Juggling a lot of things, something that seems inherent to
open source work, can be overwhelming and tiring. So much so, that I
burn out from time to time, and just have to do other things for a
while. This is a temporary issue, and partially do to the first two
points. However, it's something to consider.
> We are eager to give back to the Pandoc community that has offered us
> so much. Please let us know the most impactful way we can lend our
> support.
I can't offer a clear answer, unfortunately. But I can say that I'd
*love* for somebody to take over maintenance of pandoc's Docker
containers. It's quite the time-sink for me, the changes and
incompatibilities in upstream containers make it hard to keep up, and
the current build chain has proven to be too hacky – it has been defunct
for a couple of months now. However, there are many people (and
companies) who rely on it.
Either way, thanks for asking!
Cheers,
Albert
--
Albert Krewinkel
GPG: 8eed e3e2 e8c5 6f18 81fe e836 388d c0b2 1f63 1124
--
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/8734xi7qlm.fsf%40zeitkraut.de.
^ permalink raw reply [flat|nested] 4+ messages in thread