Add a link to "How to make a pull request" to the "Add a Package" pages.

[daveverwer]

I had a suggestion that we should link to the GitHub guide to making a pull request on the "Add a Package" page as it might not be obvious for everyone how to do it. It's a good point, so let's find if GitHub have a good page and add a link to it.

• [ ] Add a link to the "Add a Package" page.
• [ ] Update the PackageList repository's readme file to mirror the page.

[Sherlouk]

Has our opinion on automating the PR process changed at all?

I was always pretty pleased with how simple my little experiment worked, especially as it did all client-side validation before it opened the PR.

In terms of making it easy for people, especially people who don't know how to open a pull request, I don't think it could get much better!

---

For reference: https://github.com/SwiftPackageIndex/PackageList/pull/492

edit://

The journey for this, if integrated directly into SPI, would be:

1. User goes to "Add Package" page
2. User puts URL into a text field and presses "Add" button
3. This will send an AJAX form request to the server which will validate the package (returning any errors or a success status which would be shown in a panel next to the form)
4. Server, once validated, would run some git commands to create the patch and open the PR

Messaging could let the user know that the package will be validated first before being added to the site

[finestructure]

I think it'd be great to have something like this running that still uses the PRs but makes opening them easier. I've seen interesting packages that I dragged my feet adding because I didn't want to deal with a PR 😅

[Sherlouk]

I've seen interesting packages that I dragged my feet adding because I didn't want to deal with a PR

this.

The barrier isn't always knowing how (though documenting this is definitely beneficial regardless!), it's the hassle hurdle of going through it to add a random package I've found when trawling GitHub!

[daveverwer]

I took the weekend to think about this and also chatted it through with @finestructure this morning.

My original thought was that rather than building more software on top of the current process, it might be time to replace the PackageList repo and have the server add packages directly. This would have advantages in several areas, and if the validation process that we currently have were part of it, it would prevent spam. There are disadvantages, though, in not seeing what’s getting added before it’s already in the index.

So, I’d support this idea, but I’m not too fond of having another separately hosted part of the SPI. If we go ahead with something along these lines, it must be a part of the main app.

It would also need to perform the existing validation before the app submits the PR. Ideally, this would not duplicate the existing script’s functionality (which must remain in the PackageList repository). There are so many spambots finding forms and submitting random URLs, we’d be looking at many bad pull requests if we do not validate pre-PR.

Also, feedback to the user about what’s happening is going to be critical here. If people assume that submitting a URL is adding it to the index, they’ll take a look after submitting it and then wonder where it’s gone. We need to explain the process and show them where they can find the generated PR.

For this reason, we also need to show the user what is wrong if validation fails. We will no longer know who is submitting, so we can’t ask them to fix any issues, leaving it for us to correct. The other disadvantage is that we lose the audit trail of who added what package as this form would effectively be an anonymous way to submit a package.

After writing all that, especially that last point about losing the audit trail, I’m not sure that this is the best approach. I think we should either leave it as is or look into replacing the repository completely.

I talked myself out of that as I was writing it!