On Tuesday, March 10, 2020 at 2:23:10 AM UTC-6, Oleg Nenashev wrote: > > I suggest to discuss it at the next Docs SIG meeting (Mar 13). Sorry that > I did not follow-up timely. >
I've added it to the agenda for the next Docs SIG meeting, March 27, 2020. We've shifted Docs SIG meetings to monthly on the fourth Friday of each month. > > 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 > > That's a very good point. I assumed we would address that class of problem by assigning the 'github' label to one plugin, 'blue ocean', then rely on the Jenkins dependency resolution process to load all the necessary dependencies for that plugin. Same principle would apply to Bitbucket. That was what I was trying to express with "Skip labels provided by parents". In that sense, the Blue Ocean aggregator is the parent and would be labeled github, bitbucket, git, and more. The plugins automatically installed as dependencies of the blue ocean plugin would not need any of those labels. I think you're correct that the user value of a label is reduced significantly if the list of plugins with that label is cluttered. I think clutter could be reduced significantly by choosing to label aggregators without labeling the things which are dependencies of the aggregators. > 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. > > Yes, I knew there was a contradiction in those two principles. I wanted to encourage the application of all the principles, with the "Skip labels provided by parents" as a principle of exclusion. The git client plugin would be included by the first 3 principles but then would be excluded by the "Skip labels provided by parents" principle. > >> 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. > Agreed that I would love to have feedback from plugin maintainers whether they would label with "downstream consumer plugin" labels. Would the maintainer of "Basic Branch Build Strategies" be willing to add labels for github, bitbucket, gitea, and gitlab? > > 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/98065639-c8e0-44dd-a2ed-40c9491050be%40googlegroups.com.
