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