Plugin maintenance is valuable and useful. Keeping a plugin current with the ongoing development of Jenkins can require user interface improvements, dependency updates, and more.
@alecharp, @jakeleon, and I are working on a Google Summer of Code project idea to provide an indicator of “plugin health” to plugin maintainers and to Jenkins users. We hope that measurements of the “health” of a plugin will help maintainers as they decide how to invest their development time. We hope that measurements of the “health” of a plugin will help users as they decide if they should install and use a plugin.
Some of the ideas for possible measurements are represented by the changes identified in the “Contributing to Open Source” workshop document. Others are described in mailing list discussions.
We’d like to use those ideas to discuss the concept of “plugin health”, how it might help users, and how it might help maintainers.
As per my initial understanding of this idea, it looks like the end goal of this project might be a centralized place where users and/or (potential) maintainers can visit and get an overview of all the Jenkins Plugins and their “health” in terms of scores or bars. As mentioned by you, a plugin’s health will be calculated based on the checklist/factors mentioned in the attached Google Doc above. So, it would be like a dashboard that can provide you with information ranging from:
high-level data, like, how many plugins have a health score of 3/10 and needs immediate maintenance,
to deep-level data, like, the reason behind the xyz plugin’s health score being 3 is that it has not yet updated its parent POM and so on.
Question: Is that how you see it? Or am I missing something?
Our thought behind it is that yes, the “health score” would be calculated from a central location like the update center, on a list of criteria (still to be determined exactly what criteria should be accounted for, would love suggestions and reasoning) like code coverage statistics, dependabot, spot bugs, release date, avg time to merge a PR, etc. This grade would then appear in a place like https://plugins.jenkins.io/ right on the plugin tiles. Clicking on the grade would then take you to a “how we calculated this score” with helpful doc on how to improve your score. We think this would give a users a better idea of what plugins are current, secure and reliable as well as help or motivate maintainers to achieve an all around better plugin. Please correct me if I have mischaracterized this @alecharp@MarkEWaite
Your reply gives me a clearer picture, thanks!
I see, so with this project, we want to give users a way to see plugin health and allow them to take a peek at what improvements are needed for a plugin to increase its health score.
We don’t plan to work on those suggested improvements and increase health scores by ourselves as part of this project, we leave it on the users and maintainers to act upon. Did I get it right?
I’m asking this because as per the descriptions of the projects, “Plugin Health Score” and “Automating plugin build metadata updates” have some things in common if I’m not wrong.
Exactly right! This project is about implementing the actually grading system, giving that clarity and guidance to both users and maintainers, not about making the improvements to the plugins ourselves!