Stato delle regole di contribuzione
Stato
Aperto. Questa pagina registra quali regole per i contributi in questa raccolta valgano dimostrabilmente e quali non esistano. Verrà sostituita non appena i punti aperti saranno decisi.
Situazione
L'area Progetti conduce chi collabora fino all'invio di una modifica. Da lì in poi intervengono regole che un progetto si dà: quale branch, chi rivede, quando si integra. Una parte di quelle regole è scritta in questa raccolta ed è dimostrabilmente in vigore, un'altra parte no. Senza quella distinzione nasce il tipo di documentazione più costoso: quella che afferma una regola a cui nessuno si è vincolato, e che perciò non viene né seguita né confutata.
Che cosa vale dimostrabilmente
| Ambito | Regola | Da che cosa è dimostrabile |
|---|---|---|
| Stile di codifica | PSR-12, senza eccezioni alle regole | la configurazione di verifica dello spazio di lavoro e le chiamate composer cs e composer cbf |
| Analisi statica | prevista, livello 4 | la configurazione di analisi e la chiamata composer stan |
| Testo del commit | ogni commit nomina il proprio elemento di lavoro in una riga finale a sé | le regole di progetto della raccolta; senza quella riga non nasce alcun legame fra elemento di lavoro e codice |
| Coautoria | nessun modello viene indicato come coautore di un commit | le regole di progetto della raccolta |
| Collaudo per modifica | verifica della sintassi, avvio, testi di interfaccia in cinque lingue, ricostruzione del pacchetto CSS, confronto del registro degli errori | le regole di progetto della raccolta |
| Lingua | commenti nel codice e documenti nel repository in inglese, documentazione wiki in tedesco, interfacce in cinque lingue | le regole di progetto della raccolta |
| Indicazione dell'autore | un'indicazione fissa di autore e indirizzo per il codice proprio | le regole di progetto della raccolta |
| Segnale di rilascio | la data nel manifesto del pacchetto è il segnale da cui un aggiornamento viene riconosciuto | le regole di progetto della raccolta |
| Chi decide sulla collaborazione | i manutentori del progetto interessato, senza diritti di amministrazione del wiki | la schermata Mitglieder per progetto; la verifica sta in Domain/ProjectMembership ed è retta da test propri |
| Limite di questa competenza | un manutentore assegna lettore e collaboratore, non manutentore | la stessa verifica; rifiuta anche un invio costruito a mano |
| Chiamata dei test | ogni pacchetto con directory di test ha una configurazione di test propria e viene chiamato dalla propria radice | dodici file di configurazione, tutti con gli stessi interruttori di rigore |
| Analisi statica in pratica | tutti i 27 pacchetti della suite, livello 4, raccolta congelata | la configurazione di analisi; un passaggio finisce senza rilievi solo se non è stato aggiunto nulla di nuovo |
| Nome del branch alla restituzione | al livello proporre l'endpoint Git accetta solo ref sotto refs/heads/users/<nome utente>/ e rifiuta tutto il resto prima che raggiunga il sistema sorgente; al livello scrivere la barriera non vale | la verifica sta in Domain/ReceivePackGuard ed è retta da test propri. Nessuno dei quattro modelli di mount assegna proporre; il livello nasce solo da una regola scritta apposta |
Che cosa non esiste
| Ambito | Constatazione |
|---|---|
| Modello di branching | Nessuna regola. Non è stabilito su quale branch una modifica debba stare, come debba chiamarsi o quando sparisca di nuovo. La barriera tecnica del livello proporre nella prima tabella non è una regola di quel tipo: delimita ciò che l'endpoint accetta e non dice nulla su dove una modifica appartenga nel merito. |
| Procedura di revisione | Nessuna regola. Né la competenza né il criterio di superamento sono stabiliti. |
| Regole di merge | Nessuna regola. |
| Versionamento | Nessuno schema. La data del manifesto porta il segnale di rilascio; una sequenza di versioni non è con ciò affermata. |
| Registro delle modifiche | Nessuna convenzione. Fra i pacchetti propri, uno tiene un registro delle modifiche. |
| Via di segnalazione per falle di sicurezza | Nessuna per i pacchetti propri. |
| Nomina dei manutentori | Nessuna regola. Chi diventi manutentore di un progetto lo decide l'amministrazione del wiki; secondo quale metro, non è stabilito. |
Conseguenze
Chi scrive documentazione per quest'area non può formulare alcuna regola per la seconda tabella. Una regola inventata è qui più costosa di una mancante: sembra una determinazione, viene citata come tale e non vincola nessuno.
La guida Inviare una modifica descrive perciò solo ciò che la piattaforma effettivamente offre, e nomina i punti aperti invece di riempirli.
Chi decide uno dei punti aperti lo iscrive nella prima tabella, nomina la prova e adegua la guida interessata.