jenkins-infra / plugin-health-scoring

This project aims to introduce a metric system to calculate the health score of each plugin within the Jenkins ecosystem and reflect the final scores on the Plugin Site for the plugin maintainers and users.
https://plugin-health.jenkins.io
MIT License
24 stars 46 forks source link

Make `contributing-guidelines` optional for overall score evaluation #255

Closed NotMyFault closed 1 year ago

NotMyFault commented 1 year ago

Preferably, the result of contributing-guidelines should have no impact on the score of a plugin. jenkinsci hosts a few thousand plugin repositories, which (almost) all share the same prerequisites and steps to build. Therefore, we have centralized in-detail resources on jenkins.io, outlining how to build a plugin, what you need locally and how to contribute your changes back.

I feel, adding a contributing file to your plugin repository, with the same information maintained on jenkins.io, just to get your score up, feels like putting an unnecessary maintenance burden on the plugin maintainer.

Of course, there are exceptions and specific plugins may need more than the typical steps documented on jenkins.io, but from what I noticed, these plugins typically have a well-curated documentation how to build them.

Acceptance criteria

alecharp commented 1 year ago

You make a good point.

I would also say that, because we have a CONTRIBUTING.md file in https://github.com/jenkinsci/.github, that contributing guide is even shown on repositories with no specific contributing guide.

For example, mailer (plugin of which I'm a maintainer) as no contributing guide in its repository. However, https://github.com/jenkinsci/mailer-plugin/contribute shows a contributing guide because the organization has one.

So, we could remove the contributing guide probe result from the PluginMaintenanceScoring implementation, but I would like to keep the probe itself with a warning (like not having a contributing guide might be normal). Does this make sense?

NotMyFault commented 1 year ago

So, we could remove the contributing guide probe result from the PluginMaintenanceScoring implementation

According to the probes page, contributing-guidelines has no probes currently, so I assume removing it wouldn't have an impact on the existing scores.

but I would like to keep the probe itself with a warning (like not having a contributing guide might be normal)

I'm not right in the loop how scores are calculated, but if that is a way to ensure your score doesn't go up or down depending on the existence of the file, sure, works for me! That was my concern.

alecharp commented 1 year ago

According to the probes page, contributing-guidelines has no probes currently, so I assume removing it wouldn't have an impact on the existing scores.

some plugins do have contributing guides so there is something wrong with the probe apparently. <-- BUG

I'm not right in the loop how scores are calculated, but if that is a way to ensure your score doesn't go up or down depending on the existence of the file, sure, works for me! That was my concern.

Probe implementations are just "data gathering" implementations. Scoring implementations are using ProbeResult to assess each plugin. The ContributingGuidelinesProbe result is used in PluginMaintenanceScoring. This scoring implementation is contributing up to 12.2% of the global score. And the ContributingGuidelinesProbe result is contributing up to 15% of that implementation.

https://github.com/jenkins-infra/plugin-health-scoring/blob/997a86aef521305a481e5766bbc09637fd41e7f6/core/src/main/java/io/jenkins/pluginhealth/scoring/scores/PluginMaintenanceScoring.java#L60-L62

We could keep the probe, have that in the details of the plugin but not use it in the scoring. This way, maintainers would have the information that they could probably include a contributing guideline if the plugin development requires more or different steps than the one globally available.

NotMyFault commented 1 year ago

We could keep the probe, have that in the details of the plugin but not use it in the scoring. This way, maintainers would have the information that they could probably include a contributing guideline if the plugin development requires more or different steps than the one globally available.

Sounds great, that's what I was looking for 👏