[GSoC 2023 Project Idea] Add probes to "Plugin Health Score"

Contributing GSoC
1

“Plugin Health Score” was a successful GSoC 2022 project. It laid the principles, the framework, and the automation for this important feature. The first iteration has a just handful probes build in.

A “Plugin Health Score Probe” will be executed on all the plugins to verify the status or measure a given health indicator. Some can be quite simple, but others need creativity and skills. The more probes we have, the better the health score quality and its representativity. Bottom line: we need more probes…

Tagging @jakeleon, @alecharp, @dheerajodha here: what are the missing probes? What probes could be part of a GSoC 2023 project?

/- Jmm

3 Likes
2

Yes there are net new probes like code coverage, spotbugs configured, CI configured, more time based probes (time to review/merge PRs, time to release after approved and merged PRs) that are needed. (we will probably get to one or two of these before GSoC begins) There is also the need to expand some of existing probes, for example, situations where a maintainer may use a similar tool to the one we are currently probing (ala Dependebot probe but they use updateCLI).

Documentation certainly needs to be improved. Documentation of the tool itself, developer help like creating or changing a probe.

We would like to display the scores on plugins.jenkins.io - this could be a fun project for the summer for a front-end focused individual.

2 Likes
3

What about l10n/i18n?

4

Care to elaborate? I have not seen this before

1 Like
5

I’m not so sure this is valid proof of the health of a plugin, but… If a plugin has its property files internationalized, then its potential audience is more prominent, then it can get more pull requests, more issues, and so on… Or not? This may already be reported by another probe regarding the activity of the repository. :thinking:

I think we can forget this proposal, sorry for the noise. :blush:

6

No such thing :slight_smile: - it may be useful as complimentary data to assess a final score, not necessarily a probe own its own. Kind of how I imagine install count to be used. It can be a useful piece of information when assessing a plugin but on its own may be not useful, unfair etc. Will keep this in mind and look into it

1 Like
7

Could you please link the website where the existing probes are listed/described?
Thanks.

8

Plugin Health Scoring :: Probes - here you are!

1 Like
9

Thank you, Jake.
I don’t know if any plugin has already migrated to updatecli or renovabot, but the dependabot probe could maybe be extended.

10

indeed. I spoke with Adrien about this and we were not sure on the usage of other tools on that front. But I think that situation applies elsewhere as well

1 Like
11

Now, what about:

  • comparing the existing parent pom to the latest one?
  • comparing the base Jenkins version to the latest one?
  • see if spotbugs has been configured to catch most of the bugs (
 <properties>
     <spotbugs.effort>Max</spotbugs.effort>
     <spotbugs.threshold>Low</spotbugs.threshold>
   </properties>
  • has a contributing guide
  • has enabled incremental builds
  • has replace Nonnull and CHeckForNull annotations

All of these proposals have been shamelessly taken from “Improve a plugin tutorial”.

2 Likes
12

I think these are some nice and interesting ideas for new probes!

1 Like