Joomla! Documentation™

Om te begrijpen hoe problemen en bugs bijgehouden worden via prioriteiten, is hier een veel voorkomend scenario.

U heeft uren geprobeerd het op te lossen, niemand op de forums was in staat u te helpen, het probleem wordt niet behandeld in de documentatie en u heeft waarschijnlijk ook een deadline. Het is tijd om het op de tracker te plaatsen. Na al die inspanning lijkt het zeker een cruciaal probleem. U kiest dus het prioriteit-niveau hoog.

Wat gebeurt er dan? Iemand uit de "Joomla! Bug Squad" JBS verandert het in de prioriteit gemiddeld. Waarom hebben ze dat nu weer gedaan? Betekent dat dat uw probleem niet belangrijk is en niet behandeld wordt? Zijn ze gemeen en onverschillig? Natuurlijk niet. De ontwikkel-werkgroep heeft tamelijk strikte definities van prioriteitsniveaus.

Prioriteit definities

Problemen (bugs) krijgen prioriteit op basis van de volgende kenmerken:

Prioriteit 1 → Kritiek

Het systeem werkt helemaal niet meer. Belangrijke delen van de broncode zijn verbroken, waardoor geen belangrijke activiteiten kunnen worden uitgevoerd. Voorbeelden zouden zijn Inloggen, installatie, extensies installeren, javascript fouten die verhinderen dat u opslaat of iets dergelijks, enz. Dit omvat ook het generen van fatale PHP fouten.

Priority 2 → Urgent

Delen van de broncode verhinderen serieus de werking waardoor een belangrijk deel van de functies uitvalt.

Priority 3 → Gemiddeld

Problemen verhinderen vermeld gedrag maar de toepassing werkt nog. Voorbeelden zijn parameters die niet volgens verwachting werken, taalbestanden die niet als verwacht laden, enz.

Priority 4 → Laag

Klein verlies aan functionaliteit en in het algemeen vervelend gedrag. Kan een minder algemene platformen of browser specifieke problemen bevatten, die hoewel ze technisch aanzienlijk kunnen zijn, op deze omgeving, een minderheid vertegenwoordigen. Het omvat ook het ontbreken van vertaalstrings.

Priority 5 → Zeer laag

Cosmetische problemen, verkeerd gespelde woorden, grafische fout uitgelijnde objecten, minder belangrijke problemen met parameters, enz.

Wat betekent dit?

Allereerst,als het niet binnen een paar dagen voor een release is en als het geen veiligheidsprobleem is, tenzij u subversion of een nightly build gebruikt, ziet u waarschijnlijk nooit een prioriteit 1 (hoog) probleem of hoeft u er een te melden. Dat komt omdat, als er open prioriteit 1 problemen in de basiscode zitten, er geen release zal zijn. Hetzelfde geld voor prioriteit 2 (belangrijk). Een echt prioriteit 1 probleem in een release is iets dat tot een nieuwe release zou leiden. Een prioriteit 1 of prioriteit 2 probleem in een branch van de basecode zou een geplande release tegen houden. Dit is ernstig, want ieder release bevat veel bug-fixes en verbeteringen, dus door geen release uit te geven krijgt de community deze niet. Het forceren van een niet geplande release is ook serieus, want het betekent dat het werk aan andere dingen stopt terwijl alle inspanning wordt gestopt in het release uitbrengen.

De enige uitzondering zou zijn als u een belangrijk veiligheidsprobleem ontdekt, maar de tracker is niet de plek om de meeste veiligheidsproblemen te melden.

Dit betekent niet dat er nooit prioriteit 1 of 2 problemen zijn. Een prioriteit 1 probleem voorbeeld is Read More link does not appear on Category Blog Layout.

Dus bedenk, voordat u besluit een probleem als prioriteit 1 of 2 te geven, de consequenties die dit heeft.

De meeste problemen zijn prioriteit 3, gemiddeld. Sommige problemen zijn echter prioriteit 4 of 5. Als u uw probleem de prioriteit 4 of 5 geeft, betekent dit dan dat uw probleem niet opgelost wordt? In het geheel niet. Als het makkelijk op te lossen is, vooral als u een patch of voorgestelde code meeleverd, wordt het misschien direct opgepakt. Sommige mensen in de JBS zijn gespecialiseerd in taalproblemen of CSS of andere onderwerpen die vaak een prioriteit 4 of 5 probleem zijn. Voel dus niet dat iets een prioriteit 3 moet hebben om aandacht te krijgen.