I've been wondering about this as well. It seems that we can have a rather mature project still incubating after a number of years. We can have active consumers relying on it but the momentum of the original project and maintainers waned. Multiple external forks have been made with the inability to get contributions accepted.
In the example of Livy, action was triggered by the threat of retirement. We certainly need an earlier flag than this. Perhaps a specific trigger in the board report reminder email for podlings that are getting long in the tooth that they should include various metrics: * Graduation Status * Community issues for both users and maintainers - what are the barriers of entry for each - complexity in maintenance, language use, continued relevance, etc * Are there known forks with extensions that would have rather contributed back? Based on this, some intervention with new Mentor/s to assess and guide can be advised? Unfortunately, this would require some oversight from the IPMC to identify these podlings before they get too far down the abandoned road. Maybe this is a simple report to see how long they have been incubating though? On Tue, Oct 18, 2022 at 3:55 PM Josh Fischer <j...@joshfischer.io> wrote: > > One might even do this review (gasp!) over Zoom, so that people can > ask questions and have them answered in real time > > + 1 Julian. I appreciate this. > > I'm on one of these projects (Heron) that has been in the incubator for far > too long. I think where Heron fell short in its journey was the steep > learning curve it takes to build, maintain, and use Heron which caused our > community to dwindle over time. So in Heron's case, I don't feel it's > anything that happened in the incubator. It's mainly the complexity of > maintenance. > > > > > On Tue, Oct 18, 2022 at 2:35 PM Julian Hyde <jh...@apache.org> wrote: > > > One idea is to schedule a review after the project has been in the > > incubator longer than the median time (say after 2 years). Deep-dive > > into what is going right and wrong, identify things that can be fixed, > > and set targets. And schedule another review a year later. Or schedule > > a vote to retire. > > > > One might even do this review (gasp!) over Zoom, so that people can > > ask questions and have them answered in real time. > > > > It sounds shockingly invasive, considering we at Apache tend to do > > everything asynchronously. But it's better than the alternative, which > > is a slow death as mentors and initial committers drift away. > > > > Julian > > > > > > > > > > On Tue, Oct 18, 2022 at 12:27 PM Justin Mclean <jus...@classsoftware.com > > > > wrote: > > > > > > Hi, > > > > > > Looking at the longest incubating projects, one has graduated and needs > > some cleanup, one had a reboot, one is discussing a reboot, and several > > have roll calls in progress or are discussing retirement. However there > are > > two or three other projects that either should retire or graduate and > have > > been incubating for far too long. > > > > > > But taking a step back what can we do to make projects life though the > > incubator shorter? Would having more resources help? (If so what > > resources?) What else might we be able to do - offer training for > instance? > > > > > > Kind Regards, > > > Justin > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > >
