Add Linux Foundation health score badge to README

[jonathimer]

Congrats! We have onboarded Gutenberg to LFX Insights, the Linux Foundation's platform for monitoring the world's most critical open-source projects.

https://insights.linuxfoundation.org/project/wordpress-gutenberg

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @jonathimer.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Unlinked contributors: jonathimer.

Co-authored-by: desrosj <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @jonathimer! In case you missed it, we'd love to have you join us in our Slack community.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

[desrosj]

Hey @jonathimer,

Thanks for this pull request! I've looked at the health score site, and that seems like a really awesome tool.

I've dug in a bit to look at the data for the Gutenberg repository is aggregated there. I have some concerns that I'd like to work through with you that I feel are blockers to adding this badge to any WordPress organization project. This PR is specifically focused on adding the badge to this repository, so I recognize this feedback may be more appropriate for a different forum. If that's the case, please let me know and I'm happy to engage wherever is best!

My first concern is around the representation of this repository and how it relates to the WordPress project itself. I noticed that there is also a WordPress project on the LFX Insights site. There is also a dropdown next to the name that allows you to filter by repository. Is there a reason why this repository was added separately rather than as a repository nested under WordPress?

While the repository is technically a separate plugin and the individual npm packages published from this repository can be used in non-WordPress projects, the Gutenberg project itself is ultimately a part of the WordPress software. Within the project, we have a saying:: "Core is Gutenberg, Gutenberg is Core." Aggregating the activity in a single location would more accurately reflect the true health and pulse of the WordPress software.

This concern extends past just the Gutenberg repository as there are other repositories that ultimately are shipped in WordPress. Libraries that live under the project's GitHub organization that are also maintained by contributors (such as https://github.com/WordPress/Requests/), tools that are foundational to the the testing infrastructure that runs for every commit to wordpress-develop (such as https://github.com/WordPress/wpdev-docker-images), and repositories called "feature plugins" that are eventually merged and shipped with WordPress (the Abilities API and Performance Labs plugins are current examples of this). The effort put into these repositories is for the direct benefit of the software itself, so I feel it makes sense to consider including some (maybe not all) as one project to show the true combined activity.

The https://github.com/wordpress/wordpress repository is also not the correct one for the project. That repository mirrors the SVN repository that a server commits to after running the build scripts results, but only when changes happen to the build directory as a result. When changes are made that do not directly affect the built result of the software, no commit is made . So as it's set up right now, no contributions to the projects test suites, build tools, etc. are accounted for.

The WordPress/WordPress repository has issues disabled, and pull requests though allowed, are not accepted there. The https://github.com/wordpress/wordpress-develop repository is where the work actually takes place. Pull requests are allowed, but issues are not (all bug reports are opened in Trac, the project's bug tracking software), and all changes to the software will be visible here, including changes to files that do not affect the results of running the build scripts.

The second concern I have is around how the contributor activity is being underrepresented. Admittedly, the WordPress project uses an unorthodox methodology for attributing individual changes to specific contributors. When a release of the WordPress software is published, the Credits page in the dashboard is powered by the Credits API on wordpress.org, which requires each contributor to have a WordPress.org account. Contributions are collected through the form of "props" that are included within commit messages.

The project strives to "err on the side of giving props liberally". In practice, this allows designers, testers, bug reporters, etc. to receive credit for their work, not just the people submitting or committing the code.

When the entire contribution process took place on Trac, this was quite simple because a .org account was required to contribute, so the usernames were already there. However when the project began mirroring the repository to Git/GitHub, that became a bit more nuanced. The main thing to be aware of is that "props" are not reflected in the wordpress-develop repository history at all.

For repositories where the merging action takes place on GitHub and not SVN, we follow a custom format for Co-Authored-by trailers using [email protected], which allows a script to easily associate a given credit with a wordpress.org user account. There are some nuances to GitHub usernames, their APIs, a user can misconfigure their local Git client, etc. that make it impossible to reliably connect a contribution to a w.org account otherwise.

For example here, @Mamaduka is listed twice: once as Mamaduka, and another as [email protected].

I would love to adopt support for the Insights tool, but I think until we are able to address inaccuracies like this we would be doing more of a disservice to the project as a whole, and more specifically the contributors who are not committing code who are not represented at all in the various statistics. I'd love to work with you to help improve this, and more than happy to drop this feedback somewhere else that's more appropriate!