[PROPOSAL] Formalized "Roll Call" process for potentially orphaned repos

[epugh]

What/Why

What are you proposing?

There are repositories where the maintainers are no longer active. These repositories are in a zombie state, with no ability to attract new maintainers, but also not marked as archived either.

What users have asked for this feature?

The kubernetes operator was in this state for a while, and the .NET language client is currently in this state.

What problems are you trying to solve?

When we have a orphaned repository, I want a process for either rebooting it with new maintainers, or for responsiblty moving it to a archived state so that we don't convey a broken windows feeling to our community.

What is the developer experience going to be?

Formalize the interaction between the TSC and the maintainers of a repo and establish clearer guidelines. Help the TSC get ahead of potential problems. Have clearer expecations for maintainers going forward.

Are there any security considerations?

Having a single process for vetting new maintainers when this situation happens improves our security posture overall.

What will it take to execute?

We need a defined policy. I am going to draft a potential one below.

Any remaining open questions?

We need to establish a lot more around governance of the project, yet not go overboard as well.

I have taken inspiration from my experiences in the ASF, where I have been on the project that was dwindling and didn't have much activity ;-). Also: https://www.apache.org/dev/pmc.html#roll-call

I have not specified anything about how to be proactive in this process... It starts once we know a repo is abandoned (orphaned?). Not sure the best term. I also am not suing the term roll call, or even running that process. Maybe that is really what we need here?

---

At times the maintainers of a repository may have moved on and no longer be active leaving behind an orphaned repository. This requires an exception process to be run by the Technical Steering Committee to add new maintainers to the repository. Once a repository is considered orphan the following steps are taken:

• An issue is opened in the repo similar to [PROPOSAL] Unmaintained OpenSearch k8s operator repo #60 to track the process.
• New potential maintainers are identified to join the repository. Do we need to say by who?. Do we need to specify how?
• The standard nomination process as documented in https://github.com/opensearch-project/.github/blob/main/RESPONSIBILITIES.md#nomination is begun. notice it says only current maintainers can nominate?
• If, after seven days, there is no reply to the email thread, then a follow up email is sent.
• If, after 14 days, there is no reply to the email thread from existing maintainers then the exception process if followed:
• The nominator shares with the TSC the name and background of the potential candidate to be a maintainer.
• A member of the TSC has a discussion about the responsiblities of being a maintainer with the potential candidate.
• Assuming that is positive feedback, then a ticket is opened with the OpenSearch Project admins similar to [GitHub Request] Add github.com/synhershko as a maintainer of opensearch-k8s-operator .github#405.
• Once completed the original issue in the technical-steering repo is closed.

[krisfreedain]

This is an interesting way to ensure the project keeps maintainers involved, and keeps things moving forward. The first thought that comes to mind is, while it can sometimes be obvious to a lot of us, I think it would do well to ensure "orphaned repository" characteristics are clearly defined.

[andrross]

The standard nomination process as documented in opensearch-project/.github@main/RESPONSIBILITIES.md#nomination is begun. notice it says only current maintainers can nominate?

@epugh I don't think this is quite right. Should it be something like the following?

A TSC member starts an email thread with existing maintainers notifying them of potential new maintainers. The existing maintainers must either start the standard nomination process, or respond with reasons why the proposed maintainers are not suitable and a plan for on-going maintenance of the repo. If after 7 days there is no response, the exception process is followed:

[epugh]

This is an interesting way to ensure the project keeps maintainers involved, and keeps things moving forward. The first thought that comes to mind is, while it can sometimes be obvious to a lot of us, I think it would do well to ensure "orphaned repository" characteristics are clearly defined.

I think this is what I'd like John Mertic to shed some ways of identify and us all to get on the same page about.

[epugh]

The standard nomination process as documented in opensearch-project/.github@main/RESPONSIBILITIES.md#nomination is begun. notice it says only current maintainers can nominate?

@epugh I don't think this is quite right. Should it be something like the following?

A TSC member starts an email thread with existing maintainers notifying them of potential new maintainers. The existing maintainers must either start the standard nomination process, or respond with reasons why the proposed maintainers are not suitable and a plan for on-going maintenance of the repo. If after 7 days there is no response, the exception process is followed:

I like the specificity. I think a question for us to decide is "Is this something the TSC must be involved in", because if yes, then totally. If other folks can spin this process up, then maybe need to rework it. Having said that, in my mind this is a TSC concern.

[horovits]

@epugh thanks for the proposal, see also #99

[andrross]

ensure "orphaned repository" characteristics are clearly defined.

I think this is what I'd like John Mertic to shed some ways of identify and us all to get on the same page about.

@epugh I actually think this policy is pretty clear about what an "orphaned repository" is: the maintainers are unresponsive to both GitHub issues and emails for a specified period of time. The harder problem is if the maintainers do respond but don't follow through. We can tackle that problem if/when it happens, but I like this initially policy to formalize the procedure when all maintainers move on and are no longer paying any attention to the repo.