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
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.
- 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- 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
but if the parent can be used without the child (extension) then how does that parent get found in isolation. The only case of not labelling the parent is when it provides no user feature in my opinion (eg it's a pure api plugin)
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" labelThis 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.
- 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- 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" labelTBH 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.
> 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 labelbut if the parent can be used without the child (extension) then how does that parent get found in isolation. The only case of not labelling the parent is when it provides no user feature in my opinion (eg it's a pure api plugin)
--
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 jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/a4bee5a1-5fcc-4fbe-a8e6-bf8e27257328%40googlegroups.com.