Consider consolidating GitHub wiki actions?

[jcbhmr]

@spenserblack would you be open to revisiting the idea of combining github wiki actions? Particularily @Andrew-Chen-Wang's Andrew-Chen-Wang/github-wiki-action which I have contributed to recently.

I think the goals of this project align reasonably well with Andrew-Chen-Wang/github-wiki-action, particularly given the recent shift from "I dream of lots of features on by default" to a more restrained "just push the folder to the wiki" action with a recommendation to use other actions to do complex stuff.

previously: Andrew-Chen-Wang/github-wiki-action#26 and Andrew-Chen-Wang/github-wiki-action#8

now: Andrew-Chen-Wang/github-wiki-action#8 (comment) and https://github.com/Andrew-Chen-Wang/github-wiki-action#preprocessing

On a practical note, I have contributed a few features that I've proposed here to Andrew-Chen-Wang/github-wiki-action and they worked out pretty well! I think it'd be foolish to re-implement them a second time (or copy-paste 🤣) vs nudging towards Andrew-Chen-Wang/github-wiki-action

• github-server-url option
• using $GIT_DIR and $GIT_WORK_TREE
• providing an alternative strategy to push to the wiki
• using gh auth setup-git properly to configure auto-authentication with github push/clone urls

more info on the recent v4 stuff: Andrew-Chen-Wang/github-wiki-action#30

TLDR: spenserblack/actions-wiki and Andrew-Chen-Wang/github-wiki-action seem to fill the same usecase and niche now. Can nudge spenserblack/actions-wiki towards Andrew-Chen-Wang/github-wiki-action? Or is there a specific direction or usecase that we'd like to build on for spenserblack/actions-wiki?

[spenserblack]

I probably won't abandon/archive this project in favor of github-wiki-action, since I initially made it to be simply for personal use. However, I understand not wanting to duplicate work, so if you decide to make github-wiki-action the primary project that you contribute to, that's fine with me 🙂

Feel free to make a PR referencing this somehow. Right now github-wiki-action is referred to as "a direct competitor," but you could possibly reword that to something like "receives more active contribution from a major contributor to this project."

[jcbhmr]

I think it's healthy to have varying implementations of the same solution.

While I agree in principle that competition to foster improvement is good, I also see value in the Python wisdom:

There should be one-- and preferably only one --obvious way to do it.
https://peps.python.org/pep-0020/

In this case, I think trying to improve the original (or popular) thing is better than making a clone. But that's me.

[spenserblack]

How many Python package managers are there? 😆

[Andrew-Chen-Wang]

@jcbhmr I don't understand the meaning of competition in the context of OSS. If there is maintenance for an existing solution, then that's all that's needed for OSS. Maintenance is key. Please don't bother other maintainers unless they've abandoned a project that has popularity (ie needs a new maintainer).

[jcbhmr]

Please don't bother other maintainers unless they've abandoned a project that has popularity (ie needs a new maintainer).

Sounds good, I'll drop the subject. 👍

[spenserblack]

For what it's worth, I'd welcome a PR that updates the README to recommend @Andrew-Chen-Wang's project as a more mature or feature-rich alternative. @Andrew-Chen-Wang does make a good point about the usage of the word "competition," so at the very least the README probably shouldn't call their project a "direct competitor."

[jcbhmr]

Opened a PR #82