Looking for collaborators/maintainers

[davideicardi]

Hello!

I'm looking for additional collaborators/maintainers, to help me triage issues, do small fixes, and coordinate the activities for Kafdrop.

I don't think any particular commitment is required. We mainly need 2/3 maintainers (or more!) that using Github "reviewers" feature will ensure a good quality of commits and discuss the evolution of the product (for example, now I plan to update to JDK 17, and I would appreciate some advice...).

Anyone interested?
In case you are interested, please write me an email at davide.icardi@gmail.com, with your github user, so we can share some more information.

@mcs @fape @Bert-R You are the most active contributors of the last year, and I really appreciated your help! If you want to join I will be more than happy!

@ekoutanov What do you think? Any suggestions?

[Bert-R]

@davideicardi I'm willing to support this.

[nicklester]

@davideicardi Also keen..

[ekoutanov]

Invited @Bert-R.

Edit: @Bert-R for now.

[thachlp]

I am interested, just send an email.

[davideicardi]

Thank you!

My proposal is to configure Kafdrop project so that all of us can merge any PR, but it must be approved by at least 1 maintainer (@ekoutanov, @davideicardi, @Bert-R, and more in the future ...). This should reduce the bureocracy at minimum but ensure some quality ...

What do you think? Any other proposal?

[thachlp]

FYI: You can refer to https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners, it will notify all owners if a pull request is opened.
I don't think anyone can merge a pull request with approval is good because, after approval, it can have another commit.

[davideicardi]

@thachlp There is an option to avoid this scenario: Dismiss stale pull request approvals when new commits are pushed

[Bert-R]

My proposal is to configure Kafdrop project so that all of us can merge any PR...

Who are 'us' in this sentence?

[davideicardi]

@Bert-R I don't have access to project permissions (Emil is the only admin), so I'm not sure, but I think that until now the code owners are just Emil and me. For code owners I refer to someone that can merge a PR into master branch.

The main idea of this issue is to extend the code owners teams. I think that Emil should already have added you. Can you confirm that now you have such permissions?

P.S. To avoid confusion in the future, I suggest to use the github codeowners feature

[Bert-R]

@davideicardi I now have permission to merge a PR, so I think we're all set. The GitHub code owners feature is meant for repos that have different owners for different sets of source files. That's not the case here.

The way we could work now that one of us (Emile, you and me) could review a PR, approve and merge it. The master branch is currently not set up to demand PRs and thus approvals are actually not required.

[davideicardi]

In my opinion, the code owner feature is useful to explicit say who are the "owners" of a project. It essentially the only way (as I know) to see who is responsible of it. Apart document it in README... For example it could be useful to ask the right dev for urgent security update. I have used it in the past for other open source project.
Also owners can be automatically added as reviewers.

Regarding PR I would prefer to make it mandatory, to have a single workflow for updates.
So that any PR with 1 approval could be merged without worries by any of us.

For example, these are the expected workflow:

• an external dev create a PR, a code owner approve it. For minor changes he could directly merge it. For more important changes we will wait for another approval from code owners and then merge it
• a code owner create a PR. When another code owner approve it, he will merge it.

But I'm open to other workflows!

[Bert-R]

I'm OK with the code owner feature and I also favor creating a branch protection rule to require PRs and at least one approver. I'd like to make an exception for Dependabot PRs. That can be done by adding a small workflow like this:

name: Auto-approve dependabot PRs

on: pull_request_target

jobs:
  auto-approve:
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
    if: github.actor == 'dependabot[bot]'
    steps:
      - uses: hmarr/auto-approve-action@v3

Such PRs are very common. Glancing over the content is sufficient, no need to also click the Approve button.

@ekoutanov would need to create the branch protection rule:

[davideicardi]

Ok for me!

[mloukianov]

+1 - at least one approval vote for PR before merging

…

-- Max --------------- Max Loukianov +1.512.762.0131 (direct, USA) +7.916.740.3917 (mobile, EMEA) email: ***@***.*** skype: max.loukianov

On Fri, Mar 24, 2023 at 8:25 AM Bert Roos ***@***.***> wrote: I'm OK with the code owner feature and I also favor creating a branch protection rule to require PRs and at least one approver. I'd like to make an exception for Dependabot PRs. That can be done by adding a small workflow like this: name: Auto-approve dependabot PRs on: pull_request_target jobs: auto-approve: runs-on: ubuntu-latest permissions: pull-requests: write if: github.actor == 'dependabot[bot]' steps: - uses: ***@***.*** Such PRs are very common. Glancing over the content is sufficient, no need to also click the Approve button. @ekoutanov <https://github.com/ekoutanov> would need to create the branch protection rule: [image: image] <https://user-images.githubusercontent.com/7149792/227533005-f2a8063f-ae27-4640-a013-05d5ae8306d7.png> — Reply to this email directly, view it on GitHub <#487 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJOQPL2UBYQGZZK7A6ZJMTW5WODTANCNFSM6AAAAAAWBNGCZI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ekoutanov]

Thanks everyone who's put their hand up. For now, I'm going to be inviting those with strong a track record of contributing to Kafdrop.

[ekoutanov]

@Bert-R branch rule modified as per your instruction.

[github-actions]

This issue is stale because it has been open for 30 days with no activity.