some practical constraints we may be interested in letting the newcomer communicate with only a subset of the remaining nodes, termed the [*helpers*]{}. For example, reducing the number of helpers decreases I/O overhead during repair and thus mitigates one of the performance bottlenecks in cloud storage systems. In the original storage versus repair-bandwidth analysis of RCs [@dimakis2010network], it is assumed that the newcomer does not distinguish/choose its helpers. We term such a solution the [*blind helper selection (BHS) scheme.*]{} Nonetheless, it is intuitive that the newcomer should choose to access only those “good” helpers of the remaining nodes.

The idea of choosing good helpers in RCs has already been used in constructing exact-repair codes as in [@el2010fractional; @papailiopoulos2012simple] that are capable of outperforming RCs with BHS in [@dimakis2010network] in some instances.[^1] Under the subject of [*locally repairable codes (LRCs)*]{} some additional progress has been done with the goal of minimizing the storage [@gopalan2012locality; @kamath2014codes; @papailiopoulos2012locally]. In the literature of LRCs, helper selection is not blindly decided but is judiciously chosen/fixed (see Section \[sec:comparison\] for an in-depth comparison with these references). We note that there are at least two classes of helper selection schemes:[^2] The [*stationary helper selection (SHS)*]{} schemes, which 