Skip to content
This repository has been archived by the owner on Apr 11, 2024. It is now read-only.

Looking for new maintainers #182

Open
derberg opened this issue Jan 18, 2024 · 12 comments
Open

Looking for new maintainers #182

derberg opened this issue Jan 18, 2024 · 12 comments

Comments

@derberg
Copy link
Collaborator

derberg commented Jan 18, 2024

I will be stepping down as maintainer for this repo.

@arjungarg07 afaik from different discussions you also cannot longer work on this repo

@magicmatatjahu I believe you also have different responsibilities


My proposal:

  • Rename this but to "Looking for new maintainers"
  • Pin this issue so it is visible to anyone looking into Issues tab
  • Add note in readme that we are looking for maintainers
  • Create a discussion in community that this project will be archived in 1 month unless someone is interested to take this over and maintain forward
    • must have at least 2 new maintainers
    • maintainers should have some company support or at least provide a proof that they use the project or have a use case for it, therefore they have interest in maintaining the project long term. Basically make sure that we do not get just students volunteers that would treat this project as path to TSC. We basically need experience folks with use cases that can drive project forward independently
  • Ask Thulie to share discussion on AsyncAPI social media and newsletter so potential users of cupid know about it. At the moment we are getting only 24 weekly downloads

After a month from publishing the discussion in social media, if there is noone to take over, we will archive repo and move to https:/asyncapi-archived-repos


Thoughts?

@arjungarg07
Copy link
Collaborator

Hey @derberg, Thanks for creating this. Due to some circumstances I won't be able to contribute to the project. Apologies for the delay in response from my side 🙏🏽
As a result, I would be stepping down as a maintainer and hope for someone to take this project forward for the good of the community.

@derberg
Copy link
Collaborator Author

derberg commented Jan 18, 2024

@arjungarg07 thanks for clarification. So now let's execute the plan and make sure we did everything possible to keep the project alive.

@jonaslagoni
Copy link

jonaslagoni commented Jan 18, 2024

Gonna leave this comment here so I don't forget, but if someone else is interested in taking over please prioritize them 🙂

I might be interested in taking over maintenance 🤔 Although I won't be putting time into it right this second, I still believe in what it can offer in the tooling ecosystem when working with multiple AsyncAPI documents. Especially when I can start using it for https:/asyncapi/EDAVisualiser/.

Here are my current ideas for the library:

  • Support different scenarios such as find lonely channels/topics, find one direction channels (that have no consumers or no producers), find mismatching payloads for same channels, find mismatching content types for same channels, etc.
  • Support extensibility for comparators and extensive options to customize the tool to behave in your unique situation.
  • Switch over to TS (same as for most of the other repo's I help maintain)
  • Introduce CLI for the tool

However, I do have some stipulations to take it over.

  1. Until v1, I want to enforce 0 reviews for maintainers to speed up development time. Once v1 is reached we switch over to a similar contribution guide as Modelina currently has: https:/asyncapi/modelina/blob/master/docs/champions.md#merging-a-pr (don't get the wrong idea, the top priority is onboarding contributors and maintainers in the long run, but staying agile in the beginning)

@derberg
Copy link
Collaborator Author

derberg commented Jan 22, 2024

I still believe in what it can offer in the tooling ecosystem when working with multiple AsyncAPI documents

just to be clear, nobody says the tools is not useful - it is just not maintained and need new maintainers or we should archive it. Npm package is still there if somebody wants to use current version.

@jonaslagoni didn't you just describe a completely new project? also parser rewrite needs to be done here. The only sense to preserve this repo for your purpose is maybe the name and already existing stars - is that what you are looking for?

Until v1, I want to enforce 0 reviews for maintainers to speed up development time. Once v1 is reached we switch over to a similar contribution guide as Modelina currently has: https:/asyncapi/modelina/blob/master/docs/champions.md#merging-a-pr (don't get the wrong idea, the top priority is onboarding contributors and maintainers in the long run, but staying agile in the beginning)

sounds to me like you probably want to start new project on personal account, like with EDAVisualizer and then donate once ready?

@jonaslagoni
Copy link

@derberg it's a complete rewrite of the project, yes, but it does not overwrite what the library currently offers nor its purpose. So re-creating it completely makes no sense to me 🤔

sounds to me like you probably want to start new project on personal account, like with EDAVisualizer and then donate once ready?

Why? 🤔

@derberg
Copy link
Collaborator Author

derberg commented Jan 24, 2024

Why? 🤔

you mentioned 0 reviews for maintainers - so basically one maintainer, cause why would 1 maintainer agree that the other one push to master without review - at least that is how I understand it 🤷🏼

anyway, in the end it is up to maintainers to decide who they run stuff, if they want PR approval before merge or not. Maintainers manage branch protection, so maintainers decide if codeowner PR approval is required or not. We're not gonna tell maintainers how to run things, we can only educate on best practices.


@jonaslagoni so before we start executing the plan, I understand I can mention you there already as one of volunteers, or will you do it under the open discussion?

@jonaslagoni
Copy link

you mentioned 0 reviews for maintainers - so basically one maintainer, cause why would 1 maintainer agree that the other one push to master without review - at least that is how I understand it 🤷🏼

anyway, in the end it is up to maintainers to decide who they run stuff, if they want PR approval before merge or not. Maintainers manage branch protection, so maintainers decide if codeowner PR approval is required or not. We're not gonna tell maintainers how to run things, we can only educate on best practices.

Its not gonna be a solo show, but once the roadmap is laid with however many maintainers there are, it should be easier for the maintainers to evolve the library so early in its life.

Important changes, etc, will of course need to be discussed first.

@jonaslagoni so before we start executing the plan, I understand I can mention you there already as one of volunteers, or will you do it under the open discussion?

What open discussion? 🤔 But yea, if no one else have a strong desire 🙂

@derberg
Copy link
Collaborator Author

derberg commented Jan 25, 2024

I mean this part of plan

Create a discussion in community that this project will be archived in 1 month unless someone is interested to take this over and maintain forward

do you want to be already mentioned there as one of maintainers?

@jonaslagoni
Copy link

Up to you 😄

@derberg derberg changed the title Step down as maintainer Looking for new maintainers Feb 1, 2024
@derberg derberg pinned this issue Feb 1, 2024
@derberg
Copy link
Collaborator Author

derberg commented Feb 21, 2024

discussion created: https:/orgs/asyncapi/discussions/1074

I also asked @thulieblack for social media share

@derberg
Copy link
Collaborator Author

derberg commented Apr 10, 2024

doesn't look like anyone can pick it up. Will proceed with archiving

@derberg
Copy link
Collaborator Author

derberg commented Apr 11, 2024

done - more in https:/orgs/asyncapi/discussions/1074

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants