Vamos a empezar con la responsabilidad que suele ser asociada al rol de Trusted Committer: Asegurar la calidad del producto.
En una comunidad InnerSource, los Trusted Committers poseen todas las decisiones relacionadas con lo técnico, especialmente aquellas relacionadas con la calidad del producto. La posesión implica la necesidad de asegurarse de que se sigan las decisiones vigentes. Esto incluye comunicar y, si es necesario, abogar por estas decisiones, dentro y fuera de la comunidad. Pero los Trusted Committers no tienen que tomar todas las decisiones técnicas por ellos mismos, tampoco hacer todo el trabajo para implementarlas.
Es el trabajo del Trusted Committer el comunicar y clarificar los estándares de calidad en su comunidad, al igual que formularlos de una forma que sean entendibles y accionables para sus Contribuidores. Esto incluye documentación escrita, por supuesto, pero la forma más efectiva para que los Trusted Committers comuniquen estos estándares de calidad es con el ejemplo. Nosotros pensamos que puede ser un objetivo valioso para una comunidad InnerSource el intentar distinguirse de los proyectos de desarrollo de software tradicionales, no solo en la forma en la que organizan el desarrollo, sino también, en la calidad de software que producen. Un alto nível de calidad de software es esencial para establecer y mantener la confianza en la comunidad InnerSource, por parte de los usuarios y jefes. Todos conocemos como un mal lanzamiento puede destruir la confianza en un instante.
Los Trusted Committers también se aseguran que la comunidad tiene la infraestructura y las herramientas necesarias para producir software de calidad. La revisión por pares, usualmente realizada como parte de pull requests (PRs), se usa principalmente para asegurar la calidad. Aunque cualquiera puede empezar y participar en un pull request señalando mejoras necesarias, generalmente es el Trusted Committer quien tiene la última palabra al aceptar y fusionar o rechazar una contribución. A esto nos referíamos cuando dijimos que "los Trusted Committers pueden publicar código mas cerca de producción". Los Trusted Committers también deben ayudar a los Contribuidores durante una PR para llevar sus contribuciones a término.
Dicho esto, al final es trabajo del contribuidor hacer que esto suceda. El trabajo de un Trusted Committer no es el aceptar todas las contribuciones por defecto, pero es solo aceptar aquellas que cumplan con el criterio definido en términos de calidad y alcance. Y los Trusted Committers deben evitar a toda costa reescribir el código del contribuidor para hacer que "encaje", incluso si esto significa usar mas tiempo en apoyar Contribuidores en una PR. Los Trusted Committers toman una perspectiva a largo plazo y entienden que este tipo de apoyo es una inversión para la longevidad de la comunidad, y que a la larga va a incrementar la velocidad de desarrollo de la comunidad.
Alguna veces los requerimientos o limitaciones no son conocidos desde el inicio, en su lugar son descubiertas durante el desarrollo. Los Trusted Committers también son responsables de asegurarse que estos descubrimientos son atrapados y documentados para los Product Owners y para los Contribuidores.
Pero el alcance de los Trusted Committers respecto a la calidad va más alla de pull requests. Los Trusted Committers piensan acerca de la calidad a un nível estratégico, y aseguran la longevidad del software que se está construyendo. Esto implica responsabilidades orientadas al código para asegurar la limpieza del código y mantener una integridad conceptual del software en su conjunto. Tambíén implica tareas orientadas a la administración, como asegurarse que la comunidad tiene suficiente tiempo para refactorizar su software o, en caso de ser necesario, mover la fecha de lanzamiento a favor de mejoras en la calidad. La efectividad del Trusted Committer está fuertemente relacionada a la salud del código.
Aparte de esto, los Trusted Committers tienen que usar mucho de su valioso tiempo validando y documentado soluciones alternativas para bugs o arquitectura frágil y no van a tener tiempo suficiente para guíar a los Contribuidores.
En conclusión, asegurar la calidad del producto es una responsabilidad clave de los Trusted Committers. Ellos definen los estándares de calidad y guían con el ejemplo. Ellos participan en pull requests y ayudan a los Contribuidores a alcanzar los estándares de calidad. Ellos también toman responsabilidad de la salud a largo plazo del software.
