Qual é a réplica canônica de "é código aberto, envie um patch"? [fechadas]


215

O perigo de sugerir algum recurso em um produto, especialmente de código aberto, é que você receberá a resposta "por que não faz isso?".

Isso é válido e é legal que você possa fazer a alteração sozinho. Mas sabemos praticamente que os produtos geralmente melhoram à medida que os programadores ouvem a voz dos usuários - mesmo que esses usuários sejam outros programadores. E, a maneira eficiente de fazer essas alterações pode incluir alguém que já está trabalhando no projeto, adotando a ideia e implementando-a.

Existem alguns termos comuns usados ​​para se referir a problemas de desenvolvimento de software. por exemplo, ciclismo . Existe um termo comum usado que essencialmente responde: "Sim, eu sei que posso mudar praticamente qualquer coisa do mundo - mesmo código fechado. Eu poderia ser contratado e escrever esse código. Mas, neste caso, estou apenas fazendo uma observação que pode de fato ser útil para outro codificador já adequado para fazer essa alteração facilmente - ou apenas para discutir possibilidades ".

[ps (alguns dias depois) - Eu deveria ter apontado que "enviar um patch" costuma ser dito com humor irônico e estou buscando uma resposta espirituosa apropriada.]


16
Eu gostaria de poder votar isso mais de uma vez! (E isso é proveniente de alguém que tem . Submetido patches para um punhado de diferentes projectos e obtido aceitaram Essa atitude você descreve é simplesmente irritante!)
Mason Wheeler

62
Suponho "Como eu sou, um macaco de código desempregado? Tenho uma vida!" não é uma réplica aceitável ;-)
Steven A. Lowe

12
Na minha experiência, a resposta "enviar um patch" geralmente vem depois que o desenvolvedor já explicou por que a adição do recurso não seria prática.
usar o seguinte comando

7
@ Steven, depende de você apenas querer superar o insulto, ou realmente fazê-los fazer o que você precisa. Eu acredito que não é uma estratégia ideal se você quiser a última.

12
@orokusaki: Ou D) Eles consideram o recurso menos valioso do que outros que poderiam estar trabalhando e possuem recursos limitados.
18711 David Thornley

Respostas:


115

É um ponto difícil: como o usuário não paga direta ou indiretamente por um produto, ele não pode solicitar a implementação de um recurso. Não é como se você fosse uma parte interessada ou um cliente direto que encomendou o produto, e nem mesmo um usuário final de um produto comercial.

Dito isto, "enviar um patch" não é uma resposta válida. Não é educado. Não é certo. Mesmo para um produto de código aberto. "Enviar um patch" é a versão curta de:

"não nos importamos se você gosta do nosso produto ou não. Vá modificá-lo se quiser, mas não nos incomode com as solicitações dos seus clientes."

Que tal enviar um patch?

Bem, não é tão fácil. Para fazer isso:

  • Você deve conhecer os idiomas usados ​​no projeto de código aberto.

  • Você deve poder carregar o código-fonte do controle de versão para poder modificá-lo.

  • Você deve ter todas as versões corretas de quaisquer dependências de construção instaladas (incluindo bibliotecas de tempo de execução e ferramentas de construção).

  • Você deve poder compilar esse código fonte , o que não é tão óbvio em alguns casos. Especialmente, quando um grande projeto leva algumas horas para compilar e exibir 482 erros e milhares de avisos, você pode ser corajoso em procurar a fonte desses erros.

  • Você deve entender muito bem como o projeto é realizado , qual é o estilo de codificação a ser usado, se houver, como executar testes de unidade etc. Se o projeto não tiver uma documentação decente (o que geralmente ocorre em projetos de código aberto) ), pode ser muito difícil.

  • Você deve se adaptar ao projeto e aos hábitos dos desenvolvedores que participam ativamente do projeto. Por exemplo, se você usa o .NET Framework 4 diariamente, mas o projeto usa o .NET Framework 2.0, não pode usar o LINQ, nem o Code Contracts, nem outros milhares de novos recursos das versões mais recentes da estrutura.

  • Seu patch deve ser aceito (a menos que você faça a alteração apenas para si mesmo, sem a intenção de compartilhá-lo com a comunidade).

Se sua intenção é participar ativamente do projeto, você pode fazer todas essas coisas e investir seu tempo nele. Se, por outro lado, houver apenas um bug menor irritante ou um recurso simples que estiver faltando, passar dias, semanas ou meses estudando o projeto, então fazer o trabalho em si em alguns minutos é irracional, a menos que você goste.

Então, há uma réplica canônica para "é código aberto, envie um patch"? Acho que não. Ou você explica à pessoa que ela é indelicada ou simplesmente para de falar com ela.


9
Parece que foi escrito por alguém sem experiência em manter um projeto de código aberto.
Rein Henrichs

46
@ Rein: Manter um projeto de código aberto não é diferente de manter qualquer outro projeto. Você tem clientes. Se você ignorar esses clientes, eles deixarão de fornecer um feedback valioso e irão para outro lugar em busca de soluções. Talvez isso seja bom para as pessoas de código aberto, mas eu gostaria de saber se eu seria totalmente responsável por corrigir os erros de um software de código aberto, porque isso me faria pensar duas vezes antes de usá-lo.
Robert Harvey

17
@ Rein: Bem, até agora eu ouvi você dizer duas vezes que não sabemos do que estamos falando. Talvez você possa nos esclarecer, não é?
Robert Harvey

8
@ Rein Henrichs: Seus dois primeiros comentários são ataques '' ad hominem ''. Se houver diferenças entre os dois, diga o que são, em vez de dizer que outras pessoas não sabem de nada.
Andrew Grimm

13
Eu suspeito que a intenção era "Manter um projeto de código aberto não é diferente de manter qualquer outro projeto no que diz respeito a ouvir o feedback do cliente e manter sua boa vontade". Nesse caso, estou totalmente disposto a abandoná-lo, mas, como alguém que manteve vários projetos de software livre, com um punhado a centenas de colaboradores, considero a declaração geral original "incorreta".
Rein Henrichs

79

A réplica canônica é enviar um patch.


47
Ou melhor ainda, dizer: "Eu já fiz seis meses atrás. Quando vocês vão revisar e cometer isso?"
21711 Bob Murphy

14
Normalmente, eu não gosto de respostas curtas, mas essa é realmente a única maneira de responder que certamente termina no resultado que você está procurando. Eles declararam claramente a melhor maneira possível de alcançar seu objetivo. Por que estragar com qualquer solução menor?

19
-1 resposta idiota de código aberto. Nao é útil. (Desculpe.) Não há "réplica" canônica. A melhor resposta (assumindo que o OP não pode simplesmente enviar um patch, o que eu acho que é uma suposição razoável neste caso) é uma das (1) "Não tenho os recursos ou recursos para gerar um patch [e, possivelmente, incluir um link para esta questão] ", (2) eyeroll, sem resposta, uso da ferramenta em seu estado atual ou (3) busca por uma ferramenta melhor.
JohnL4

11
Não precisa necessariamente ser um patch. Fornecer feedback detalhado e refinado também vale a pena. Tudo isso está dizendo é que não espere que eu invista meu tempo para cobrir sua necessidade específica, se você não tiver nada a oferecer em troca.
Evan Solha

67

Essa é a resposta padrão quando os desenvolvedores não acham que farão algo em um prazo razoável, mas isso foi repetidamente mencionado.

É mais injusto quando é repetidamente abordado, mas a pessoa que mencionou mais recentemente não sabe disso e apenas recebe "estamos fazendo correções para isso" imediatamente. Nesse caso, o mantenedor está farto da discussão, mas o usuário pensa que é um novo tópico. De qualquer forma, o mais provável é que você consiga "fazer correções" imediatamente, não leve para o lado pessoal, mas talvez queira ler os arquivos e o rastreador de erros para obter mais detalhes sobre o problema.

Se você mesmo solicita repetidamente uma solicitação, "aceitar patches" pode ser uma exclusão relativamente educada, em comparação com algumas alternativas menos educadas ...

E, é claro, existem mantenedores rudes que dizem "remendando" sem nenhuma explicação para ninguém, mas eu diria que é uma minoria.

Se você já manteve um projeto de código aberto com muitos usuários, saberá que há 100 vezes mais solicitações do que os mantenedores poderiam receber, e muitas dessas solicitações são importantes para o solicitante, mas seriam escandalosamente difíceis, ou perturbaria muitos outros usuários ou teria outra falha que só é visível com uma compreensão global do projeto e da base de código. Ou, às vezes, há apenas pedidos de julgamento, e leva muito tempo para discutir cada um repetidamente.

A maioria das empresas de código aberto não oferece acesso aos desenvolvedores, e você recebe apenas o tratamento silencioso ou uma história educada, porém falsa, do suporte ao cliente. Portanto, no código aberto, pelo menos, você tem algumas opções (pague alguém para codificar o recurso etc.) e, embora os desenvolvedores possam ser grosseiros, pelo menos eles dão respostas diretas. Eu prefiro ter "não" do que o habitual "está no nosso roteiro ... [2 anos depois] ... ainda está no nosso roteiro", tipo de coisa que recebi de vários fornecedores ...

Então, acho que não há uma resposta. Talvez o mantenedor de código aberto esteja realmente muito ocupado, talvez seja um idiota, mas de qualquer forma, provavelmente eles têm um trabalho difícil e entrar em um debate sobre quem tem a última palavra não está indo a lugar algum. O melhor que você pode fazer é contribuir de alguma maneira e tentar ser construtivo.

Talvez não seja código, mas possivelmente há muitas análises e documentação de cenários de usuário que você poderia fazer. Quando eu mantinha o gerenciador de janelas GNOME, muitas vezes teria sido útil para as pessoas analisarem um problema globalmente considerando todos os usuários e anotarem realmente os problemas, prós e contras e o que deveria acontecer de uma perspectiva global.

(Em vez disso, o habitual era começar a arder como se eles fossem o único usuário que importava e não houvesse trocas. E enquanto isso é ótimo, e é um ponto de dados, e muitas vezes eu conseguia ser educado ou até mesmo resolver seu problema eventualmente .. o flamejante não faz nada acontecer mais rapidamente. Apenas confunde emoções e causa desperdício de tempo de todos.


4
@Aaronaught Estive em torno de centenas de projetos de código aberto e não percebi o DIY como uma resposta padrão. É uma resposta a certos tipos de solicitação.
estragos P

2
Tudo o que estou dizendo é que, na maioria das vezes, acho que há algum motivo pelo qual um mantenedor está pelo menos um pouco cansado de um tópico (ou pessoa) antes de dizer "recebendo correções" e pode valer a pena investigar por que você recebi essa resposta. É a minha experiência, fwiw. Se a pergunta aqui é sobre casos em que não há motivo para estar cansado do assunto ou da pessoa, então, certamente, "fazer correções" provavelmente não é uma coisa boa para o mantenedor dizer. Pessoas cometem erros. Eu ainda digo que duvido que uma réplica (ou uma meta-discussão como essa) ajude, mas o envolvimento construtivo às vezes pode.
precisa

5
Além disso, embora possa ser redigido de forma mais ou menos educada, se um mantenedor tiver uma lista de pendências de trabalho em mente, provavelmente terá uma coisa que poderá obter, para cada 100 coisas para as quais eles usariam um patch porque desejariam característica; e ainda há outra categoria de mudanças que eles rejeitariam, mesmo que outra pessoa fizesse o trabalho. Portanto, tem que haver alguma maneira de se comunicar "Eu aceitaria essa mudança, mas não tenho planos de fazer isso sozinho". Algumas pessoas aqui parecem sentir que "Claro, chegando" é a única resposta aceitável. Mas "fazer reparos nisso" é uma categoria real.
quer

2
@Aaronaught aqueles parecem boas frases. Acho que muitas vezes nenhuma ofensa / grosseria é pretendida por "nós aceitamos um patch", mas os programadores geralmente não são os tipos mais sensíveis emocionalmente, podem estar passando por e-mail e o tom não é transmitido muito bem por texto, então é fácil parecer tão curto.
estragos P

2
Na verdade, "usaríamos um patch para isso" é diferente de duas maneiras sutis, mas importantes: (1) não atribui a responsabilidade diretamente ao usuário e (2) reconhece que a solicitação foi seriamente considerada, apesar de não ser implementado. Embora o resultado líquido seja essencialmente o mesmo, é uma resposta muito mais humana. (Ainda assim, não faria mal para adicionar explicitamente o implícita ... mas não temos os recursos para concluir que nós mesmos agora. )
Aaronaught

43

A razão pela qual você obtém essa resposta não é que os mantenedores são idiotas, é porque você não os convenceu adequadamente da proposta de valor deles trabalhando em seu recurso para você .

A melhor resposta é iniciar um diálogo sobre o valor do seu recurso para a comunidade como um todo , para ver se você pode convencê-los a mudar de idéia. Talvez eles estejam certos e saibam mais sobre as necessidades da própria comunidade do que você - mas, novamente, talvez não.

Se o recurso é valioso apenas para você e de pouco ou nenhum valor para a comunidade, acho que o dinheiro é um excelente motivador, enquanto reclamar da atitude deles não é.


15
Claro, talvez eles sejam idiotas. Essa resposta por si só não é um indicador muito preciso, pois também é usada por não-idiotas quando o autor da pergunta é um idiota.
Rein Henrichs

4
Eu também gostaria de acrescentar que, na falta de dinheiro, muitas vezes você pode negociar em espécie por algum trabalho: ajudar na triagem de uma fila de problemas ocupados, sair no canal de IRC e dar suporte, testar patches ou escrever documentação. Projetos de código aberto têm recursos limitados e precisam tirar o máximo proveito deles. Adicionar um recurso é viável se for importante para pessoas suficientes ou importante para pessoas que dão / dão o suficiente. Se o seu caso não for o primeiro, faça o último.
HedgeMage

2
Honestamente, a melhor maneira de convencer um desenvolvedor é mostrar quanto da sua base de usuários deseja o recurso. Os rastreadores de bugs com votação, tópicos de fóruns etc. são muito bons para isso e são usados ​​em muitos projetos de código aberto.
ProdigySim

4
Da mesma forma, quando as pessoas recebem um RTFM ou DAFS como resposta, ou um -1 no SE, é porque o questionador não convenceu adequadamente o respondente da proposição de valor de responder sua pergunta por elas . Tenho certeza que muitos de vocês podem se relacionar com esse sentimento.
Rein Henrichs

11
@ Walter Sim, por isso sugeri convencer a pessoa do "valor da sua característica para a comunidade como um todo".
Rein Henrichs

31

Qual é a réplica canônica de "é código aberto, envie um patch"?

Não há uma resposta razoável que provavelmente faça alguma diferença. Tentar convencer os voluntários a fazer algo que eles não têm intenção de fazer é uma perda de tempo ... ou pior.

Suas opções são:

  • Faça o que a resposta sugere; ou seja, implemente o recurso e envie-o como um patch. É chamado "devolvendo algo".

  • Encontre alguém que esteja disposto a implementar o recurso por dinheiro real. Pode ser o próprio projeto (por exemplo, em troca de patrocínio), alguém associado ao projeto ou algum "codificador de aluguel" aleatório.

  • Encontre um produto alternativo.


Se você recebeu essa resposta quando fez uma sugestão "útil", considere como poderia ter respondido se estivesse no lugar dele. Por exemplo, como você responderia se achasse que a sugestão não valia a pena / foi bem pensada / inteligível / etc, mas não teve tempo ou paciência para participar de um debate prolongado?


Eu estive envolvido em um projeto de SO de código aberto de longa duração, e uma das coisas mais irritantes são as pessoas que se sentam na "galeria de amendoins" e o enchem de sugestões de como fazer as coisas "melhor" que:

  • são incompletos, ininteligíveis ou totalmente sem sentido,
  • são idéias não experimentadas com uma chance objetiva baixa de sucesso,
  • exigiria uma enorme quantidade de esforço para implementar e / ou
  • são contrários aos objetivos declarados do projeto.

Freqüentemente, a melhor resposta é desafiar a pessoa a se envolver no projeto ... e esperar que ela entenda a dica ... "colocar ou calar a boca". Infelizmente, os mais irritantes nem sequer dão uma dica.

Obviamente, a outra resposta a essas pessoas é não responder ou ignorá-las completamente.


7
"Como você responderia se pensasse que a sugestão não valia a pena / foi bem pensada / inteligível / etc" - exatamente como todos os outros profissionais respondem. "Você poderia explicar / dar alguns exemplos do que está pedindo?" ou "Você poderia me dar uma ideia de por que acha que precisa desse recurso?" ou "E se fizéssemos essa outra coisa, isso funcionaria para você?" ou apenas "Obrigado por sua sugestão, vamos considerá-la para uma versão futura". Isso é habilidades interpessoais básicas, não ciência de foguetes.
Aaronaught

12
@Aaronaught - Desculpe, mas você não entende. O desenvolvedor de código aberto típico não tem tempo para se envolver em discussões educadas, mas sem sentido, visando acariciar o ego de seus "clientes"; isto é, fingir se importar, quando uma pessoa meio inteligente pode descobrir que tudo é uma fachada. E para ser franco, acho esse tipo de ego acariciar polidez como condescendente ... e MAIS ofensivo do que ser dito sem rodeios de que não há chance de que eles implementem o XYZ.
Stephen C

6
@ Kurige - na verdade, se as pessoas em questão enviassem patches, DEFINITIVAMENTE seriam considerados. O problema é que as pessoas em questão são "toda boca"; ou seja, não há interesse em fazer nenhum esforço.
Stephen C

10
Porque o desenvolvedor de código aberto típico já tem um emprego e faz seu desenvolvimento de código aberto por diversão. Fazer o que as outras pessoas querem que você faça é trabalhar. Fazer o que você quer fazer é divertido.
ProdigySim

8
@Aaronaught: É necessário tratar muitos idiotas com respeito? Dado um serviço público, haverá pessoas que fazem exigências irracionais, geralmente de forma ofensiva. Lidar com tolos indelicados pode ser uma verdadeira dor. Um requisito de ser respeitoso com eles levaria muitas pessoas para fora dos negócios de F / OS, e isso seria uma perda para todos.
18711 David Thornley

20

A resposta seria razoável se você e o programador em questão fossem iguais e soubessem o mesmo sobre a base de código e a linguagem e todas as outras coisas relevantes a essa coisa específica que você está apontando.

Você não é igual (ou provavelmente o faria), então sugiro uma resposta adequada:

"Não há como eu conseguir fazer o mais rápido e bom possível, e é por isso que pedi para você me ajudar em primeiro lugar. Por favor!"

Acredito que é contrário à natureza humana fundamental dizer então "oh, sim, essa coisa em que passei muito tempo e é muito boa é tão simples que qualquer pessoa pode sair da rua e fazer um trabalho tão bom quanto Eu posso ".


Só que não é exatamente o que eles estão dizendo. Eles estão dizendo "o que você deseja não é algo que a comunidade deseja, então não estamos realmente interessados ​​em trabalhar nisso. Podemos aceitar um patch se você quiser trabalhar nele". Implícito é "também poderemos mudar de idéia se a comunidade o desejar". Lembre-se de que "eu quero que você me ajude " vai contra a natureza fundamental dos projetos de código aberto , onde (para trazer toda a força do meu nerdismo de Star Trek) o bem de muitos sempre supera o bem de poucos.
Rein Henrichs

Bem, a menos que esses poucos tenham muito dinheiro, historicamente falando.
Rein Henrichs

2
@ Rein, não, o que eles estão dizendo é que ELES não querem fazer isso. Tudo isso "a comunidade quer" é apenas um homem de palha. O ponto principal é que um da COMUNIDADE está solicitando isso.

11
"é extremamente indelicado sugerir a criação de um patch se você não souber antecipadamente que, se vier, você o consideraria para o seu produto." Acordado. Como eu disse, é por isso que não uso essa resposta. Eu posso simpatizar com isso, no entanto. "Se você sinceramente quer dizer que" enviar um patch "é para calar as pessoas em vez de delegar trabalho, você concorda que isso foi solicitado por um membro da comunidade e não por um desenvolvedor." Não tenho muita certeza do que você está dizendo aqui, desculpe.
Rein Henrichs

11
@ Thorbjørn Ah sim. Bem, na verdade, os mantenedores de código aberto com os quais estou familiarizado certamente não pensam assim. De fato, fazemos o possível para fornecer diretrizes e documentação para desenvolvedores, para ajudar as pessoas a aprender o projeto e as convenções para contribuir com ele precisamente porque estamos cientes da lacuna de habilidades. Por exemplo, rubini.us/doc/en/contributing
Rein Henrichs


15

A resposta canônica para "enviar um patch" é:

"Eu não tenho as habilidades, experiência ou tempo necessário, então você pode me dizer para onde enviar as caixas de cerveja para o cara que pode fazer isso por mim?"


13

Envie um caso de teste abrangente .


11
Eu gosto deste, porém, muitas vezes leva mais tempo do que enviar o próprio patch! A constante aqui é a hora de se familiarizar com a base de código e é provavelmente a maior parte da criação do teste ou da gravação direta do patch!
Newtopian

11
Eu gosto desta resposta para erros. Mesmo se você não entender a estrutura o suficiente para enviar uma correção, ela economizará uma quantidade enorme de tempo para alguém que o faça. Não há nada menos provável que me faça consertar um problema do que um "bug" vago e irreprodutível que pode ser simplesmente um sistema mal configurado. Não há nada que me faça avançar mais rapidamente do que um simples caso de teste, para que eu possa experimentar rapidamente correções diferentes.
precisa saber é o seguinte

11

"Se você fizer isso, eu incluirei" é muito melhor que "não".

Se você não conseguir fazer o trabalho por um motivo ou outro, explique a circunstância ao mantenedor do projeto em particular.

Se você não estiver disposto a contribuir de alguma forma para um projeto de código aberto que gostaria de usar, procure suporte comercial ou outro produto comercial.


5
Portanto, apenas aqueles que contribuem diretamente têm o direito de reclamar sobre um bug ou um recurso ausente? Tudo bem, eu acho, mas isso também significa que nem os colaboradores nem os usuários têm o direito de reclamar por falta de adoção.
precisa saber é o seguinte

@Aaronaught Não, eles têm o direito de reclamar, mas há um limite para a quantidade de tempo não remunerado que um desenvolvedor pode investir em um projeto e é importante que os usuários reconheçam isso. Em meu próprio trabalho, reservo "Eu gostaria de receber uma solicitação de patch / pull" para recursos com péssimas propostas de esforço / valor da comunidade. Ou para onde o usuário está insistindo que obtenha o recurso AGORA, e não respeitando o tempo de outra pessoa ou outros compromissos do projeto.
precisa saber é o seguinte

10

"Obrigado pela resposta."

Porque:

  • A preço zero, a demanda (solicitações de recursos) excede a oferta (codificadores disponíveis para implementar esses recursos).
  • Ragging em qualquer coisa que é fornecida gratuitamente carece de classe IMHO.
  • Esse é o ponto principal do software livre: pessoas que trazem vegetais e carne para adicionar nutrição à sopa de pedras. Se não posso contribuir com algo, devo estar agradecido por poder comer e não reclamar por não estar comendo melhor.

9

Você não precisa dizer nada. O próprio fato de os desenvolvedores terem respondido é uma indicação suficiente para que eles já saibam que o problema existe e isso causa problemas para (pelo menos alguns) usuários.

No final do dia, nada do que você disser vai convencer o desenvolvedor a trabalhar para você, se ele não quiser.


9

Um bom projeto de código aberto terá um sistema de solicitação de bug / recurso no qual os usuários podem enviar bugs / recursos e outros podem votar neles para que os mantenedores possam identificar o que é importante para a comunidade como um todo. A maneira mais rápida de colocar seu recurso em prática é enviar um patch para ele. Período ... não há como contornar isso.


8

Pessoalmente, eu gostaria de obter uma resposta de "Este é um problema conhecido, mas infelizmente não é um problema a ser resolvido tão cedo. Os desenvolvedores estão trabalhando em outros problemas. Não há ETA no momento".

A resposta "enviar um patch" é muito rude, pois pressupõe várias coisas:

  1. Todos os usuários do programa são programadores ou todos os repórteres de bugs são programadores.
  2. Todos os programadores sabem o idioma em que o programa está.
  3. Todos os programadores conhecem todos os tipos de problemas que um programa de qualquer tipo pode ter.
  4. Todos os programadores têm tempo livre para trabalhar em um projeto de código aberto.

Mesmo se assumirmos que o fabricante da resposta "enviar um patch" sabe tudo o que foi dito acima, isso simplesmente faz a declaração parecer "X horas do meu tempo valem mais do que as ordens de grandeza mais horas do que você gostaria de acordar" para acelerar e corrigir o problema ".

Geralmente, quando recebo uma resposta rude de um desenvolvedor quando pergunto sobre um problema que tenho ou envia um erro, paro de usar esse programa. Eu não uso mais o uTorrent (não é de código aberto, mas o ponto permanece), por exemplo, porque as respostas que recebi no fórum de "suporte" foram muito rudes. Enviei um problema que tive no fórum Bug Reports. O encadeamento foi imediatamente bloqueado com um link para outro encadeamento sobre um problema semelhante, mas diferente em um encadeamento (que também foi bloqueado, é claro). Enquanto isso, abri um tópico no fórum de discussão geral perguntando se alguém havia encontrado uma solução alternativa para o problema. No tempo que levou para salvar esse tópico e voltar e ver que meu primeiro tópico havia sido bloqueado, meu tópico em Geral foi bloqueado e minha conta do fórum foi banida por comportamento perturbador. Eu desinstalei o uTorrent e não voltei desde então.


Você quer dizer "Prefiro receber uma resposta de" em vez de "Prefiro não receber"?
Andrew Grimm

Obrigado pelo primeiro parágrafo em particular. É incrível como uma forma tão básica de cortesia profissional pode ser estranha para tantas pessoas. Seja você pago ou não, a resposta apropriada é reconhecer o problema e explicar seu status (mesmo se o status for "adiado").
Aaronaught

8

Apenas responder "enviar um patch" é uma IMO grosseira, mas ainda assim ... se você usa software de código aberto para algo sério, deve estar preparado para cuidar dele, se necessário.

O seguinte é baseado em uma postagem de Jeremias Maerki (da fama do Apache FOP):

Se algo não funcionar para você, você tem várias opções:

  • Este é um código aberto: você pode corrigi-lo.
  • Se você não pode consertar isso sozinho, pode esperar até que alguém tenha tempo livre e pense que é divertido de implementar.
  • Se isso não acontecer, você pode encontrar ou contratar alguém para fazer isso por você.

Eu acho que é uma versão completa muito válida da resposta "enviar um patch".


6

Toda vez que vejo isso, começo imediatamente a procurar um produto alternativo. Para mim, isso é um sinal perigoso de que os mantenedores não se importam com seus usuários (ruim se o seu projeto for usado em qualquer lugar) ou perderam o interesse no projeto. Ambos geralmente significam que o projeto morrerá em breve ou será atormentado pela estagnação, à medida que os desenvolvedores se recusam a avançar no projeto.

(Observe que não estou dizendo que o primeiro relatório de erro que você vê com esse tipo de resposta é executado. Você deve observar uma tendência geral. Se a maioria dos relatórios de erros terminar com esse tipo de resposta, siga este conselho. Se são apenas algumas, então essas são provavelmente as solicitações de recursos que não se enquadram nos objetivos do projeto ou são extremamente específicas para o uso)

Como o @MainMa disse, começar a contribuir para um novo projeto é muito difícil. A maioria dos desenvolvedores não entende isso, pois trabalha no projeto há meses / anos e isso faz sentido para eles. Às vezes, isso pode ser um erro honesto.


3

Ocasionalmente, brinco que o software livre pode ser livre como na cerveja, livre como na fala ou livre, pois você recebe o que paga.

Enquanto digo isso de brincadeira (trabalho para uma empresa que usa muitos OSS), mas acho que existe uma verdade - se você deseja suporte em nível comercial, precisa usar software comercial com um acordo de suporte adequado ou encontrar um solução de software de código aberto que permite esse nível de suporte (geralmente através de alguém sendo pago para fornecê-lo, mas potencialmente através de sua organização empregando ou atribuindo recursos de desenvolvimento para trabalhar nele).

"Enviar um patch" é irritante, mas destaca algo sobre o OSS e talvez seja um lembrete de que o OSS não é adequado para todos em todas as situações, pelo menos não sem garantir que você tenha uma estrutura de suporte sólida ( internamente, pago por ou através da comunidade).

Costumamos pensar em software que é gratuito como na cerveja, mas não na fala (que é um freeware não aberto). Talvez este seja um caso em que deveríamos pensar no software tão livre quanto na fala, mas não como na cerveja.


2

Mude para uma alternativa bem conservada.

Da minha experiência com projetos de código aberto bem mantidos, é que, se você criar um relatório de bug ou solicitação de recurso bem definido, há uma chance muito alta de ser implementado.


2
Relatórios de bugs e solicitações de recursos geralmente não são bem definidos. Minha experiência é que competência e respeito funcionam bem. Além disso, uma solicitação de recurso bem definida será considerada, na melhor das hipóteses. Pode ser considerado de baixa prioridade, ou pode ser algo que o grupo de projetos explicitamente não deseja fazer (há bons exemplos nas Perguntas frequentes do PuTTY e uma boa lista de solicitações de recursos agrupadas por categorias).
18711 David Thornley


1

Considero que quando alguém está trabalhando em um projeto, fornecendo lançamentos e suporte, um contrato tácito e implícito de suporte entre desenvolvedor e usuário surge. O desenvolvedor assumiu a responsabilidade implícita de oferecer suporte à base de código para seus usuários, incluindo a adição de recursos mediante solicitação.

"Enviar um patch" é basicamente dar o dedo aos usuários, na minha opinião. Isso é contextual - às vezes é um esforço demais para ser implementado, às vezes destrói o projeto existente ou incorre em creaturite com taxas, ou qualquer um de vários outros motivos. Mas, em última análise, está dizendo: "Dane-se, não faça isso". O que, em minha opinião, é, em algum nível, uma violação desse contrato tácito.


Não é um contrato, a menos que ambos os lados recebam algo. O que o projeto normalmente quer são relatórios de erros bem-feitos e solicitações de recursos frequentemente bem-feitas, e nem todos os que chegam até o final do contrato implícito.
18711 David Thornley

11
@Aaronaught: Eles estão fornecendo testes gratuitos apenas se apresentarem relatórios de erros detalhados o suficiente para trabalhar. Eu já vi minha parte nos relatórios de erros ruins. Eles podem ou não estar fornecendo boa publicidade. A maioria das pessoas que usa o F / OSS não devolve nada útil, o que é bom, mas com certeza não é o lado de um contrato.
18711 David Thornley

11
@ David: Você poderia parar de tentar restringir a conversa apenas aos usuários mais difíceis / improdutivos? Se vamos generalizar, essa generalização deve ser para toda a base de usuários e colaboradores como um coletivo; liberar para o público leva você a todas essas pessoas. Em troca do bem que você obtém de muitos deles, você obtém alguns problemas de muitos outros. Isso é vida.
Aaronaught

11
@Aaronaught: Se vamos generalizar, precisamos ter certeza de que estamos generalizando adequadamente. Não estou tentando restringir a conversa aos piores usuários, apenas apontando que eles estão lá. Grande parte da conversa parece presumir que todos os usuários são colaboradores de certa forma, e isso simplesmente não é verdade. Se vamos falar apenas sobre os usuários que são úteis para o projeto, parece justo falar apenas sobre os membros da equipe do projeto que geralmente são educados.
precisa

2
@ David: Claramente, existem alguns usuários e colaboradores externos que ajudam, e também alguns que causam problemas. Claramente, alguns desenvolvedores são educados e profissionais na medida em que o bom senso e as boas habilidades de gerenciamento de tempo permitem, e também há desenvolvedores que são rudes e não profissionais por hábito. Esta foi uma pergunta sobre como lidar com o último grupo de desenvolvedores. A existência de "usuários problemáticos" não está em disputa, mas é um arenque vermelho que não serve para nada além de atrapalhar a discussão criando uma situação adversa - então vamos deixar isso em paz.
precisa saber é o seguinte

1

Existem várias maneiras de fazer isso.

  • Proposta de recurso e votação. mas isso leva tempo.

  • Seja contratado por uma empresa que precisa dele para fazer o patch. Obviamente, essa é a melhor solução, mas prepare-se para colaborar com o cara que cria o software de código aberto que deseja atualizar.

  • Descobrir por que o recurso não foi implementado também é importante. Muitas vezes, o recurso está fora da linha do projeto de software: a equipe não deseja esse recurso, não se sente necessário ou apenas pensa que não é a melhor maneira de fazer algo. Nesse caso, você deve apenas bifurcar o projeto e fazer você mesmo.

  • Use software proprietário que faça o que você deseja.

  • Lembre-se de que o software OOP geralmente facilita o processo de integração de um recurso.

  • Se lamentar em uma lista de discussão, no irc ou em um fórum apenas irritará os programadores e dará munição aos proponentes do OSS.


0

Não há nada que você possa dizer que o faça fazê-lo. Afinal, por que ele deveria? Por causa dos desejos de um usuário? Não é uma razão suficientemente boa.

Porém , se você pode coletar um número razoável de usuários e fornecer razões racionais ("Eu quero isso" não é uma razão racional). Por que esse recurso pode ser útil, em geral, e para você e vários outros, ele pode mudar de idéia? .

Embora haja também um caso especial que deve ser considerado. Que dev. está cansado de desenvolver o aplicativo, desejando lentamente abandoná-lo (tem outras coisas a fazer) e, portanto, está abandonando lentamente os pedidos de recursos. Além de tentar convencê-lo a liberar o código, nesse caso, praticamente não há nada que você possa fazer, mesmo com relação ao acima.


Como alternativa, o desenvolvedor tem solicitações de recursos suficientes para mantê-lo ocupado durante o resto do século, gostaria de incluir o seu, mas não prevê chegar a ele tão cedo.
21711 David Thornley

@ David Thornley - Isso também.
Rook

0

Projetos de código aberto, em particular, são amigáveis ​​com recompensas ou financiamento do desenvolvimento de um recurso específico, mesmo que o novo recurso não chegue aos lançamentos oficiais.

Além disso, sim, uma das idéias por trás da publicação de código aberto é que qualquer pessoa e todos tenham o direito e a responsabilidade de fazer suas próprias contribuições.

Com o código fechado, seu melhor recurso é reunir um grupo estatisticamente importante da base de usuários que deseja soluções como as que você deseja.


2
O direito de contribuir, sim, mas da última vez que li a GPL, ela não mencionou nada sobre a responsabilidade dos usuários finais fazerem suas próprias contribuições. Isso é um pouco rebuscado, você não acha?
Aaronaught

0

Na minha experiência, essa resposta geralmente é dada se a solicitação do usuário não se encaixa no objetivo do projeto. Isso acontece quando as pessoas pensam que você implementará tudo o que elas lhe propõem e um pouco mais - de graça, código aberto e um futuro ótimo e feliz.

"Enviar um patch" é uma resposta relativamente rude (e deve ser evitada, é claro. Especialmente nesta forma concisa e nítida. Existem muitas maneiras de expressar aproximadamente a mesma mensagem - por exemplo, "convide" os usuários para ajudar porque você não tenha tempo para implementá-lo por conta própria). Mas, como está, é um indicador claro de "pare de desperdiçar meu tempo". Como tal, não há muito que você possa fazer sobre isso, nem resposta "canônica".

A melhor resposta que consigo pensar é apresentar um patch . Supondo que seu patch funcione, você pelo menos provou que a idéia não é totalmente irrealista. Normalmente, isso significa que as pessoas responsáveis ​​pelo projeto reconsiderarão a proposta.


11
Acho que nenhum desenvolvedor deve responder "enviar um patch" em relação a uma solicitação que não se encaixa no objetivo do projeto. Isso é mais desonesto do que rude. O software fica inchado e o desenvolvedor o odeia, ou ele não aceita o patch e efetivamente desperdiça seu tempo. O último é mais provável. O desenvolvedor realmente deve dizer honestamente "Não queremos mudar isso porque ____" e terminar com isso.
Rei Miyasaka

@Rei Miyasaka: Pessoalmente, eu ficaria furioso se recebesse "enviar um patch", fizesse o trabalho para fazer um patch de boa qualidade e soubesse que eles não queriam o recurso de qualquer maneira.
David Thornley

@David Yeah eh? Eu jogaria uma cadeira ou duas.
Rei Miyasaka

0

"enviar um patch" é uma escova legítima para idéias que não se encaixam nos objetivos do projeto. Provavelmente é melhor, a longo prazo, dizer que a idéia é péssima ou você está tentando usar o projeto para algo muito além do escopo pretendido, mas "ei, se você acha que o que está pedindo é tão trivial, por que não" você tenta encaixá-lo em nossa base de códigos existente "é adequado.

Se for menor e realmente útil para os usuários pretendidos do projeto, basta enviar o relatório de erro, descrever claramente o problema, dar etapas para reproduzir, indicar que você está usando a compilação noturna atual e deixar por isso mesmo.

O que pode parecer uma pequena mudança simples que ajudaria toneladas de usuários pode realmente ser uma enorme dor de cabeça que ninguém usaria além de você. Esse é o melhor caso para "enviar um patch".

Também é possível que você tenha se deparado com um caso como o notório mantenedor da glibc, que parece ter uma mente única de que seu sistema é o universo, sua interpretação das especificações é a palavra de deus, e isso é tudo o que existe, independentemente de quantas pessoas prefeririam o contrário.


Eu não acho que alguém escolheria fazer essa pergunta se soubesse que a mudança seria uma enorme dor de cabeça usada apenas por uma pessoa. Portanto, em vez de "enviar um patch", por que não explicar de forma educada e breve por que é tão importante e não pode ser feito imediatamente?
Shickadance

2
"Enviar um patch" é uma péssima escolha, já que é possível que alguém envie um patch. Deve ser reservado para pessoas com baixa prioridade.
David Thornley

0

Eu sugeriria criar um projeto para implementar o recurso em sites como RentACoder / ELance / etc, e postar sobre ele no fórum original do projeto de código aberto. Qualquer um dos programadores nos projetos de código aberto, incluindo o autor, agora tem um incentivo financeiro para considerar sua solicitação.


-1

Na verdade, me inscrevi apenas para responder a esta pergunta.

Há necessidade de uma réplica? Essa resposta geralmente é usada quando o desenvolvedor conhece o problema, mas não o considera importante.

Vou te dar um exemplo ao vivo. O ubuntu abandonou o suporte systray (mas pode ser contornado pela lista branca de um aplicativo) e adicionou novos indicadores de aplicativo. alguns aplicativos, como Júpiter, contavam com o suporte systray, de modo que o desenvolvedor falou sobre o pessoal de trabalho em vez de adicionar o suporte ao indicador de aplicativo, então pedi ao desenvolvedor para adicionar o suporte ao indicador de aplicativo. A resposta foi "Envie-nos patches". perguntando a razão pela qual eles escolheram não implementar isso. havia isso

Não tenho interesse em gastar meu tempo construindo suporte para uma biblioteca que nunca usarei apenas porque alguém com muito dinheiro exige isso, colocando na lista negra a capacidade de meus aplicativos de funcionar corretamente em sua distribuição Linux simplesmente porque ele pode.

Se fosse um problema técnico real, eu provavelmente entraria em ação, mas essa é uma manobra puramente política, então não, acho que não.

Não, eu vou colocar na lista de permissões

Justo. o desenvolvedor tem motivos para não implementar um recurso, mas está disposto a aceitar patches. isso não é realmente rude e ofensivo, portanto não houve necessidade de uma resposta.

Conclusão: a réplica canônica seria enviar o patch, mas se você não puder, não há necessidade de uma réplica


-1

Inicie uma recompensa pelo recurso que você deseja.

Ou saia e compre o produto que afirma fazer exatamente o que você deseja e abuse do pessoal de suporte quando descobrir que o marketing não corresponde às suas expectativas.


-2

O melhor que consigo pensar é "você é péssimo".

Desculpe, obviamente isso não ajuda muito, mas acho que essa é apenas uma das situações infelizes em que o usuário está completamente ferrado. Um apelo brutalmente honesto à consciência do desenvolvedor é um último esforço.

Você poderia tentar oferta ( tosse ) "doações" para ter seu problema abordado, mas temo que tal prática se fez comum levaria a alguns realmente ruim perda de integridade no setor, como correções de bugs nunca deve ser feita rentável, tanto para Software "gratuito" ou comercial.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.