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?

[cagix]

I kind of like this idea. Maybe this repo could serve as a kind of collection of "official" scripts from the Pandoc creators and all other filters could be linked in the README (sorted by topic)? That would reduce the maintenance to checking the links every year. In addition, the "official" code provided could serve as a live demo / live documentation of the Lua API.

[tarleb]

I'm very much in favor of that; it would save me a lot of time. It takes a significant amount of effort, on almost each new pandoc release, to adjust the tests and filters to the changes. It's tiresome, and pinging all authors and waiting for them to change the code would take just as long. I'd be glad to get out of that obligation.

We could still do occasional automatic "releases", which pack the filters into a single archive. This shouldn't be too hard if the individual repos use a common structure.

[cagix]

We could still do occasional automatic "releases", which pack the filters into a single archive.

That sounds interesting, but might not be quite easy with regard to the then presumably different licences in different repos?

This shouldn't be too hard if the individual repos use a common structure.

Would maintaining a template repo help with this?

[tarleb]

Pinging everyone who contributed a filter so far: what do you think of this idea? What would you need to make this as painless as possible for you?

@jdutant @tolot27 @blake-riley @not-my-profile @svenevs @b3 @jkr @cole-miller @sokotim @korintje @gtuckerkellogg @stroobandt @frederik-elwert @odkr

[cagix]

Since each filter belongs to a subfolder, it should be easy to split your repository into several individual repositories using git filter-branch and retain the individual history :)

[not-my-profile]

I am not sure about this. There are advantages to having a common repository. Having them all here guarantees that other pepole can contribute improvements even when the original author has ceased maintenance.

It takes a significant amount of effort, on almost each new pandoc release, to adjust the tests and filters to the changes. It's tiresome, and pinging all authors and waiting for them to change the code would take just as long. I'd be glad to get out of that obligation.

I think an easy fix for that would be to have a latest_pandoc_supported variable for each filter. When a new pandoc version is released that variable could be automatically bumped for each filter which tests pass with the new version. And the script could automatically update a table in the README of this repository that lists all scripts known to work with the latest version. Even the pinging of authors when their filter is no longer compatible with the latest version of pandoc could be easily automated.

Especially if you still occasionally want to release filter bundles having all filters in a single repository should make that easier. Otherwise you just have new potential problems to deal with (e.g. some repository went offline, some repository suddenly has an unexpected file structure, etc.).

[bpj]

I am in favor, but what about having this repository contain submodules/subtrees/subrepos linking to contributors' repositories so that people can still pull this repository and get all filters? I suppose a cronjob or action could be set up to update the links every day/week/month. Den fre 31 dec. 2021 09:56Martin Fischer ***@***.***> skrev:

…

I am not sure about this. There are advantages to having a common repository. Having them all here guarantees that other pepole can contribute improvements even when the original author has ceased maintenance. It takes a significant amount of effort, on almost each new pandoc release, to adjust the tests and filters to the changes. It's tiresome, and pinging all authors and waiting for them to change the code would take just as long. I'd be glad to get out of that obligation. I think an easy fix for that would be to have a latest_pandoc_supported variable for each filter. When a new pandoc version is released that variable could be automatically bumped for each filter which tests pass with the new version. And the script could automatically generate a table for the README that lists all scripts known to work with the latest version. Even the pinging of authors when their filter is no longer compatible with the latest version of pandoc could be easily automated. — Reply to this email directly, view it on GitHub <#207 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAI3OU5UGRQWJSEWCOAMAKDUTVV2ZANCNFSM5LAX3HCQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[korintje]

I agree with this idea. It is because the roles of the filters are highly independent, so we cannot expect large synergy effects by collecting them at one repository. Instead, I think it is better to focus on keeping accessibility, readability, and consistency of each filter documents. Listing the filters at Pandoc official web page or GitHub Pages would be nice. As far as I know, one ideal example is crates.io, which is a kind of library repository for Rust language, is known to have well-formatted and easily-accessible documents.

[jgm]

There are advantages to having a common repository. Having them all here guarantees that other pepole can contribute improvements even when the original author has ceased maintenance.

In that case you could always fork the original repository, make your changes, and submit a PR here for an updated link to the fork.

I am in favor, but what about having this repository contain
submodules/subtrees/subrepos linking to contributors' repositories so that
people can still pull this repository and get all filters?

I'm not sure it's all that valuable to be able to get all the filters in one repository. Generally you only need some of them; why not just clone those separately?

[tolot27]

I like the idea of submodules and switching to them should be easy because we have subdirectories, already. submodules can be checked out from their origin and individually.
Having this repository as the main repository has the advantage that checks (i. e. in case of a new pandoc version) can be maintained at a central place.

[svenevs]

I don't have any preference either way, if it makes things easier for maintainers then I'm all for it ❤️ I'm pretty sure my filter is feature complete, but I'm sorry if I've missed any issues related to it.

[alerque]

I'm really not convinced this would be an adventitious move. Having some complex filters that see a lot of development in their own repos is a good thing perhaps (and we have a history of suggesting that) but for small one-off ones that tend to be submitted, used by them a few times, and then the submitter moves on I think a large chunk of them would fall below some minimum threshold that would make them viable FOSS projects on their own. Having a team of maintainers at least reviewing submissions here adds some amount of normalizing and consistency that makes filters in this repo much more attractive than random ones out of people's Gists, and for maintenance not having the bottle neck of one maintainer that got it working form themselves and then is never motivated to tweak it to be more generally useful seems seems like a benefit to most simpler filters.

[jgm]

@alerque I think the filters could still be reviewed -- at any rate, we wouldn't need to include links to filters that didn't look good. The aim would be to change where bug reports and enhancement or support requests go. They should go to the author of the filter, not to the pandoc maintainers.

[stroobandt]

As a first-time, one-off contributor, I have to admit that the current process together with the suggestions and help provided by @tarleb rendered my contribution more worthwhile and universally applicable.
That would not have happened without the "editorial work" of @tarleb.
The current process could be considered as a very valuable peer-review, where the value eventually goes to the end user.

Another admission of mine is that my extended family and I usually employ my filter only with the version of pandoc that comes packed with the latest Ubuntu LTS release and upgrades. The reason for this being the fact that too many of my users on too many machines require a stable system environment for work/study.

This certainly does not mean that I would not maintain my filter. However, if the user community at large fails to prod me, I would typically notice a version compatibility problem with my filter only when a new version of pandoc eventually lands in the Ubuntu LTS repositories.

I hope this straightforwardness helps with reaching a consensus about how to proceed with this great, curated collection of filters.

[b3]

I do not have any smart definitive answer to this good question. I added thumb up to comments given ideas that I like.

It is a fact that I didn't follow issues here for my small filters (thanks to @jgm I will now try to check them).

It is also a fact that, as @stroobandt states, @tarleb work rendered my small contributions more worthwhile and universally applicable.

IMHO I think that keeping a common framework (at least for tests and description for instance) need however to be kept.

Being able to fetch all code at once is also a nice facility (which helps me being inspired) but still can be offered if this repo is changed to a simple list of links.

Sorry not being able to help more concretely.