Dans le système actuel, chaque utilisateur a une priorité qu’il garde constante tant qu’il n’a pas atteint son quota et qu’il perd lorsque son quota est atteint. Ceci oblige les utilisateurs à forte priorité à adapter leur rythme de soumission aux besoins des utilisateurs à faible priorité afin qu’ils puissent utiliser leurs créneaux.
Afin de permettre une gestion plus dynamique, prévoir un module ajustant le « quota dynamique » des utilisateurs en fonction du taux de satisfaction de leur « quota statique » fixé au départ.
Ainsi, parmi deux utilisateurs de priorité égale, chaque utilisateur se voit attribuer une pénalité proportionnelle au temps qui lui a été attribué sur un horizon à choisir divisée par son quota. C’est l’utilisateur le moins pénalisé qui a le droit de placer une requête. On recalcule les pénalités après chaque soumission de requête.
Pour ne pas pénaliser les utilisateurs qui ont soumis des requêtes à des dates ou les télescopes ne se sont pas ouverts, on comptabilise le temps de toutes les requêtes positionnées dans le futur, mais pour les requêtes positionnées dans le passé on ne compte que celles qui ont été satisfaites.
Afin de tenir compte de plusieurs nuits d’observation sans pour autant bloquer les utilisateurs soumettant régulièrement des requêtes, on peut introduire un taux de décroissance de la prise en compte du temps consommé pour les dates du passé.
Exemple d’implémentation :

• Pour chaque utilisateur :

  Un compteur « temps consommé les nuits précédentes »¶

  Un compteur « temps consommé la nuit courante »¶

  Un compteur « temps programmé dans le futur » (fin de la nuit ou nuits suivantes)¶

• A chaque soumission de requête, le « temps programmé dans le futur » est incrémenté de la durée de la requête »

• A chaque date de fin d’exécution de requête, le « temps programmé dans le futur » est décrémenté de la durée de cette requête et si la requête a été satisfaite, le « temps consommé la nuit courante » est incrémenté de la durée de la requête.

• A chaque fin de nuit, le temps consommé la nuit courante est ajouté au temps consommé les nuits précédentes puis remis à zéro.

• Le temps consommé les nuits précédentes est multiplié par le facteur de décroissance. Le taux de décroissance est 2-1/t avec t la demi-vie de la prise en compte du temps.
  Exemple de d’utilisation de ce mécanisme :

  Pour une demi-vie de 1 jours, le temps consommé la dernière nuit compte pour 50% de la somme ; le temps de l’avant dernière nuit pour 25% ; le temps de la dernière semaine pour 99% de la somme.¶

  Si deux utilisateurs ont chacun un quota de 50%, un utilisateur qui cède sa part à l’autre utilisateur pendant une nuit aura droit à 75% la nuit suivante ; un utilisateur qui cède sa part 2 nuits consécutives aura droit à 87% la nuit suivante et un utilisateur qui cède sa part 6 nuits aura droit à 99% la nuit suivante.¶

  Un utilisateur qui aurait cédé sa part depuis la nuit des temps n’aurait jamais droit à plus d’une nuit dédiée, les proportions se trouvant rétablies dès le lendemain.¶

  Pour une demi-vie de n jours, un utilisateur absent depuis longtemps peut utiliser jusqu’à n nuits consécutives à 100% avant le rétablissement des quotas initiaux.¶

Ce système permettrait de gérer l’équilibre entre les observations d’événements célestes transitoires qui sont intermittentes et non programmées et les observations de surveillance de l’espace et autres projets scientifiques à l’activité plus régulière. Ça permettrait également aux utilisateurs ayant un quota faible de positionner plus facilement des observations entre les observations des utilisateurs à gros quota.