GitHub Convention

[slawekjaranowski]

No description provided.

[elharo]

Honestly this is overkill. Let's be cautious about making PRs more complex than they are already. I don't like any conventions for commit messages beyond say what the commit does. I've seen so many projects with all sorts of rules about how to format commit messages, and I've never once seen this be of any use at all. The cost vastly outweighs the benefits.

[slawekjaranowski]

The big benefit is to categorize PR in release notes - we should list bug fixes, new features and so on ... grouped by category not in one plain list.

[gnodet]

Honestly this is overkill. Let's be cautious about making PRs more complex than they are already. I don't like any conventions for commit messages beyond say what the commit does. I've seen so many projects with all sorts of rules about how to format commit messages, and I've never once seen this be of any use at all. Thge cost vastly outweighs the benefits.

We kinda do the same in JIRA, we always assign a type to the issue.

[gnodet]

This can be enforced if needed with something like:

name: Check PR Labels

on:
  pull_request:
    types: [opened, labeled, unlabeled, synchronize]

jobs:
  check-labels:
    runs-on: ubuntu-latest
    steps:
      - name: Check required labels
        uses: actions/github-script@v7
        with:
          script: |
            const requiredLabels = ['bug', 'enhancement', 'feature', 'dependencies', 'build', 'other'];
            const prLabels = context.payload.pull_request.labels.map(label => label.name);
            
            const hasRequiredLabel = requiredLabels.some(label => 
              prLabels.includes(label)
            );
            
            if (!hasRequiredLabel) {
              core.setFailed(
                'This PR must have one of the following labels: ' + 
                requiredLabels.join(', ')
              );
            } else {
              console.log('Label check passed! Found required label.');
            }

[elharo]

Enforcement is a major problem for non-comimtter contributors who cannot change labels. Let's not enforce. We can always clean uop labels later before generating release notes.

[elharo]

Again, the issue is not committers. It's non-committer contributors. I'm not sure if this is something we can configure in the repo or not, but in other projects where I am not a committer I have noticed repeatedly that I am not able to apply or change labels for PRs I submit. Now maybe there's a way to give non-committer contributors the ability to edit labels on their own PRs and other projects just haven't bothered to do this. If so, fine. However, if this is a Github limitation, we need to plan for that.

[slawekjaranowski]

It is something what committer should care before merge, I don't see a problem for it.
If it is a problem, so what is your proposition ... how to categorize issues and PR and don't leave it for release manager.

[slawekjaranowski]

I hope we can start working with such limitation and improve it in the future.

[ascheman]

You will need write access to the repository to edit labels, which usually is not the case for contributors, but only for committers. You could have an action which is bound to a custom slash command, like

1. contributor wants a label added by adding a comment with /request-label feature
2. committer approves the label request with /approve-label (which could also be auto-approved by rules)

That said, I doubt that many contributors would make use of it, since it is very uncommon and only very few people know about it. On the other hand it is not much work and probably worth a try. The question then is to educate contributors to learn and use the feature.

Personal opinion: Perhaps it is rather possible to have some AI (GH action) to evaluate PRs and propose labels or even auto-assign labels based on the contents.

[olamy]

Are contributors creating issues in Jira already able to add infos such components or labels?
frankly not sure what is the problem here.
rather the commit use the comment /request-label feature or the commiter add it before/after merging and that's it.

[elharo]

We don't use milestones

[slawekjaranowski]

But I think we should for project with GitHub Issues without Jira ... it is very useful for users.
It clear point to version which fix the historical issue.

[elharo]

Honestly every project I've seen to date that tries to use Github milestones has de facto abandoned them. I don't quite understand why, but developers do seem to ignore milestones after the first few months,

[elharo]

No, titles need to be shorter

[slawekjaranowski]

Yes short but should provide a minimum information about change

When you read a release notes you want to understand what were going in release without reading each changes detail.

[elharo]

We need to make this mandatory and enforced by Github. No review, no commit. Don't do by convention what machines can enforce.

[elharo]

not necessary

[slawekjaranowski]

we have such in Jira ... I think that can be useful to have a priority or importance for issues

[gnodet]

Is that somehow recognized by GitHub ? can we order ?

[elharo]

Can non-committers assign labels? In many, perhaps all, repos they can't.

[slawekjaranowski]

We should know what the kind issue, PR is.
Yes only committer can categorize it - but should not be a problem.

[ascheman]

• You can add new labels (or delete/modify) if you have write access to the repo
• Setting labels requires triage permissions
• Issue Templates allow for automatic labelling (https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository)
• Respective GH Actions could add more logic wrt labelling

[slawekjaranowski]

In next steps we can work on issues templates ... but it should be a next discussion. By the way idea for issues template is very good.

[elharo]

is this really what we want? It sounds diffeerent than what's been proposed before.

[slawekjaranowski]

As @olamy proposition, I agree that we don't need a issue for each PR, PR can describe a problem.

[elharo]

On Thu, Dec 12, 2024 at 8:38 AM Olivier Lamy ***@***.***> wrote: Are contributors creating issues in Jira already able to add infos such components or labels? frankly not sure what is the problem here. rather the commit use the comment /request-label feature or the commiter add it before/after merging and that's it.

Yes, contributors creating issues in Jira (i.e. who have been approved for a Jira account) can assign labels to issues This is a real problem I have seen in multiple other open source projects that adopt policies like this about labeling commits and issues. It is not hypothetical. Any policies and procedures we define for PRs SHOULD be able to be performed by all contributors. We cannot include any step such as "Turn the sonic oscillator three more triangles" in PR and commit instructions when only committers or PMC members are allowed to turn the sonic oscillator. Adding a label to a PR is such a step. IMHO this is a flaw in Github, but one we need to account for. As a second issue, I have yet to see a single project on Github that has reliably and consistently labeled PRs or issues. Whatever the instructions say about labels, these instructions are routinely ignored in practice. —

…

Reply to this email directly, view it on GitHub <#588 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHVP2B7DPJ5W4UAMTQST432FFDPTAVCNFSM6AAAAABTGL3CNSVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDIOJYGMZTIMBSHA> . You are receiving this because you commented.Message ID: ***@***.***>

-- Elliotte Rusty Harold ***@***.***

[slawekjaranowski]

I hope as at beginning it will be ok.
We still can improve it, make some of action automatically and so.

[gnodet]

We need to use GH actions to automate as much as possible to streamline the process for contributors/committers/release managers.