¿Cómo se expresa "es de código abierto, envíe un parche" para que sea amigable?

18

En las respuestas de ¿Cuál es la réplica canónica a "es de código abierto, envíe un parche"? , muchas personas expresaron la opinión de que simplemente pedirles a las personas que envíen un parche es arrogante y grosero.

Pero me parece que como desarrollador en cualquier proyecto de código abierto, verá muchas más solicitudes de características en la lista de correo de las que posiblemente podría implementar. Entonces, cuando un usuario dice: "Me gustaría ver la función X", la verdad es que las posibilidades de que se implementen son bastante escasas, a menos que envíen un parche. Además, a veces un poco de aliento puede ser todo lo que se necesita para convertir a un usuario en un contribuyente.

Por otro lado, no desea asustar a los contribuyentes (potenciales) alejándose como grosero.

Entonces, ¿cómo diría "envíe parches en lugar de solicitar funciones" de manera amigable?

Actualización: ¡ Gracias por todas las sugerencias! Veo que la mayoría de ellos requieren explicaciones bastante largas. Pero como prefiero evitar (a) explicar lo mismo cada dos días (solo lleva demasiado tiempo), o (b) usar fragmentos que pego en el correo electrónico (se vuelve impersonal muy rápido), me pregunto: ¿Alguien escribió esto en un documento que puedo vincular?

(Las cosas específicas del proyecto, como cómo escribir pruebas, compilar el código y enviar el parche, aún deben documentarse, por supuesto, pero creo que esos problemas técnicos deberían ir a CONTRIBUTING.txt de todos modos).

open-source Jo Liss
fuente
10
Muy importante, si no tiene intención de aceptar parches, ¡no lo solicite! Es decir, si dice "Enviar un parche", debe estar dispuesto a aceptar un parche limpio y bien escrito.
edA-qa mort-ora-y
1
@ edA-qa, no necesariamente todos los parches limpios y bien escritos, pero si es probable que vete las nuevas funciones, probablemente debería tener una forma en que la gente pueda proponerle esas funciones para una respuesta probablemente / probablemente no antes de invertir mucho tiempo desarrollándolos.
Steve314
@ Steve, no me refiero a parches no solicitados , esa es una historia diferente. Quiero decir específicamente como en la pregunta, si le dices a alguien que envíe un parche.
edA-qa mort-ora-y
Solo es arrogante y grosero cuando realmente quieres decir "que puede o no ser una buena idea, vete". Si honestamente quiere decir que es una mala idea, dígalo. Si quiere decir que es una idea realmente buena que no tiene tiempo para implementar, dígalo. E indique que estaría dispuesto a aceptar un parche que implementara esa característica. (De esa manera, tal vez alguien realmente envíe un parche). El problema con solo decir "enviar un parche" es vago y desdeñoso.
David Schwartz

Respuestas:

8

Usted no

En lo que he estado experimentando, los contribuyentes candidatos son manipuladores, y no enviarán una solicitud de función simplemente solicitándola. Normalmente lo solicitarán con algún nivel de participación:

  • ¿No sería dulce si [...]? Podría ser posible hacer A, B y C. (Eso es cebo para: no tengo tiempo, pero aquí hay una idea especificada en caso de que lo haga).
  • Aquí hay un parche para hacer / aquí hay una solución para [...].
  • Estoy pensando en escribir un parche [...] para hacer y podría usar comentarios / alguien está interesado en ayudar.
  • Etc.

Los codificadores que envían una solicitud de función directamente lo hacen por una razón. Algunos de ellos incluyen (y sé con certeza que los dos últimos suceden en WordPress, por ejemplo):

  • Son profundos en otros proyectos de código abierto, es decir, no tienen tiempo.
  • Son free-riders y tienen la intención de mantener las cosas de esa manera.
  • Está más allá de su nivel de habilidad / escrito en un idioma del que no saben nada.
  • Usan el software por falta de una mejor opción, y no quieren lidiar con un montón de código maloliente de batsh * t ^ \ b.
  • Ya no pueden ser molestados porque sus parches anteriores fueron ignorados / rechazados, es decir, piensan que estarían perdiendo el tiempo.

Más típicamente, las solicitudes de funciones vendrán de usuarios finales que no podrían contribuir con el parche incluso si quisieran. Especialmente cuando se envía fuera del sistema de tickets.

Creo que su prioridad más importante debería ser no posponer a los contribuyentes potenciales / existentes, en lugar de tratar de reclutar activamente a otros nuevos. Es muy importante, y lo digo por experiencia. Tengo una forma extraña de elegir una nueva base de código, que implica la lectura rápida del código para obtener un cierto nivel de comprensión, saltar al sistema de venta de entradas y corregir errores fáciles de ver para aprender las partes internas en profundidad (y archivar nuevos como pruebo). A lo largo de los años, he inundado algunos proyectos con docenas de boletos y parches. Muchas veces estos boletos recibirán poca o ninguna atención oportuna (ni siquiera un reconocimiento, por ejemplo, ¡sigan así!), Incluso cuando vienen con pasos de diagnóstico documentados y pruebas unitarias adjuntas.

Denis de Bernardy
fuente
1
No podría estar mas de acuerdo. Parece haber un sentimiento general entre los proyectos de F / OSS de que cualquiera que envíe una solicitud de función es simplemente perezoso y podría enviar un parche / modificar su propia instalación si realmente quisiera esa función. Es extremadamente desagradable para cualquiera que simplemente no sabe programar o no tiene el tiempo porque está involucrado en otros proyectos. No son groseras las palabras "enviar un parche", sino la suposición de que el usuario no tiene nada más en su plato.
Shauna
9

En resumen, usted explica que no tiene tiempo ilimitado para hacer su trabajo de forma gratuita. (Puede omitir el bit 'gratis'), y que pueden contribuir en cualquier momento que deseen, no es "su" proyecto, es el proyecto de todos.

así que dices "Lo sentimos mucho, es una gran idea, pero estamos demasiado ocupados con todo el resto del trabajo en curso, lo agregaremos a la lista, pero si realmente quieres incluir esto, y le gustaría ayudarnos contribuyendo al proyecto, entonces sería maravilloso. Tenemos algo de documentación para ayudar a los muchachos a realizar cambios en el proyecto, están aquí, así que si tienen las habilidades y el tiempo y quiere ayudarnos, entonces por favor intente y envíenos un parche con sus cambios. Es posible que tengamos que hacer algunas modificaciones cuando lo recibamos para que se ajuste a los estándares del proyecto, pero nos estará haciendo un un gran favor al menos darnos una ventaja para este trabajo y te amaremos por ayudarnos ".

Por supuesto, una vez que comience a solicitar parches, nunca, nunca, podrá dejarlos en su sistema de tickets durante demasiado tiempo; si obtiene mucho, los integrará más que haciendo el trabajo que solía hacer. Puede que no le guste eso, pero es necesario si desea que sigan apareciendo parches.

gbjbaanb
fuente
Me gusta esto. Quizás esto sea realmente algo mejor incluido en la documentación para que no tenga que copiar y pegar cada vez que necesite explicar esto. Y luego simplemente dice "¿Le gustaría contribuir con un parche? Http: //.../#contributing"
Jo Liss
@JoLiss: Usted criticó mi respuesta por sonar impersonal; ¿Cómo crees que copiar y pegar un hipervínculo a una pregunta frecuente es mejor? Si va a usar una respuesta enlatada, use una que muestre empatía o que suene profesional (o ambas). Esta idea para un atajo no es ninguna; de hecho, es precisamente el tipo de grosería de la que se quejaba la pregunta original.
Aaronaught
Huh, interesante No me di cuenta de que la gente necesariamente lo encontraría grosero si publicas un enlace. Por otro lado, encuentro que las respuestas enlatadas son muy impersonales. Entonces, tal vez sea mejor escribir este tipo de explicación cuando surjan.
Jo Liss
6

Sé cortés y explica la situación con claridad. ¿Qué pasa con algo como:

Gracias por tus comentarios. Consideramos que su función es muy interesante, pero a pesar de nuestros esfuerzos por implementar las funciones más solicitadas en nuestro producto, no tenemos tiempo suficiente para implementarlas todas. Si es desarrollador, puede unirse a nosotros contribuyendo al proyecto, ya que es de código abierto.

Mira, no puedes decir "¿Por qué me molestas con tus solicitudes? No estoy aquí para trabajar de forma gratuita; si quieres esta función, ve e impleméntala tú mismo". La persona puede no ser desarrollador, puede no saber el lenguaje utilizado para desarrollar el producto, etc.

Entonces, en lugar de ser grosero, puede sugerir participar en el proyecto y también explicar por qué es posible que no pueda implementar la función usted mismo.

Otra forma de no ser grosero es no tener que decir nada. Si tiene un sitio web en el que los usuarios de su aplicación pueden sugerir nuevas funciones e informar errores, puede ordenar los elementos según su prioridad: por ejemplo, si una función es solicitada por 10 000 usuarios y otra es solicitada por solo 10 , hay posibilidades de que el primero se implemente primero.

En dicho sitio web, siempre puede poner una sugerencia de "impleméntelo usted mismo" para las características que, después de unos días o semanas, no han recibido suficientes votos positivos de otros usuarios.

Arseni Mourzenko
fuente
5

Gracias por tu solicitud. Lo hemos agregado a nuestra cartera de proyectos y lo revisaremos en breve.

Tenga en cuenta que debido al volumen de solicitudes, no podemos garantizar que se implementen todas. Dependemos de voluntarios, así que si usted es un desarrollador, considere donar parte de su tiempo y enviar un parche . De lo contrario, sepa que todos estamos trabajando arduamente para superar el atraso y responderemos a su solicitud lo antes posible.

Realmente, ¿fue tan difícil?

Aaronaught
fuente
+1 excelente; Buena respuesta profesional. @Jo Liss: tenga en cuenta que la mayoría de la gente simplemente quiere usar el software, no dedicar sus vidas a él.
Steven A. Lowe
Me gusta la esencia, pero personalmente creo que el tono es demasiado impersonal. Por lo general, no es una empresa que presta servicio al cliente, solo es un desarrollador que habla con un compañero. Incluso la gente de 37signals evita este tipo de lenguaje .
Jo Liss
@JoLiss Usted está haciendo servicio al cliente, ya sea que quiera creerlo o no. Y no dijiste nada sobre "compañeros". Es posible que la persona con la que está hablando sea un desarrollador, pero a menos que sepa eso, no creo que sea una suposición apropiada (a menos que esté trabajando en herramientas de desarrollador, pero no especificó eso en la pregunta). Finalmente, los chicos de 37 señales hablan de lo que constituye bullsh * t es ... irónico, por decir lo menos.
Aaronaught
Hm. No estoy seguro de querer dar la impresión de que estoy prestando servicio al cliente ... Sin embargo, su punto de vista de que los usuarios no son necesariamente pares es bien tomada. Con respecto a las señales, aquí hay otra publicación de blog que habla sobre el tono: creo que el punto no es tanto que no debas mentir, sino que no debes salirte como una corporación sin rostro. En mi opinión, esta es una buena estrategia, y es aún más cierto para los proyectos de código abierto.
Jo Liss
2
@JoLiss: Si quieres ser más personal que esto, genial, todo el poder para ti: este es, para mí, el estándar mínimo que debes cumplir en términos de cortesía. No solo diga "enviar un parche", explique que está ocupado, no es perezoso o desinteresado; Reconozca que es posible que no puedan enviar un parche, y que incluso si lo son, de todos modos le harían un favor al obligarlo.
Aaronaught
4

Bueno, en lugar de solo decir "enviar un parche", debes elaborar un poco más.

  • Deje en claro que no tiene el tiempo para hacerlo en este momento o en el futuro previsible, por lo que si otros quieren implementarlo pronto, no hay más remedio que proporcionar un parche.
  • Tómese el tiempo para evaluar la función. Si sinceramente te gusta, no hay nada malo en decir eso. Alentar gente. O si cree que la característica es realmente mala, tómese el tiempo de explicar eso.
  • Proporcione algo de ayuda inicial. Nadie conoce la base del código como tú. No tiene tiempo para hacerlo, pero probablemente sepa exactamente cómo lo haría y dónde comenzaría. Dentro de 5-10 minutos puede compartir el conocimiento que otros necesitarían horas para resolver. Además, esto ayuda a que prevalezca su panorama general. En lugar de tener características alienígenas en tu proyecto, puedes guiar a los contribuyentes a una buena interacción.
back2dos
fuente
Estoy de acuerdo con esto, pero agregaría que necesita pautas muy claras sobre lo que espera de un parche. (por ejemplo, conforme a los estándares del código, unidad probada, documentada). Esto es importante, porque es muy probable que usted sea ​​el que tenga que admitir la función: los remitentes de parches rara vez se quedan para corregir sus errores u ofrecer soporte a otros usuarios de su biblioteca.
Mark Heath el
3

Esto es lo que normalmente digo ...

"Esa es una sugerencia interesante y sería genial si FooBarLib pudiera hacer eso. Desafortunadamente, FooBarLib es solo un proyecto de tiempo libre para mí, por lo que es poco probable que pueda hacerlo en el futuro cercano. Agradezco las presentaciones a FooBarLib, así que si puede implementar esto usted mismo, no dude en enviar un parche (asegúrese de leer primero nuestras directrices "cómo contribuir a FooBarLib").

Mark Heath
fuente
2

Además de las buenas maneras de decir "Enviar un parche", también proporcione documentación orientada al desarrollador para que otros por qué realmente quieran que la característica pueda ponerse al día con facilidad en su proyecto. Muchos proyectos no son amigables para los desarrolladores y requieren días con un mínimo de lectura de miles de líneas de código y toneladas de pequeños casos de prueba hurgando en diferentes partes del sistema para hacerlo bien.

Si proporciona ayuda a los posibles desarrolladores, estarán más que dispuestos a brindar ayuda. Esto significa una buena documentación de código, buenas páginas wiki que explican el flujo (o un buen diagrama UML / pizarra) y una manera fácil de hacer que se acepten parches.

TheLQ
fuente
-2

Realmente me encanta la forma en que github alienta a otros a bifurcar el proyecto. Pueden existir múltiples versiones del mismo proyecto bajo diferentes cuentas de usuario. Si no te gusta la dirección que estoy tomando el proyecto, bifurcalo. Puede enviar fácilmente solicitudes de extracción, pero no está atascado esperando que lo acepte.

Entonces mi respuesta es a menudo, simplemente bifurca.

Mccotton
fuente