Domanda:
Ho riscontrato un errore sul codice di qualcuno pubblicato online: qual è il protocollo?
user30609
2019-07-18 12:33:29 UTC
view on stackexchange narkive permalink

Utilizzo un toolbox di econometria da circa 2 anni ed è fantastico, molto utile. È disponibile sul sito web personale di qualcuno.

Ho riscontrato un errore in una porzione di codice che mi ha riportato indietro per un periodo di tempo considerevole. È un piccolo cambiamento ma con vaste conseguenze. Invece di mettere in discussione il codice, ho fatto la mia idea.

Ora che ho trovato il problema, qual è il protocollo per evidenziarlo? È necessario inviare un'email all'autore?

Ho modificato questo per includere le informazioni dai tuoi commenti alle risposte seguenti.Si prega di modificare ulteriormente se sono necessari ulteriori chiarimenti o se le mie modifiche sono imprecise.
È disponibile su github / bitbucket?In tal caso, crea un problema o anche meglio un fork e invialo su richiesta pull.
Cos'è questo errore?Voglio dire: il problema è che il codice non fa ciò che l'autore pensa di fare (errore di implementazione) o la logica dell'autore è semplicemente sbagliata per l'attività che vogliono risolvere (errore semantico)?Nel primo caso generalmente non è un grosso problema, apri un problema nel repository se disponibile o invia un'e-mail alla mailing list se esiste o solo all'autore.Se è il secondo, può valere la pena una piccola pubblicazione a seconda della circostanza esatta (se lo strumento è ampiamente utilizzato da altri, se la tua soluzione è un'idea nuova, ecc.).
Sebbene possa essere scortese sottolineare gli errori degli altri in generale, quando si tratta di codice, è molto apprezzato.
@Evorlor Come può essere scortese segnalare gli errori?È così che impariamo.
@user2768 Può essere formulato in modo rude, o le stesse persone si offendono anche se è formulato in modo corretto.
domanda secondaria: devo informarli in modo anonimo
@gerrit _Può essere espresso in modo rude_, ma sembra ortogonale.Inoltre, sono d'accordo, alcune persone si offendono.
@user30609 C'è qualche motivo per farlo in modo anonimo?Sembra che ostacolerebbe il processo senza alcun vantaggio.
@user30609 nel caso in cui siano offesi
@user30609 Non credo che tu possa offendere.
Xkcd obbligatorio: https://xkcd.com/386/
Scrivi un test che dimostri il bug.Scrivi una correzione che elimini il bug, come indicato dal superamento del test.Invia quello.
Sei risposte:
user2768
2019-07-18 13:08:23 UTC
view on stackexchange narkive permalink

Ora che ho trovato il problema qual è il protocollo per evidenziarlo, è necessario inviare un'email all'autore?

Non è necessario, ma lo è la cosa giusta da fare , se non lo fai, sei responsabile di causare ostacoli agli altri che faranno perdere loro una notevole quantità di tempo.

commento corretto, mi è stato fastidioso, penserò a un bel modo per scrivere una mail
@user30609 Non pensarci troppo, l'email deve solo dire qualcosa del tipo: _Dear A, utilizzo la tua cassetta degli attrezzi econometrica da circa 2 anni ed è stata molto utile per il mio lavoro.<< Facoltativamente menziona alcuni dei tuoi lavori, possibilmente racchiusi tra parentesi. >> Recentemente ho scoperto un piccolo errore nel codice: << descrivi l'errore (e correggilo se noto) >>.Forse puoi implementare questa correzione e includerla nella tua cassetta degli attrezzi;risparmierebbe ad altri la frustrazione del debug per ore._
I programmatori adorano le correzioni gratuite al loro codice.Le due volte in cui ho informato i programmatori ** e ** fornito la correzione insieme all'e-mail, è stata distribuita entro 24 ore.
Codificatori @Nelson ... probabilmente.Ma siamo onesti: c'è * un sacco * di codice PANTA negli accademici (Pubblica e non toccare mai più).Si potrebbe fare l'avvocato del diavolo e dire: se fossero interessati a mantenere il codice, lo metterebbero su un SCM pubblico e non offriranno solo alcuni ZIP su un sito web personale.Ma vale la pena provare, ovviamente: la cosa peggiore che può accadere è che il messaggio venga ignorato ...
@Marco13 Potrebbe essere che semplicemente non conoscano il controllo del codice sorgente.Fino a poco tempo fa, anche i neolaureati in CS lo sapevano raramente.
@user2768 Non chiamatelo errore;è maleducato.* Recentemente ho superato un ostacolo nel mio progetto modificando XYZ nella tua libreria.Spero che tu possa dare un'occhiata e determinare se questa modifica deve essere applicata al tuo codice sorgente o se ho violato il tuo codice in un modo non supportato, grazie. *
@MonkeyZeus Non ho mai avuto questo.Perché è scortese segnalare un errore, quando è un errore?Tutti sbagliano.È _ più chiaro_ dire che è un errore che deve essere corretto, invece di "superare un ostacolo" che richiederebbe un po 'di tempo per analizzarlo.Perdere tempo non è più scortese della franchezza?
"se non lo fai, sei responsabile di causare ostacoli agli altri" - è molto d'accordo.Ricordi che hai trovato quella stranezza durante l'utilizzo di OSS e non l'hai mai segnalato?Quella stranezza ha danneggiato la mia produttività, di conseguenza non ho più il mio lavoro e sono senza casa - grazie mille per aver rovinato la mia vita, amico.Oh, l'hai segnalato?Uhh ... dove?Perché dovresti segnalarlo su qualche forum di cui non ho mai sentito parlare in vita mia?Mi stai nascondendo alcune informazioni in particolare?Ti imparerò ad assumerti la responsabilità delle tue azioni.Il mio avvocato si metterà presto in contatto.
@vaultah È parabolico.Quando stai usando OSS, non devi solo * anticipare *, ma * presumere * che le persone rovineranno le cose (e le solite dichiarazioni di non responsabilità possono essere trovate in LICENSE.md).I vantaggi ideali dell'OSS entrano in gioco quando tutti giocano secondo le regole e molti accademici no.Quando il finanziamento è finito, non si preoccupano del codice e proiettare le responsabilità sugli altri è inappropriato.
Concordato.Il principio è spiegato in [Matteo 18: 15-17] (https://www.biblegateway.com/passage/?search=Matthew+18%3A15-17&version=GW), che può essere *** MOLTO ***Tradotto liberamente come, * "Se il tuo collega programmatore sbaglia, vai a mostrargli l'errore, uno contro uno. Se corregge il bug, probabilmente te ne sarà grato e ti sarai fatto un amico. Senon corregge il suo bug, quindi chiede a uno o due altri che potrebbero avere più successo convincendolo a provarlo. Se ancora non risolve il suo bug, diventano pubblici e pubblicano la correzione on-line. "* In realtà è solo un'applicazione della regola d'oro.
Ovviamente l'OP non è responsabile per eventuali danni derivanti se non lo segnala.Penso che questa risposta non significhi "responsabile" in un senso "sei da incolpare", ma più "avresti potuto prevenirlo con il minimo sforzo" - e molte persone dormono meglio la notte e possono condurre una vita più felice, se lo sannohanno fatto la cosa giusta, indipendentemente dal doverlo fare o che qualcun altro fosse in colpa.
@Falco No, per _tu sei ** responsabile ** di aver indotto gli altri a tirarsi indietro_, volevo davvero dire che _ sei ** la colpa ** per aver provocato altri arretramenti_.(Non c'è problema di responsabilità per eventuali perdite di tempo.) Credo che l'OP abbia la responsabilità di agire.
@user2768 Non credo di poter essere d'accordo con questo.Non biasimerei qualcuno per non aver fatto di tutto per aiutare gli estranei, dove non sa nemmeno se vogliono o hanno bisogno di aiuto e se l'autore si preoccupa davvero.Penso che sia una cosa carina da fare e lo farei anche io, ma non biasimerei mai qualcuno per non averlo fatto - non lo vedo come un dovere che deve essere fatto, ma piuttosto un buon atto che si potrebbefallo se vuole fare qualcosa di carino.
@Falco Lo vedo come un dovere.(Vale la pena notare che l'OP non sta _ facendo di tutto per aiutare gli estranei_, deve semplicemente inviare una singola e-mail.)
@user2768 stiamo approfondendo la morale / filosofia qui.Ma probabilmente ci sono un milione di piccole cose (piccole come inviare un'e-mail) che potresti fare ogni giorno, il che renderebbe migliore la vita di altre persone.Se tutti fossero un dovere, non avresti tempo per te stesso.
@Falco Sto semplicemente identificando quello che considero un dovere di ricercatore.Non considero le _milioni di piccole cose_ a cui sfuggite come parte del dovere di un ricercatore.Potresti scrivere la tua risposta, dato che non sei d'accordo.
Ho votato contro la tua risposta, perché scrivi semplicemente "è la cosa giusta da fare", che è anche la mia opinione.Solo nei commenti esprimi esplicitamente il fatto che lo vedi come un dovere avvincente per ogni ricercatore.La differenza è giusta, sono d'accordo che uno è un essere umano migliore se lo fa, ma non peggiore se non lo fa.
Non sarei sorpreso se ci fossero documenti là fuori deliberatamente pieni di errori con l'intenzione esplicita di far perdere tempo ai ricercatori, in particolare il tempo di quei ricercatori efficaci e coscienziosi abbastanza da notare e prendere il tempo per sottolineare questi errori.
TheLuckless
2019-07-19 04:16:15 UTC
view on stackexchange narkive permalink

Un punto importante dell'etichetta che è stato ignorato nelle altre risposte:

Trattalo come un bug sospetto e non dare per scontato "Ho ragione, tu" ti sbagli "durante la presentazione della tua correzione.

  • Non importa quanto tu sia sicuro della questione, c'è sempre spazio per aver interpretato male o trascurato qualcosa di importante.

Considera il caso di trovare un "errore" nel codice di: 

  (A + B)

E decidi tu che tutti i tuoi casi d'uso devono essere: 

  ABS (A + B)

I tuoi casi d'uso potrebbero non includere la necessità che quell'eventuale aspetto negativo esista, o anche essere in grado di gestirlo quando lo fa, ma ciò non significa che i casi al di fuori della tua considerazione potrebbero non richiederli.

  • Inizia con il presupposto che i programmatori originali ne sappiano di più sul codice di te. [In realtà potrebbero non esserlo, ma le opinioni degli altri possono sempre essere rivalutate ...]
  • Avvicinati come se avesse l'obiettivo di ottenere reciprocamente una migliore comprensione di ciò che il codice sta facendo e di ciò che dovrebbe fare e come viene effettivamente utilizzato.
  • Considera di formulare eventuali suggerimenti per modifiche / miglioramenti come domande piuttosto che comandi . ["Vedi qualche difetto nel mio tentativo di risolvere il mio problema?" vs "Dovresti invece usare il mio codice."]
Completamente d'accordo!!
L'OP scrive, _Ho trovato un errore in un pezzo di codice_, quindi questo non risponde veramente alla domanda, mette in dubbio la legittimità della domanda e risponde a una diversa.
@user2768 - _Pensano_ di aver trovato un errore, e probabilmente l'hanno fatto, e hanno chiesto un protocollo su come gestirlo al meglio.Parte del protocollo corretto è lasciare la porta spalancata alla possibilità che in realtà ti sbagli sulla natura dell'errore che hai trovato ... Se pensi che questo risponda a "una domanda diversa",perso il punto della risposta.
@TheLuckless Pensi che l'OP _pensi_, ma potrebbero _davvero_ sapere_ che c'è un errore.Non è impossibile, l'ho fatto io stesso in numerose occasioni.Ho anche pensato che non ci fosse un errore e seguo il tuo consiglio quando sono in dubbio.
@user2768 non importa quanto si "sappia" di un bug del software, _ il galateo corretto_ è quello di _ancora presumere che tu possa sbagliarti, non importa quanto sei sicuro di avere ragione_.È la posizione educata per iniziare una conversazione del genere e ti copre il sedere se in realtà trascuri qualcosa.- Inoltre, non dimenticare che è anche del tutto possibile che ENTRAMBE le parti si sbagliano.Bug nel codice e nel design non sono esattamente rari ...
Non credo sia appropriato preoccuparsi di chi ha ragione e chi ha torto.Forse hanno ragione entrambi.Forse si sbagliano entrambi.Non importa.
@TheLuckless Ci sono casi in cui penso che sia sbagliato, ad esempio, le prime tre cifre di pi sono definite come 3.13.In questi casi, non ha davvero senso _assumere che potresti sbagliare_, chiaramente approssimare pi greco come 3.13 è sbagliato.
@emory: Gli esseri umani non sono robot.Siamo * molto * più disponibili ad ascoltare "Puoi aiutarmi a capire X?"invece di "X è il motivo per cui ti sbagli".È una questione di tatto, niente di più.
@Kevin Supponiamo che io scriva del software basato su Freedom Units.Posso riconoscere che il software sarebbe più generalmente utile se scritto in unità metriche senza accettare una modifica.Mi interessa solo la mia utilità.Questa è la bellezza del software open source.Se vuoi, puoi eseguire il fork su unità metriche senza il mio permesso.
Solar Mike
2019-07-18 13:17:17 UTC
view on stackexchange narkive permalink

Hai 3 possibilità:

  1. Contatta l'autore come per l'altra risposta. Opzione migliore basata sui commenti successivi che rivelano che la fonte era un sito web personale.

Se il codice è stato pubblicato in un articolo o un documento, potrebbe essere applicabile quanto segue:

  1. Contatta l'editore.

  2. Pubblica un documento che mostri il tuo lavoro per migliorare l'utilità del codice.

Il terzo dipende dal tipo di errore e da come è stato corretto - se significava cambiare da 3 a 5 allora è banale, ma se significava ricodificare una parte significativa con un processo extra allora potrebbe essere un'opzione adatta.

Devi dirlo in qualche modo però.

Aggiungerò solo che se il codice si trova su un repository online (ad esempio GitHub), allora c'è un modo standard per farlo.
È stato un piccolo cambiamento con enormi conseguenze, non credo che meriterebbe un articolo, né mi piacerebbe trarre profitto dalle disgrazie di qualcuno.
È su un sito web personale
Quindi è chiaro che hai preso la tua decisione: dì solo che è stato così utile per te e hai trovato l'errore ...
(2) non sembra rilevante dalla domanda originale, né dal commento del PO.(3) non sembra appropriato senza ulteriori informazioni: scrivere un articolo su un bug del software sembra piuttosto insolito.Suppongo che (2) sia rilevante se il codice del software fosse pubblicato in un articolo, poiché l'editore potrebbe pubblicare una nota sul bug.Allo stesso modo, suppongo che (3) sia rilevante se il codice del software fosse pubblicato in un articolo.Forse @SolarMike aveva in mente scenari diversi.
@user2768 Avevo pensato (a quanto pare in modo errato) che l'OP avesse ottenuto il codice da un documento pubblicato di qualche tipo.Ora è diventato chiaro che è stato copiato da un sito web personale che cambia il gioco.Oh, se solo tutte le domande fossero scritte perfettamente in modo che le risposte potessero concentrarsi sulla direzione corretta ...
L'assunto di @SolarMike è la madre di tutti i **** up
@user30609 scrivere una domanda chiara è utile qui, vedere https://academia.stackexchange.com/help/how-to-ask
Scusa @SolarMike volevo dire a mio nome, avrei dovuto scrivere la domanda in modo chiaro e non dare per scontato che i potenziali lettori sapessero cosa stavo dicendo
h22
2019-07-18 23:47:48 UTC
view on stackexchange narkive permalink

Se sei tu stesso il programmatore e questo è il progetto open source, sarebbe meglio inviare la richiesta pull se hanno il repository SCM. Entrambi i software verrebbero risolti e si otterrebbero crediti.

In caso contrario, segnala il bug, meglio del loro database di bug, se ne hanno. Scrivere un blog sul problema in un posto casuale non ha molto senso perché potrebbe volerci un'eternità prima che gli autori trovino i tuoi commenti.

Se si tratta di un team obsoleto che non ha un repository e nessun database di bug, potrebbe avere senso rilevare il progetto.

Torben
2019-07-19 02:21:11 UTC
view on stackexchange narkive permalink

Molti repository hanno un file "CONTRIBUTING.md". Il file contiene linee guida per fornire feedback, segnalazioni di bug o come aprire le richieste pull. ( Esempio 1, esempio 2) Altri progetti hanno una pagina web o wiki con una sezione "Come contribuire", dove puoi trovare queste informazioni.

Se non trovi nulla di tutto ciò, dovresti scrivere un'e-mail con la segnalazione di bug e chiedere al proprietario del repository la seguente procedura.

Nyos
2019-07-21 20:01:31 UTC
view on stackexchange narkive permalink

Vorrei solo far notare che le persone pubblicano codice esattamente perché vogliono / si aspettano alcune correzioni / miglioramenti dei bug. Ho inviato alcune correzioni nella mia vita (o ho solo segnalato problemi) e sono state per lo più ben accolte. Anche quando mi sbagliavo (si è scoperto che i compilatori hanno la libertà di interpretare "un comportamento indefinito" nel modo più liberale).

Quindi non aver paura di inviare un rapporto / patch!



ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...