Repo/process updates

[jeffpaul]

Is your enhancement related to a problem? Please describe.

In working through the 0.8.0 release, the following items came up that may be worth considering:

1. Considering updating from the current deploy.yml workflow to one utilizing https://github.com/10up/action-wordpress-plugin-deploy <-- already prepared in Update deploy.yml #543
2. The changelog in readme.txt links to https://github.com/wordpress/two-factor/releases. Should we have a full changeling in readme.txt?
3. Is assets folder within SVN trunk necessary given that duplicates the root assets folder?
4. License not fully correct per expected formats. composer.json properly lists GPL-2.0-or-later, package.json shows GPL-2.0+ instead of GPL-2.0-or-later, two-factor.php leaves out the License and License URI header fields, and readme.txt also leaves out the License and License URI header fields. I'd recommending ensuring all these note GPL-2.0-or-later as the license and where links are required that we link to https://spdx.org/licenses/GPL-2.0-or-later.html
5. Similarly ensure that the other header fields in two-factor.php and readme.txt match the formats/information as listed by the WP.org Plugin team in Header Requirements and Plugin Readmes respectively.
6. Add a develop branch off master and set develop to the default branch such that all future PRs branch off develop and releases happen by merging from develop into master and tagging/releasing off master. Similarly, rename master to trunk or main, update other references within the repo from master to the new branch name including within GitHub Actions.
7. Create a RELEASING.md file to document the release process including text to copy/paste into an issue for release checklist, add RELEASING.md to the .distignore file.
8. The plugin currently lists credits by linking to the GitHub Contributors view, but that does not take into account folks who help test/provide feedback on PRs, open well-defined issues, and other non-commit-related tasks. As such, while it may be a bit more effort during the release process I recommend adding a CREDITS.md file (example here) and adding a step to the release process for "Props: update CREDITS.md file with any new contributors, confirm maintainers are accurate."

Proposed Solution

No response

Designs

n/a

Describe alternatives you've considered

n/a

Please confirm that you have searched existing issues in this repository.

Yes

[iandunn]

These things came up in the 0.8.1 release (#550):

• The person doing the release needs to be added to the plugin committer list on w.org, so that they get the release confirmation email, or someone who's already a committer needs to be available to confirm. It'd be good to link to where they can be added, and clarify that this is different from the contributor list.
• Mention that creating a release will automatically generate & attach zip/tarball files, because the release form asks for them to be uploaded
• Mention that someone needs to confirm the release. This is implied but not explicitly stated
• The changelog can be generated from a compare URL like 0.8.0...HEAD
• Add a step to install the new version on a production site to make sure everything worked fine

[PluginVulnerabilities]

Having the changelog in the readme.txt helps with security, as it makes it easier to identify security changes to plugins and then double check they were complete. We often find security change are not incomplete. So it would be great if you included the changelog in the readme.txt.

[jeffpaul]

@PluginVulnerabilities there's a character limit on the readme.txt, so I'd recommend we limit to a certain amount of the changelog but then reference the full changelog here in the source repo.

[PluginVulnerabilities]

It would be best if WordPress didn’t have a character limit that restricted the changelog, but if the recent changes were included and the full changelog was linked to, that would be a good solution.