Qual è la grammatica più efficace da utilizzare per i titoli di edizione? [chiuso]

7

Quando scegli un titolo per un nuovo numero, ci sono diverse opzioni grammaticali tra cui scegliere. Ecco quattro diverse opzioni per un problema di esempio appena creato:

  • Descrittivo : "Le nuove righe non vengono eliminate quando vengono analizzate le intestazioni di più righe"
  • Imperativo - negativo : "Evita di lasciare righe nuove durante l'analisi di intestazioni su più righe"
  • Imperativo - primo contesto : "Correzione dell'errore di intestazioni su più righe: striscia di nuove righe"
  • Imperativo: prima l'azione desiderata : "Elimina righe nuove durante l'analisi di intestazioni multi-linea"

Sul mio posto di lavoro i titoli dei problemi si alternano tra tutti questi formati, ma continuo a pensare che sia meglio scegliere una convenzione e attenerci ad essa.

Quale opzione (da quella precedente o un'altra) è quella preferita, ovvero quella che ridurrà al minimo lo sforzo degli sviluppatori di leggere questi problemi?

Modifica: come indicato nei commenti, diversi tipi di problemi possono giustificare una scelta diversa della grammatica, in cui una distinzione particolarmente importante è tra bug e nuove opere. Per rendere la domanda più specifica, supponiamo di scegliere, poiché msell offre in la sua risposta , l'opzione descrittiva. Ora diamo un'occhiata a un suggerimento per migliorare una funzione esistente:

  • "Aggiungi informazioni sulla città alla geolocalizzazione"

Se ci atteniamo alla grammatica descrittiva, dovremmo sostituire quel titolo con

  • "Informazioni sulla città mancanti dalla geolocalizzazione"

Tuttavia, questo sembra meno chiaro, poiché la mancanza di informazioni sulla città non è un bug, è il comportamento previsto. Il giornalista sta semplicemente suggerendo di migliorare quel comportamento. Quindi sembra che l'opzione imperativa sia la via da seguire per quel problema.

Diamo un'occhiata ora a una funzionalità completamente nuova. Considera queste opzioni:

  • "Nessuna possibilità di esportare report in XML"
  • "Aggiungi la possibilità di esportare un rapporto in XML"
  • "Esporta report in XML"

Descrivere il comportamento attuale sembra ancora più ridicolo qui, ma l'opzione imperativa non sembra così buona. La terza opzione descrive semplicemente la nuova funzione stessa, che potrebbe essere la via da seguire, supponendo che il problema abbia metadati che indicano che si tratta di un problema di "nuova funzionalità".

  • Quindi cosa è più importante: attenersi a una convenzione o abbinare la grammatica al problema?
  • Dove tracciare la linea tra un titolo descrittivo e un titolo imperativo?
  • Quando descriveresti il comportamento corrente e il comportamento desiderato?
posta Joe 26.01.2014 - 18:04
fonte

2 risposte

3

Nel titolo preferisco descrivere il bug, non la correzione. Inoltre, al contrario della risposta del pdr, mi concentro sul bug reale, non su quello che stavo cercando di ottenere. Vi è abbondanza di spazio disponibile nella descrizione dettagliata per il comportamento previsto, le informazioni di base e anche le proposte su come correggere il bug.

Per aiutarmi a scrivere buoni titoli per i bug, cerco di trovare una descrizione che suoni bene nelle note di rilascio. Considera gli esempi forniti:

Fixed bug #1001: Newlines are not stripped when multi-line headers are parsed

Questo suona bene.

Fixed bug #1001: Avoid leaving newlines when parsing multi-line headers

Non è chiaro se il bug riguardi la possibilità di lasciare le newline o di evitarle.

Fixed bug #1001: Fix parsing of multi-line headers: strip newlines

Mentre il bug in questo formato è chiaro, sembra maldestro con la ripetizione della parola "correzione" e l'uso di due punti aggiuntivi.

Fixed bug #1001: Strip newlines when parsing multi-line headers

Questo ha lo stesso problema del secondo esempio. Non è chiaro se la riga descritta è il comportamento corretto o errato.

Quindi preferisco il primo esempio "Descrittivo". Un vantaggio di questo approccio è che è necessario uno sforzo minore quando si creano le note di rilascio, poiché le informazioni sono già (principalmente) nel formato corretto. Tuttavia, anche se le note di rilascio non sono necessarie, questa linea guida funziona ancora bene e produce titoli di bug facili da leggere e comprendere.

    
risposta data 27.01.2014 - 08:03
fonte
8

Sempre perché, piuttosto che cosa. Dal punto di vista dell'utente, qual è il vero problema che stai cercando di risolvere? Ad esempio,

Search doesn't work if looking for a string that spans two lines.

È impossibile sapere da qualsiasi dei tuoi esempi. Il problema è che non puoi dare la priorità alle attività, a meno che tu non abbia qualcuno a portata di mano che sa perché tali cambiamenti devono avvenire.

Se, quando si crea un problema, si ha un'idea della soluzione, scrivilo invece nel commento. Non è uno sforzo per uno sviluppatore leggere l'intero problema ma, quando si assegna la priorità, è necessario esaminare tale questione nel contesto di altri problemi. Quindi è importante avere informazioni utili a tal fine.

    
risposta data 26.01.2014 - 20:08
fonte

Leggi altre domande sui tag