Closed NotMyFault closed 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?
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.
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.
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.
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 👏
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
ContributingGuidelineProbe
is not used in thePluginMaintenanceScoring
anymore