enhancements

Ce dépôt est le dépôt de suivi des améliorations pour les versions de Kubernetes, détenu par SIG Architecture. Il contient des issues et des KEP (Kubernetes Enhancement Proposals) qui servent de chapeau aux nouvelles améliorations ajoutées à Kubernetes. Une amélioration s'étend généralement sur plusieurs versions et peut être suivie comme élément de backlog avant le début des travaux ; elle peut être déposée une fois qu'un consensus existe dans au moins un SIG Kubernetes. Le README définit ce qui compte comme une amélioration à l'aide d'heuristiques approximatives. Une amélioration est généralement quelque chose qui ferait l'objet d'un article de blog après la sortie, nécessite plusieurs parties/SIG/propriétaires pour être menée à bien, passe d'une étape à une autre (alpha vers bêta, bêta vers GA), exige un effort important ou modifie substantiellement Kubernetes, a un impact sur l'UX ou les opérations suffisant pour que les utilisateurs aient besoin d'une nouvelle formation, ou est quelque chose que les utilisateurs remarqueront et sur lequel ils s'appuieront. Il est peu probable qu'il s'agisse d'une amélioration si elle est mise en œuvre via une CustomResourceDefinition, corrige un test instable, refactorise du code, améliore uniquement les performances visibles sous forme d'opérations API ou de boucles de contrôle plus rapides, ou ajoute simplement des messages d'erreur ou des événements. Les nouvelles issues d'amélioration doivent être créées après avoir fait circuler l'idée (réunions communautaires, réunions SIG, listes de diffusion ou une issue kubernetes/kubernetes), éventuellement prototypé dans un fork, identifié les personnes qui acceptent d'y travailler et être prêt à agir en tant que chef de projet. Le README note que de nombreuses améliorations prennent plusieurs versions et environ 9 mois à un an pour atteindre Stable. Les améliorations sont suivies parce que les utilisateurs s'attendent à s'appuyer sur elles à long terme, le projet les soumet donc à des normes élevées d'intégrité conceptuelle, de cohérence, de tests approfondis et de documentation complète. Les issues de suivi fournissent une liste de contrôle avec différents approbateurs pour différents aspects à travers les étapes Alpha, Bêta et Stable. Les commentaires sur les issues d'amélioration servent à demander une révision ou une clarification sur le processus, à mettre à jour le statut ou à lier des issues connexes dans d'autres dépôts ; les détails de conception, de code ou de documentation doivent être discutés dans les issues ou PR liées. Depuis la version 1.26, les améliorations sont visualisées dans les Enhancements Tracking Boards, avec des liens de jalons de 1.26 à 1.38. Avant 1.26, des feuilles de calcul de suivi étaient utilisées, et une archive de ces feuilles est référencée. Le cycle de version actuel pointe vers les informations de version 1.38 dans le dépôt sig-release. Les exceptions aux dates de jalon des améliorations sont gérées par la Release Team conformément à leur documentation. Les étiquettes incluent `sig/foo` pour le SIG propriétaire, `kind/feature` pour marquer une issue comme une amélioration, et `stage/{alpha,beta,stable}` pour l'étape du processus de fonctionnalité, chacune définie via des commandes de commentaire. Un document glossaire définit la terminologie et les acronymes utilisés dans le sous-projet Enhancements.