Prioriteitswachtrijen voor vertaalwerk

Vertaalwachtrijen worden politiek zodra echt lanceringswerk erin terechtkomt. Een grote batch lijkt efficiënt wanneer die start, maar dan heeft iemand nu meteen één urgent artikel, één prijsaanpassing of één release-opmerking vertaald nodig.

Als dat kleine verzoek achter honderden batchitems moet wachten, is het systeem technisch eerlijk en operationeel verkeerd.

Niet al het werk in de wachtrij heeft dezelfde urgentie

Batchwerk is meestal gepland. Het vertegenwoordigt vaak een achterstand, een migratie of een bekende lanceringsscope. Dat werk is belangrijk, maar kan meestal constante voortgang verdragen.

Werk met één item is anders. Het wordt vaak getriggerd omdat iemand naar een specifieke pagina kijkt en een specifieke taak probeert af te ronden.

Dat verschil moet zichtbaar zijn in de wachtrij.

De faalmodus

Wanneer elk vertaalverzoek in dezelfde rij terechtkomt, domineren grote batches de beschikbare capaciteit. Het team ziet voortgang, maar het is de verkeerde voortgang:

• geplande migratie-items blijven doorgaan
• urgente redactionele correcties wachten
• vertalers kunnen niet snel één pagina valideren
• lanceringsteams gaan om het systeem heen werken

Zodra mensen geloven dat de wachtrij onvoorspelbaar is, vertrouwen ze die niet meer voor tijdgevoelig werk.

De betere regel: eerst losse runs

Een praktische vertaalwachtrij moet runs met één item prioriteren boven batchruns. Dat betekent niet dat batches nooit vooruitgaan. Het betekent dat batchwerk de resterende capaciteit gebruikt nadat urgent direct werk de kans heeft gekregen om te starten.

Dit sluit aan bij hoe teams daadwerkelijk werken. Een migratie van een achterstand mag een productiecorrectie niet blokkeren. Een brede campagnebatch mag een enkele pagina die klaar is voor review niet blokkeren.

Wat prioriteit moet beschermen

Wachtrijprioriteit gaat niet alleen over snelheid. Het beschermt vertrouwen.

Wanneer een gebruiker een enkele vertaling start vanaf een contentdetailpagina, verwachten ze dat die actie snel reageert. Als die achter een langlopende batch blijft hangen, voelt de UI kapot, zelfs als de workers precies doen wat hun gevraagd is.

Het systeem moet de relatie behouden tussen gebruikersintentie en zichtbare voortgang.

Hoe je batches gezond houdt

Losse runs prioriteren betekent niet dat batches voor altijd worden uitgehongerd. De wachtrij heeft nog steeds vangrails nodig:

• batchworkers moeten doorgaan wanneer er geen urgente losse runs wachten
• retries moeten de prioriteit behouden van het werk waar ze bij horen
• push- en publish-jobs mogen niet worden verward met vertaalprioriteit
• voortgangsrapportage moet gepauzeerd of wachtend werk duidelijk maken

Het doel is niet om batches te straffen. Het doel is om te voorkomen dat batches een muur worden.

De kern

Wachtrijen zijn onderdeel van de productervaring. Als urgente vertaling met één item achter een gigantische batch moet wachten, ervaren gebruikers geen "achtergrondverwerking". Ze ervaren dat ze worden geblokkeerd.

Losse runs moeten voorrang krijgen omdat ze meestal actieve menselijke intentie vertegenwoordigen. Batches kunnen op de achtergrond blijven bewegen, maar ze mogen niet de voorkant van de rij bezitten.