Change this repository into a collection of links?

[jgm]

One drawback of the current structure is that people submit code here but then don't monitor the repository, and issues are neglected. Perhaps it would be better to make this simply a collection of links to lua filters that are maintained in independent repositories?

[bpj]

Also maybe "ext" in "pandoc-ext" can be read as either/both of "extended" and "extra", although that may conceptually clash with Pandoc reader/writer extensions.

Den mån 1 maj 2023 17:01Albert Krewinkel @.***> skrev:

I don't see it as a split, it's two separate orgs with slightly different goals.

As for this repo, it should probably be archived at some point.

— Reply to this email directly, view it on GitHub https://github.com/pandoc/lua-filters/issues/207#issuecomment-1529802962, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAI3OUYETGAWKP4T7HZBBSTXD7FZDANCNFSM5LAX3HCQ . You are receiving this because you were mentioned.Message ID: @.***>

[ickc]

Thank you @ickc, and sorry for the late reply, I had forgotten about this. I went with the pandoc-ext name to mirror the quarto-ext org. Now we have two such orgs, but I think that's ok.

I've sent you an invite to become a maintainer at the new org.

The invitation just expired. Could you send one again? Thanks.

[hholst80]

and issues are neglected.

Is that worse or better than neglecting things in their own repos? At least here the issue is seen by many more users and perhaps fixed.

Just because something has problems does not mean that the problem is resolved by changing the physical location of the code. The problem just moved. 99% of the code here will be written by PhD students and as soon as they are out of academia they will forget all about their pandoc hacks. I believe that moving things out will make it less probable for code to be 'inherited' by new students, and rather they will reinvent the same solutions, ad infinitum.

As a legacy user of pandoc (I have written these kind of filters myself, when I was a PhD student) I find the pandoc vs pandoc-ext confusing as I find the reasons for this change confusing. With 30 open issues, the problem rationale appears to me more theoretical than practical. Consider a repositories like Ansible which has a myriad of custom domain plugins. If they would go down this route, I could sympathize. They have >30K issues, and often have thousands of open issues, and hundreds of open PRs. This repo has 30 open issues. I am a skeptic but I can be convinced by reason: what problem is being solved and what problem is invented?

[tarleb]

Before I invest time in an answer, I'd like to learn more about your motivation for this question. Do you plan to contribute, maybe by writing explanatory paragraphs to place in some of the readme files? Or is this just curiosity and/or frustration?

[hholst80]

I think the users of pandoc deserves the best possible ecosystem. My time is as important as yours and I already invested because I see that this important. I stated that I already wanted to contribute the d2 filter. I have used pandoc for some time. At least 10 years, but likely 15 years. The little code that I made available is largely unused by the community. Wasted efforts and I also have no interest in maintaining small lua hacks in my private github. Put together these "hacks" becomes valuable.

You can expand on the rationale and we can strawman on this as a case study:

https://github.com/JensErat/pandoc-scrlttr2

It seems to be a very nicely setup repository. Last changed 8 years ago. (I think we can keep up with the maintenance work?) Not everything would need to go into this repo either. Let the users decide what they want to put here. Perhaps there is no need to have pandoc-scrlttr2 (weird name, only makes sense in academia) in this repo because it is well maintained and discoverable in other places. I want to make it easy for people to hack up some code and share it with people. Collaborate and build together as not everyone want to put up a complete OSS project and put on their github.

[jgm]

That repository is a single project by a single person who maintains it. That's exactly what we want to move to for Lua filters.

We want to get away from the model where you contribute your script to a giant repository, then expect others to field bug reports for it, deal with questions about it, and so on.

[hholst80]

We want to get away from the model where you contribute your script to a giant repository, then expect others to field bug reports for it, deal with questions about it, and so on.

I see nothing wrong with that expectation. This is exactly what happens with all successful open source. People learn about the code and knowledge is shared, and software is improved.

[jgm]

You're saying that your expectation is that others will maintain your code, answers questions about it, and so on? Where others = @tarleb and me? No, thanks. I'm already overburdened with my open source maintaining. I'd rather have you maintain your code in your own repository. Happy to link to it.

[bpj]

I took the liberty to add a page on the repository wiki where authors can add links to their filters themselves with zero hassle for the owners of this repository.

Thoughts:

• Perhaps that page can be (prominently) linked from and/or periodically copied to the repository README.
• Maybe it should better go into the pandoc-ext wiki as/if that is activated. On the other hand this repository will probably come up if people search for "Pandoc (Lua) filters".
• I will try to find time/remember to do some housekeeping on that page, but the more people help with that and with adding entries the better of course!l

[odkr]

There's already https://github.com/jgm/pandoc/wiki/Pandoc-Filters. But perhaps it'd be a good idea to place a prominent link to that Wiki in the README.