Greetings!

I took a little time to read the discussion, and I greatly appreciated the very healthy discussion.

I found it difficult to disagree with any statement anyone made during the discussion. Even as an individual who has pointed out our struggles with extending trust within our community, I recognize there is a need to ensure balance. Part of that balance we must account for is risk. Risk we must manage and/or ensure it is managed (or somewhat mitigated). But we also want to embrace, enable, and encourage contributors. And this is where things start to become very situational, as there is no reward without some risk. Just like there is no new value if there is no change or improvement. This has led me to wondering what risks are we perceiving and attempting to manage. Which then has me wondering, how do we help enable for success, as success of any specific project should be the goal of any decision. And soon we're back at each individual situation.

My thought process aside, I think it means the answer is somewhere in the Venn diagram of "what is the most reasonable path", "what is the most ideal mutual outcome", and "what will maximize the maintainer's success". I'm sure perceptions will differ for each point, as they should, but a mutual understanding must be reached. I'll note the circles for this Venn diagram which is not at the forefront of my mind (nor, even on the same page/window/screen/desk) is if the project should be considered "active" or if it can be "shipped/delivered" as part of a coordinated release of OpenStack. Truthfully, an "active" status and if the project can be immediately delivered again were not considerations for me. I recognize there is risk with an unknown contributor, and I think expecting everything to be as it once was is also an unreasonable burden to place upon a single individual on-boarding into a community. Ideally, we should be extending trust and verifying when appropriate. In a sense, I'm ultimately sort of then talking about perception and process management as well, and maybe the process needs a new state. Alternatively, it is also okay if a new maintainer wishes to fork or move a project like Monasca, which is okay because we should also embrace change.

And to be quite blunt about this, should someone need to evolve Monasca a little in the OpenStack git namespace as an unreleased project, that seems okay to me as long as we're not forcing Monasca to be an "active" project and to "release". If a new maintainer finds a footing to flourish Monasca as an adjacent in OpenDev or external to OpenDev project, that is also okay. We should encourage whatever the best outcome happens to be for those willing to put in the time and energy. We should not be trying to maintain everything as it once was, and we must be open to change. This is different from an existing or known contributor expressing to keep things "as-is" where they just need a little more access to do the needful.

I do want to express one further aspect, which is that there is no guarantee any individual will be ready/willing/able to engage in six months, nor even tomorrow. Things can come up and get in the way. All we can really do is focus on the moment, embrace, and encourage while understanding the intent. Bonus points are obtained by making additional connections and sharing context to handle the case should something occur.

I hope this helps.

-Julia

On Tue, Jan 9, 2024 at 1:48 PM Jay Faulkner jay@gr-oss.io wrote:

Hi all,

An interesting debate popped up during today's Technical Committee meeting which I thought would be wise to bring before the larger community. I will note, despite this referencing a current event, any discussions about this are about general policies and not any individual persons or situations.

Monasca, a recently marked inactive project, has had someone -- a single individual -- volunteer to attempt to maintain the service. There was some debate among the TC about whether or not this was sufficient to consider Monasca an active project again, with two primary concerns.

First, there were trust-related concerns -- for a project that would essentially be maintained by a single person, is it acceptable to grant core access or appoint someone DPL/PTL (giving the ability to merge code) who is new to the OpenStack community. Some TC members expressed a concern that granting such access, without a commitment from a trusted community member to act as a mentor or monitor on the project, could open us up to insider attacks against our deliverables, while others made the argument that we should default to trust and ensure our community remains welcome to new contributors.

Secondly, there are concerns regarding sustainability -- is it acceptable for an OpenStack project to move from "inactive" to "active" based on the promised maintenance of a single person, with no backup? Some TC members expressed a concern that projects moving from "active" to "inactive" repeatedly are taxing on governance volunteers and not an ideal outcome, while others argued that there is value in keeping projects in the OpenStack release.

There was a very involved debate in today's TC meeting about these topics. I encourage interested parties to review this log before replying. https://meetings.opendev.org/meetings/tc/2024/tc.2024-01-09-18.00.log.html#l...

We have an item on the TC agenda for next meeting, a week from today, to help decide on these items for the sake of Monasca, but it's my hope we can determine a reasonable precedent to apply consistently to these cases going forward. Your input will help guide the decision of the committee on these items.

Thanks, Jay Faulkner OpenStack TC Chair