Scale and improve ExternalDNS contributions

[Raffo]

I had a chat with @mrbobbytables today on Slack around improving the contributor experience of ExternalDNS.
We (read: the maintainers of the project) have been struggling with maintaining providers and sources, mostly due to bandwidth issues. Different approaches have been discussed over time, without reaching a decent compromise between what we have in terms of bandwidth and what makes sense for the project. For example, in #1447 we discussed having different ways to plug sources and providers, all with possible shortcomings (that's life, I guess).
There's an interesting consideration that is always valid: lots of these problems are not only a maintainers' problem, rather mostly an ownership problem. In that context, it could be interesting to try the following:

• Split sources and providers in dedicated folders
• Add to the kubernetes-sigs orgs anyone that writes/maintains a new provider
• Add maintainers of specific providers/sources to the provider as reviewers first, approvers later

This should allow the "core" maintainers to focus on core and not on other parts and reduce the signal to noise ration in terms of issues as well.

Definition of done

This issue is done if those are done 👇 :

• Split sources and providers in dedicated folders
• Add to the kubernetes-sigs orgs anyone that writes/maintains a new provider
• Add maintainers of specific providers/sources to the provider as reviewers first, approvers later
• We have a better contribution guide that specifies what will be done in terms of membership

Bonus items

Those are nice to have but not required right now:

• Label issues for new contributions / help wanted

Slightly related: #408

/cc @njuettner @linki

[szuecs]

Thanks @Raffo !
I am happy to help and split RouteGroup to its own directory.

[mazzy89]

Hey @Raffo not a Traefik maintainer here speaking however to make progress in the Traefik v2 support, can I be anyhow helpful?

[Raffo]

@mazzy89 if you mean to support another source, I'll have a PR ready to split the sources next week.

[mazzy89]

Yes. I would need external DNS to deal with Traefik v2 CRDs

[ddymko]

Hey @Raffo I would be glad to help maintain the Vultr provider

[vinny-sabatini]

@Raffo and @njuettner I have worked with @seanmalloy on triaging the issues and will try to help chip away at some of them.

[seanmalloy]

I completed adding the "kind" label to all open pull requests. My next step is to start working with @vinny-sabatini to review size/XS and size/S pull requests.

• We have a better contribution guide that specifies what will be done in terms of membership

@Raffo and @njuettner do you just want the contributing docs cleaned up and updated? Or is there something very specific you want done? I think this might be something myself and @vinny-sabatini could complete.

@Raffo and @njuettner would you have any concerns if I was added to this repo with GitHub Triage permissions? I'm a kubernetes-sigs org member and a reviewer for the k8s descheduler. This would allow me to add some additional labels to open issues and pull requests in an effort to help keep things organized. For example I want to add the provider/aws, provider/google, provider/azure, etc labels. I'd take care of submitting the PR here to add myself with Triage permissions. Let me know what you think. Thanks!

[seanmalloy]

PR to start improving contributor experience #1760. After this one is merged I believe I'll be submitting one more PR to get the last bits of contributor docs updated.

[Raffo]

would you have any concerns if I was added to this repo with GitHub Triage permissions? I'm a kubernetes-sigs org member and a reviewer for the k8s descheduler.

I have no concerns, feel free to create a PR for that. Depending on the amount of time and interest that you have, we can go as far as adding you to the approvers list, given that after #1761 we have only two approvers and that is not something good for the project.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[Raffo]

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[seanmalloy]

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale

[timbunce]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.