We have labels to identify which plugin(s) an issue or pull request is associated with. For example, #2469 has:
Additionally, we have the milestone:
(In reality, a PR should be able to be associated with multiple milestones because we have a monorepo. This isn't possible, however.)
In regards to the labels, they are currently added manually. This is not ideal. It would be very handy if a workflow would automatically synchronize the plugin labels based on the changes files in the PR. So if there is a changed path in "plugins/embed-optimizer" then it should automatically apply the [Plugin] Embed-Optimizer label.
Additionally, the plugin-specific milestone can automatically be assigned based on which plugin has the most changed lines in the PR. This milestone could then change automatically as additional changes are pushed.
As a bonus, when the changelog is being gathered for a given plugin, in addition to looking at the PRs in a plugin's specific milestone, we should also see if there are any merged PRs with the plugin's label which are associated with an open milestone. These can automatically be included in the changelog as well. This solves a manual issue of needing to make sure that a single PR with changes for multiple plugins get a changelog entry in each.
We have labels to identify which plugin(s) an issue or pull request is associated with. For example, #2469 has:
Additionally, we have the milestone:
(In reality, a PR should be able to be associated with multiple milestones because we have a monorepo. This isn't possible, however.)
In regards to the labels, they are currently added manually. This is not ideal. It would be very handy if a workflow would automatically synchronize the plugin labels based on the changes files in the PR. So if there is a changed path in "plugins/embed-optimizer" then it should automatically apply the
[Plugin] Embed-Optimizerlabel.Additionally, the plugin-specific milestone can automatically be assigned based on which plugin has the most changed lines in the PR. This milestone could then change automatically as additional changes are pushed.
As a bonus, when the changelog is being gathered for a given plugin, in addition to looking at the PRs in a plugin's specific milestone, we should also see if there are any merged PRs with the plugin's label which are associated with an open milestone. These can automatically be included in the changelog as well. This solves a manual issue of needing to make sure that a single PR with changes for multiple plugins get a changelog entry in each.