I suggest to discuss it at the next Docs SIG meeting (Mar 13). Sorry that I did not follow-up timely.
Which plugins should be labeled 'github'? > Any plugin that might help a GitHub user get more value from GitHub. For > example, "Basic Branch Build Strategies" is not specific to GitHub but > would provide value to a GitHub user. It should include the "github" label > This is a nice principle, but it is IMHO too wide for interpretation. E.g. Pipeline and Blue Ocean plugins can help a GitHub user to get more value from GitHub integrations. Should we tag around 60 Pipeline/BlueOcean plugins as 'github'? Unlikely, because it will undermine the value of the label by offering a massive number of barely related plugins. There are generic tags like "pipeline" for them. "Basic Branch Build Strategies" is definitely useful for GitHub, as well as many other generic SCM plugins. IMHO we need to provide a clear patch for users to discover such generic plugins, but not through direct labeling (e.g. "Users of this plugin usually install these plugins..." like in online shops). There are also generic "scm" labels which could help to group such added-value plugins Which plugins should *not* be labeled 'github'? > The git plugin and the git client plugin will both be installed > automatically as dependencies of most of the plugins labeled 'github'. > Don't label them 'github' because that label won't help the user get the > most value from GitHub. > IMHO this principle contradicts the first one. > 1. Which plugins should be labeled 'sonar'? > Any plugin that might help a Sonar user get more value from Sonar. > For example, "Warnings NG" is not specific to Sonar but seems like a good > candidate for a "sonar" label because it might help Sonar users > 2. Which plugins should be labeled "gitea"? > Any plugin that might help a Gitea user get more value from Gitea. > For example, "Basic Branch Build Strategies" is not specific to Gitea but > would provide value to a Gitea user. It should include the "gitea" label > > TBH both examples rather convince me that we should reconsider the criteria suggested in (1). It would be great to get feedback from plugin maintainers whether they would label them with such "downsteram consumer plugin" label, but I am not sure about it. BR, Oleg On Saturday, February 29, 2020 at 5:40:24 PM UTC+1, Mark Waite wrote: > > Managing the labels on plugins has become much simpler with the transition > to GitHub topics for label management > <https://groups.google.com/d/msg/jenkinsci-dev/DRzc6TatYSc/D9vDh4qfGgAJ>. > Thanks to Gavin Mogan for the great improvements to the plugins site > <https://plugins.jenkins.io/>! > > When one of the whitelisted labels > <https://github.com/jenkins-infra/update-center2/blob/master/src/main/resources/allowed-labels.properties> > > is added as a topic on a plugin repository, that label will be associated > with the plugin on the plugins site. > > I think there are some general principles to let labels be the best help > for users. I propose: > > - *Label for users - *It is more important that labels benefit plugin > users than plugin developers > - *Label from the whitelist - *Searches by plugin users have better > results when labels are consistent > - *Prefer widely applicable labels - *Labels with very few plugins > using the label are less likely to help users than labels with many plugins > - *Skip labels provided by parents* - When a plugin depends on another > plugin, the dependency will be installed automatically. A label is not > required on the dependency if the consuming plugin has the label > > I think we might also benefit from guidelines for label additions to the > whitelist. For example, possible guidelines might include: > > - Labels should be relevant to at least 5 plugins before they are > accepted in the whitelist. Pull requests to add to the whitelist should > include the list of plugins which should receive the proposed label > - Labels should help users find plugins especially when the plugin > name does not immediately associate with the label > > Here are some samples to test those principles and guidelines: > > 1. Which plugins should be labeled 'github'? > Any plugin that might help a GitHub user get more value from GitHub. > For example, "Basic Branch Build Strategies" is not specific to GitHub but > would provide value to a GitHub user. It should include the "github" label > 2. Which plugins should *not* be labeled 'github'? > The git plugin and the git client plugin will both be installed > automatically as dependencies of most of the plugins labeled 'github'. > Don't label them 'github' because that label won't help the user get the > most value from GitHub. > 3. Which plugins should be labeled 'sonar'? > Any plugin that might help a Sonar user get more value from Sonar. > For example, "Warnings NG" is not specific to Sonar but seems like a good > candidate for a "sonar" label because it might help Sonar users > 4. Which plugins should be labeled "gitea"? > Any plugin that might help a Gitea user get more value from Gitea. > For example, "Basic Branch Build Strategies" is not specific to Gitea but > would provide value to a Gitea user. It should include the "gitea" label > > Comments, questions, concerns? > Mark Waite > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/badd2ce1-0af1-4484-80d3-aef7b9b3eed5%40googlegroups.com.
