Editorial planning
Date e priorità: come separarle nel piano editoriale
Una data è un vincolo di calendario, una priorità è un criterio di ordine. Ecco come tenerle separate quando il piano editoriale cambia, senza riscrivere il calendario.
Treat the date as a calendar constraint and priority as a ranking criterion. When a deadline moves, you update the date. When relative importance changes, you update only the priority and leave the date alone. If the two conflict, the date wins as a constraint and the priority stays on record without being rewritten. That is the rule we use at RankAI so an SEO editorial plan with approval does not collapse into a single field. Here we apply it to one concrete case; the topic of default approval is covered elsewhere and is not the focus of this piece.
An illustrative example: two articles, one date
Take a plan with two pieces: A is dated 12 March with high priority; B is dated 20 March with medium priority. On 5 March we find out that B is more urgent than A. The temptation is to move B to 12 March and A to 20 March. But A's date was tied to a calendar constraint (a review already scheduled), not to its importance. So: B keeps 20 March but moves up to high priority; A keeps 12 March and drops to medium priority. Priority tells us the order we work in; the date tells us by when. They are two axes, not one.
The RankAI procedure in four steps
This is an operational proposal from RankAI, not a universal standard. We use it to make the conflict explicit instead of hiding it in a single field.
- Write a date only when there is a calendar constraint. If there is no constraint, the date is provisional and should be marked as such.
- Assign priority on a separate scale. Do not use the date as a stand-in for priority: “sooner” does not mean “more important”.
- When importance changes, touch only the priority. The date stays, unless the calendar constraint itself has changed.
- When date and priority conflict, record the conflict. The date wins as a constraint; the priority stays visible alongside it, without rewriting the date.
Where approval fits alongside date and priority
Human approval of a version is where the conflict gets decided, not where it gets created. In RankAI the default is human approval of a version: whoever approves sees date and priority as two separate fields and can confirm or correct the priority alone without touching the date. Automatic publishing is turned on per site and still goes through the checks; it is not the default. That way approval does not become a back door for rewriting the calendar.
RankAI's contribution: the four-combination table. To make the separation operational, we suggest reading each article along two axes and handling the four combinations differently. Near date + high priority: work on it now, the normal case. Near date + low priority: work on it only if there is time left, because the constraint is the calendar but the importance is lower. Distant date + high priority: start preparing earlier without moving the date, because importance is not a calendar constraint. Distant date + low priority: leave it in the queue. This table is an illustrative example, not a universal rule: it shows that the date should never be rewritten just because the priority changed. The conflict is resolved by keeping the date as a constraint and the priority as information recorded alongside it.
A limit you can check
On the technical trial the limits are 3 articles per month and 3 in total. With numbers that small, the separation between date and priority can be checked article by article, but it does not show how a large editorial plan behaves. For the full context on planning and approval, see the in-depth page.