opencode open source : la réalité avec les PR de la communauté, c'est qu'elles sont 99 % du temps bâclées. même dans le cas où cela ressemble à une bonne PR, il y a des choses suspectes. cela prend du temps à l'équipe. nous devons reproduire exactement le bug (car il n'y a pas d'étapes dans l'issue/PR) il y a un changement d'interface sans captures d'écran/vidéo avant/après. il y a du code terrible - nous devrions récupérer le code, le refactoriser/nettoyer, vérifier après. il y a des tests qui ne testent rien - par exemple, ils passent toujours au vert, même après que vous ayez intentionnellement réintroduit le bug. au bout du compte, la plupart des PR ne valent pas le temps qu'il faut pour les examiner correctement. dans le cas d'une implémentation abominable, nous ferons plutôt la correction/la fonctionnalité nous-mêmes depuis le début. cela dit, les bonnes personnes OSS se démarquent toujours, et leurs contributeurs sont intégrés, et ils obtiennent plus de confiance, pour pouvoir faire des contributions plus importantes. même lorsque nous fusionnons des contributions de la communauté, ils ne possèdent pas le code une fois qu'il est fusionné - que se passe-t-il s'il y a un bug fatal et que nous ne comprenons pas totalement le nouveau code ? c'est tout à fait acceptable de disparaître pendant un mois en tant que contributeur OSS. mais c'est un risque que nous devons prendre en compte. au bout du compte, l'équipe doit s'occuper du jardin et imposer un certain niveau de qualité, parfois cela inclut de ne pas fusionner des PR qui semblent prêtes à 80 %. beaucoup de PR diront 'réparez ça URGENT, ÇA CASSERA POUR TOUT LE MONDE, REVENONS EN ARRIÈRE MAINTENANT', mais ensuite la 'réparation' liée à la PR communautaire casse des milliers d'autres choses.