Az alábbiakban bemutatjuk az új feladatok rögzítésének, módosításának mikéntjét függetlenül attól, hogy az éppen milyen típusú feladat.
Mielőtt erre rátérnénk, szeretnénk kiemelni a legfontosabb dolgot: bármilyen feladatot is indítunk útjára, annak leírása legyen egyértelmű, mások számára is értelmezhető.  Létrehozás előtt olvassuk át a leírásunkat, ellenőrizve, hogy minden szükséges információt megadtunk-e benne. Hibajelzés esetén mindig ellenőrizzük, hogy megadtuk-e a hiba számát, illetve a leírásunk pontosan tartalmazza-e a hiba keletkezésének körülményeit. 

A feladatok rögzítésekor annak értelmezéséhez az alábbiakat tartsuk szem előtt:

Egyértelműen jelölni kell:

• melyik környezetben jelentkezett a hiba (flottakezelő cég / teszt / éles / …),

• milyen adaton dolgoztunk épp, legalább egy példát megadva (partner azonosító, keretszerződés szám, egyedi szerződés szám, ajánlat száma, számla azonosítója, stb.)

• mi a (hiba) jelenség, ami nem tetszik a működésben

• F1 hibaüzenetben található azonosító szám (ID … vagy TR …) → ez alapján tudják fejlesztők kikeresni a hibanaplóból az eseményt , illetve P1 hibaüzenetben található 'Részletek' megadása

• mit tettünk épp, amikor a hiba jelentkezett,

• mi lenne az elvárt működés / érték / következmény,

• megismételhető-e a hiba

További segítség lehet a javításhoz, ha a leírásunk alátámasztására (de nem helyette!) képet is csatolunk.

A leírásban szorítkozzunk a konkrét problémára, ne keverjünk bele egyéb kérdést / kérést.

A feladatok átláthatósága érdekében tartsuk szem előtt az alábbiakat:

A leírás mezőt utólag NE módosítsuk.

Amikor egy feladattal dolgozunk, és adott munkamenetet befejezettnek tekintünk saját részről, akkor nem elegendő a Feljegyzésekhez beírni válaszainkat, észrevételeinket, hanem a Státusz mezőt is állítanunk kell! Ez vezérli ugyanis, hogy kinél jelenik meg, mint rá váró feladat (fejlesztőknél vagy ügyfél oldalon, engedélyezőnél vagy tesztelőnél, stb.)

Tipikus hiba, hogy az eredetileg megfogalmazott kéréshez tesztelés közben újabb és újabb kéréseket fűzünk. Ezt NE tegyük! Teszteléskor az vizsgálandó, hogy az eredeti kérésünk megvalósult-e! Újabb kérésre vegyünk fel újabb Redmine-t! – elkerülendő azt, hogy az egyes feladatok átláthatatlan terjedelművé dagadjanak, elkerülendő azt, hogy vitatkozni kelljen az adott feladat státuszán, elszámolásán.

Szintén tipikus hiba, amikor egy már elfogadott, vagy státusza alapján felhasználóra váró feladatba beírjuk szövegesen az újabb és újabb észrevételeinket. 

A feladatok elkészültének jelzése CTC oldalról a státusz "Ügyfél tesztelésre vár" állapotba léptetéssel történik. Ezt követően a felhasználói oldalnak kell a javítást / új fejlesztést ellenőriznie. Az eredményt minden esetben a feladat státuszának léptetésével kell jelezni:

• ha rendben van a javítás -> "Tesztelve, rendben",

• ha hibát találunk a működésben -> "Tesztelve, javítandó" legyen a státusz. Ebben az esetben kommentbe írjuk meg, pontosan mi nem felel meg az elvárt működésnek, és adjuk meg - ha van - a rendszerben végzett teszt adatokat. Természetesen képet is lehet csatolni. 

A "Tesztelve, rendben" és "Lezárt" állapotú hibajegyeket NE léptessük vissza javítandóra. Előfordul, hogy a különböző hibák a felhasználó számára ugyan azt a nem megfelelő működést eredményezik, de valójában egész más baj is állhat a háttérben. Ezért ha egyszer egy hibajavítást már rendben lévőnek találtuk, és később ismét felmerül valamilyen probléma ugyan azon a felületen, azt NE a korábbi redmine feladat visszanyitásával jelezzük. Vegyünk fel egy újat, amiben természetesen lehet jelezni, hogy a jelenség hasonlít egy korábbi hibára.