Quality of Open Exchange packages

I've been running my review collections on OpenExchange now for more than 3 years.
I explained the principle I apply in a past article. 
These reviews are the first step of the quality check in OEX.

My personal Credo
My expectation of OEX  (expressed in extreme) is to see it rather as
a collection of jewels, than just a flea market.

I start this discussion encouraged by @Evgeny Shvarov in his recent comment 

The quality of Open Exchange is very important, of course! 
And we have a set of features and processes are intended to understand 
and improve the average quality of projects. And as OEX is a living 
mechanism it is not possible to "click" and improve the quality forever.

I appreciate your willingness to improve the quality and PRs submission. 
Please suggest what do you think could be introduced more to improve the quality. 
We'll try to make PRs more visible in Open Exchange.

And also the ideas on how to improve the quality of the submissions are very welcome! 

Exactly this "living mechanism" is the core subject of this discussion.

Actually, the OEX team does an excellent job with ongoing verification of the packages.
And I can confirm OEX is not just an archive where you drop your stuff and can forget it.
The outside conditions are on permanent change. Think of releases of the software components,
of changing outside services and references you use.

Most of such changes can be fixed by rather simple Pull Requests on GitHhb.
BUT: This implies that the creator of the package is willing/able to merge it.
- that approach is working in average with acceptable time  [But average is not top qualty]
- though some owners of the repo just are not aware or able or willing to accept.
- and don't even react to personal emails.

This means that such an OEX package is an ORPHAN

I'd like to ask for your opinion on how to handle these orphaned packages!

A few proposals from my side:

• Simply removing/deleting is no option as this destroys valid knowledge and experience
  •  
• Access or even the whole repo could be passed to some expert in ISC.
  • This sounds comfortable but requires additional resources at ISC sins
  • and an active owner to grant access.  The 2nd isn't always guaranteed.
  •  
• Brute force Adoption / Hijacking / TakeOver using forking in GitHub
  • This sounds hard at first glance.
  • But the community has the chance of a working version versus a broken one
  • And the orphan found a new parent that takes care of it.
  • The visibility of the broken version might be subject to discussion,
  •  

I count on your ideas and your feedback.

Robert