Add an issue template to auto submit a PR

[TheGiraffe3]

Hecter94's plugin archive has an option to open an issue to add your plugin. Provide x, y, and z, then a script will automatically open a PR with those values. We could add something similar here to make things easier for new submitters.

[Hecter94]

My main concern with lowering the barrier to entry is that unlike the unofficial repo, the official repo has pretty high maintenance requirements.

Every new plugin needs a review before it can be added and every single update for every plugin in the official repo needs to be manually reviewed and merged.

Meaning there are exponentially more maintenance requirements for every plugin added.

If we wanted to lower the barrier to entry, which I do think would be a good thing, in my opinion, the first step would be to work out a way to reduce the maintenance requirements.

Perhaps if we could set up an auto update system like what @zuckung made for the unofficial repo.

[zuckung]

we discussed that on discord. there is the problem of possibly not trustworthy content that might get added with updates, so MCO told us that the updates have to get checked before merging.

and same for initual plugin adding, the checking have to be intense here. not entirely impossible to write something that does the checks, but out of my python/github experience.

[Hecter94]

@MCOfficer what exactly is this "untrustworthy content"?
Have there been many instances of it?

Could we not just remove a plugin and block the author if they try to sneak in something malicious?

[MCOfficer]

In theory: anything that you wouldn't want to endorse as Endless Sky. Remember, the index was designed to be
a) displayed on the official website, and
b) integrated into ES, so people can download plugins directly.

Obviously we don't want trolls to upload porn, racism, etc. to be offered over official channels. We can either police it in hindsight, or put in the effort preemptively. When I wrote the RFC, I decided to be on the safe side and chose the former. As it stands, what exactly qualifies and what doesn't is a judgement call by the reviewer and whoever they choose to consult.

Now: In those >5y, we haven't seen any trolls, and no more than 2 rejections. I only distinctly remember #450, but there might've been another instance where I warned someone ahead of time on discord.

[Hecter94]

I believe it's worth considering the option of reviewing in hindsight rather than screening everything beforehand. We would still check plugins when they are first added, meaning someone malicious would need to develop and upload a legitimate plugin, then later introduce malicious content through an update.

It seems to me that the potential for abuse is pretty low, and if we adopt a three-strikes system,
Strike 1: Warning
Strike 2: Plugin removed
Strike 3: Author blocked

I feel confident that we won't get many, if any, people looking to abuse the system.

This would also free up a lot of maintenance requirements so we could then look into implementing systems that make adding a plugin easier, so we'd be making things easier for the 99% of good actors who just want to share their plugin, while introducing a small risk of malicious content being listed on "official" sources for a short time before it's reported and removed.

I can't imagine anyone would consider that insufficient.

[zuckung]

Plugin update PR merge can be easily done with actions like
https://github.com/marketplace/actions/merge-pal or https://github.com/marketplace/actions/pr-merge-bot .
so the checks can run through first, and if successfully it automatically merges the PR. based on a label or something.
that might be better than direct code changes, that just push files?

[Hecter94]

I would say that makes sense. We already have a pretty robust checking and error-handling infrastructure, so a process that leverages that existing infrastructure rather than creating its own seems like a good idea. It would also keep the history of having a PR for every update intact, rather than changing how it's handled.

It looks like any update PRs already get the Autoupdate label, so it would be as simple as running the action on any PRs with that label once all checks have completed successfully.

[MCOfficer]

In the future it might be beneficial to either create our own merging pipeline, or simply to check & autocommit to master in the autoupdate-pipeline. Reason being, I would like to eventually do away with the "Generating Files" commits. They effectively double the amount of commits we get, and it makes the history very untidy :/

But I agree, auto-merging PRs with an existing action sounds like a low-hanging fruit. FWIW I did start work on some more sophisticated PR checks, which would further help that case.

[MCOfficer]

Since the latter half of this issue has diverged quite far from the original, i've created a new one for automatic plugin updates: #1880