User Guide

The order is itself a rule

You cannot open registration without a fee table, the public form does nothing until registration is open, and the programme has nothing to place until papers are accepted. The panel shows the first three steps as a checklist under the conference title. That list is built from your data, not from a "setup done" flag, and it disappears for good when the first registration arrives.

Steps marked optional are processes some conferences run and others do not. Left switched off, they appear nowhere — not on your screens, and not on the pages authors and reviewers see.

First say what people are paying for, then open registration. The order is not optional: with no fee table the public form has nothing to show.

If you do not use tracks

With the list empty, authors are never asked the question — the right answer for a conference with a single programme.

The switch is what opens and closes the form; the dates below it only tell authors what to expect. Every conference extends its deadline at least once, and an organiser who edits a date to let one late paper in forgets to edit it back.

What you set here, and what each one does later

Topics

One per line. They become the author's dropdown and the thing reviewer suggestions match on. Leave it empty and authors are not asked.

Instructions

Shown above the form.

Abstract limit

The author's box counts down to it.

Full text

Not collected, optional, or required.

Blinding

Open, single blind or double blind. Decided here because it changes what reviewers are sent from the first assignment onwards.

Camera-ready deadline

Separate from the submission deadline on purpose: it falls after reviewing ends, and one field for both would put an already-past date in your acceptance letters.

Author response window

Both dates or neither — see §09.

Bidding window

Both dates or neither — see §06.

Reviewer quota

The most papers one reviewer should hold at once. Between 1 and 200, or empty for no quota.

Files

If the call collects files, every upload is a new version and the previous one is kept: it is the only record of what the decision was made on. The size limit is set per call, up to 50 MB.

Supplementary files sit in their own list, apart from the manuscript: a dataset, a long table, a video. Up to ten per paper. The accepted formats are wider than for the manuscript (pdf, doc, docx, txt, csv, zip, png, jpeg, mp4) and nothing executable is among them. Zip is there because a dataset is usually a folder; the product does not know what is inside, and never opens or runs it.

Supplementary files can be added after a decision too: the dataset for an accepted paper is usually prepared after acceptance, and closing that door would push it into an email attachment.

Conflicts of interest: three rules that add up

The address

A reviewer whose email is the contact address or one of the authors' addresses is out.

The affiliation

A reviewer whose affiliation matches an author's is out.

The declaration

During bidding, a reviewer can declare a conflict on any paper, and that takes them off it too.

The first two catch what the data knows. They do not catch a former supervisor, a co-author from three years ago or a joint grant — nothing in the product knows those, and only the person themselves does. That is what the declaration is for. The reason is never asked: asking would push somebody into writing "I was their supervisor" and turn a declaration into a justification contest.

All three are enforced on the assignment itself, not only in the suggestion list. Filtering alone would leave the rule to the screen's good manners, and an assignment can also be made from a link.

Open the bidding window after submissions close. Reviewers see every paper's title and abstract and give each one of five answers.

Want it · Willing · Would rather not · Not for me

Four degrees, not three. In a pool where everybody says "willing" you cannot see who actually wants the paper — and that is the single most useful thing the committee gets out of bidding.

Conflict of interest

Not a degree but a door: it removes the paper from that reviewer's list and the reviewer from your candidate list.

At the bidding stage the abstract is visible and the full text is not. Asking for a bid on a title alone would force a decision on what the title suggests; the full text opens only after an assignment is accepted.

Reminders wait three days

A reminder can be sent to a reviewer who has not answered or not delivered, but only once every three days. The button says how long is left rather than failing when you press it. The reminder button sits on a screen that gets opened several times a day, and without the wait the same reviewer gets three letters in one morning — and that reviewer is the one you lose.

The quota: a door with a second key

If you set a quota on the call and this assignment would go over it, the screen asks first and the second click goes through. A silent warning gets clicked past on a screen doing repeated assignments, which means the quota was never real; a hard wall abandons the committee at eleven o'clock the night before the deadline. The second click is the record that you meant it.

What the quota counts is open and completed work. Declined and cancelled assignments are not counted: treating work that is not on somebody's desk as load would make the reviewer who refuses most the most protected one.

Each paper's row shows how many of the assigned reviews are back, and the counters at the top of the list say what the conference as a whole is waiting on. Reviewers can revise what they sent until you decide; the review you read is always the current one.

What the reviewer sees, and when

Before they answer

Title, topic, keywords and the abstract. Enough to know whether the paper is theirs to judge, which is what they are being asked.

After they accept

The full text and any supplementary files the authors attached. The camera-ready version is not among them: that is a production file, not part of what is being judged.

After they decline

The paper closes, abstract included. Being able to keep reading a paper you turned down would make declining meaningless.

Blinding happens on the server

Under double blind the author fields are not in the response at all — not in the reviewer's list, not on the paper, not in the bidding screen. A name hidden by the interface is still there for anybody who opens the network tab, and a leaked identity cannot be taken back. The fields are absent rather than blanked: even an empty list of the right length leaks the number of authors, and telling a three-author paper from a one-author paper is enough to identify it in a small field.

Blinding protects the author, not the committee. Area chairs and the committee see reviewer names, because the person chasing a late reviewer and spotting two contradictory reviews cannot do the job otherwise. The author's identity is blinded to the area chair as well.

The discussion between reviewers

Each paper has a closed thread for its reviewers, its area chair and the committee. The author never sees it, in any conference, at any stage — a place the author can read is a place reviewers stop writing in.

• A reviewer gets in only after submitting their own review, and the other reviews open at the same moment. Reading first would anchor somebody to another person's opinion before forming their own, which turns three independent reviews into three copies of one. Until then they see a sentence saying what to do, not a locked door.
• Reviewers appear to each other as "Reviewer 1", "Reviewer 2" — the same numbers used in the decision letter, so two screens side by side never disagree. The committee and the area chair see real names.
• A message from the committee reaches reviewers as "the committee", because a named committee member becomes an authority arguing rather than a point being made.
• Confidential comments to the committee are visible in the thread: very often that box is exactly what there is to discuss.
• Messages cannot be edited or deleted. The reasoning behind a decision is sometimes built in that thread, and a discussion that can be erased is a decision that can lose its basis.

Give the window an opening and a closing date and three things happen: the reviewers' comments to the author appear on the author's own page before any decision, the author gets one reply, and the reviewers who already wrote are told the reply is there.

• One window for the whole conference, not one per paper. Giving one author three days and another one day would make the decision partly a function of the clock.
• One text, not a conversation. A thread would be one identity leak per message under blinding, and a queue nobody has time to read.
• It can be rewritten until the window closes, and not afterwards: leaving it open would change the text under the reviewer who already read it.
• The comments are only visible while the window is open or after a decision. Showing a review the moment it arrives would have the author reacting before the committee has read it.
• Reviewers are told once, on the first submission, and only those who have actually written a review. Sending on every edit would remind the same person of the same job three times; sending to somebody who declined would put in front of them the reply to a text they never read.

Three places read the author-facing comment text — the decision letter, the author's page and this step — and all three run the same code. Three copies of the rule would mean a leaked identity on the day one of them was forgotten.

An area chair is CMT's meta-reviewer: one person per paper who runs the reviewing on it and writes the committee a summary and a recommendation. You assign one from the paper's own screen.

• Not a separate pool, a second mark on a person already in the reviewer pool. In real conferences the same people do both, and a second list would mean a second link and a second letter for the same person.
• The mark makes them eligible; the assignment gives them access. Somebody marked as an area chair cannot open a paper they were not assigned to.
• One per paper. Two people jointly responsible for a job is, in practice, nobody responsible for it, and the committee would not know whose summary to wait for.
• They can assign reviewers to their own paper, which is the point of the role. The same conflict, withdrawal and duplicate rules run there, and the invitation is the same letter.
• The summary never goes to the author, and cannot be written after the decision. A summary written afterwards would change, in hindsight, what the committee decided from.
• If the area chair is changed, a summary already written stays: it is the record of what the committee decided from.

The decision panel is on the paper itself, under the reviews, the author's response and the area chair's summary — because that is the order you read them in. Four decisions: accept, minor revisions, major revisions, reject.

What is in the letter, and what is not

• Reviewer names are not in the letter — the single exception is open review, where naming them is the rule the conference announced.
• Confidential comments and scores never reach it. That field is not read by the letter at all, which is the only way to rule out "somebody adds it by accident".
• The subject line carries the reference code and no verdict. "Rejected — S-4K2M" is read from a lock screen, in a meeting, over somebody's shoulder. The author should choose the moment.
• The acceptance letter also asks the author to register. The two things a conference finds out too late are a missing camera-ready file and a presenter who never registered.

An accepted paper lands in the programme by itself

There is no "send to programme" button to forget; forgetting it would mean a missing paper in the programme, and that is noticed in the week of the conference. Reversing an acceptance pulls the row back out — unless it has already been placed in a session, in which case it stays and you are told: silently removing a scheduled paper would falsify the list a session chair is holding. In that case you take it out of the programme by hand.

On Programme you define days, rooms and time slots, then place sessions in the grid.

Papers reach the grid through two doors

1. From your own reviewing. The row is created the moment the committee says accept (§11).
2. From outside. A spreadsheet import or adding rows by hand. A conference that ran its reviewing in CMT or EasyChair uses this door.

A programme row can be edited, and its link to the reviewing is visible in the list: shortening a title for the programme is ordinary work, while hiding the link would let somebody delete a decision-made row believing it had been typed in by hand.

What the scores are for

They go to the organisers, not to the speaker. On your side the forms add up into a ranking of the papers presented, with the chairs' comments underneath.

That ranking is a reading of the scores, not a verdict. If the conference gives a best paper award, a person decides it and you issue the certificate: two papers can average the same score, and an award is the most visible document a conference hands out.

Presentation and session chair certificates are produced from the published programme, and attendance certificates from the check-in records — not from the registration list, because registering is not the same as turning up. They are sent in a queue you start yourself.

A separate document from the programme: the grid says when and where, the book carries every paper's abstract. The book is what a delegate holds all week.

• It follows the programme's order, not the reference codes. A delegate opens it in the room while following a session, and a book ordered by session sits on one page at that moment.
• Accepted papers not yet in the grid are listed at the end rather than left out. Leaving them out would mean an author who got an acceptance letter is not in the book — and that is noticed after it is printed.
• A paper with no abstract is not skipped — the reason is printed in its place. A paper imported from a spreadsheet has no abstract in Redaktum; skipping it silently would leave a paper that is in the programme out of the book, and an empty heading would read like a typesetting error.
• Authors and affiliations come from the programme row, the abstract from the submission: the programme row may have been corrected by you, and what the book shows has to match what the programme shows.

Uploaded files do not stay for ever. The periods are defined in one place in the product and the privacy notice reads them from there — if a period changes, both change, and neither starts quietly lying.

The warning letter

A letter goes out 30 days before the deletion. It goes to the organisation's administrators, not the event's own team: after five years you cannot assume anybody from that team is still there, while the organisation is. It is sent once, says how many files will go and on what date — and it also says what stays, because "will be deleted" on its own would suggest the organisation's whole conference record is going.

Opening a file that has been deleted

The answer is not a 404 but dosya_saklama_suresi_doldu, carrying the deletion date with it. A 404 says "there is no such file" and whoever reads it takes it for a fault; the file existed and was deleted by a rule. The committee's screen, the reviewer's desk, the area chair's screen and the author's own page all give the same answer.

The submissions list is where the committee spends its time, so it carries more than a list: filters, counters, export and bulk email.

Filters

State, decision, review progress, and a free-text search over reference codes, titles, contact addresses and author names. "Not decided yet" is its own choice, because an undecided paper can be either submitted or under review, so the state filter cannot ask that question.

There are no saved filters. The filter is in the address bar instead: the link is shareable, the back button works, and there is no second list of named views to maintain and go stale.

The counters above the list

Papers with no reviewer, papers waiting on reviews, papers ready to decide, decisions whose letter never went out, and accepted papers whose author never registered. Each one is a button that sets the matching filter.

Export

Two CSV files: the submissions with their reviews, and the reviewer pool with its workload. The submissions file has one row per review, not one column per reviewer, so a paper with four reviewers does not break the shape of the table. Papers with no reviewer are in it too — those are the rows somebody opening the file is usually looking for.

Writing to people

One letter to a group: authors (optionally narrowed by decision), the reviewer pool, reviewers with work outstanding, or area chairs. The "outstanding" group excludes anyone who has finished — writing to the whole role would tell somebody who delivered that you are still waiting on them.

• You must preview before the send button appears, and the preview shows the recipient count and the first letter exactly as it will arrive. Change the subject, the body or the group and the button closes again.
• One letter per address. An author with two papers does not get the same announcement twice.
• Up to 500 addresses in one send. Past that, narrow the group and send twice — the second pass is a second chance to notice a mistake.
• Addresses that failed are listed back to you. "Sent" on its own would let you believe everyone knows.
• An unrecognised placeholder is left as it is, not stripped: a field that silently becomes empty is a word lost in the middle of a sentence, and you would notice only after the letter had gone.

Redaktum does not replace your editorial system. It connects to the OJS you already run and takes over the work that happens around it — deciding who to ask, chasing people, and the records nobody keeps.

Two things follow. First, peer review itself stays in OJS: reviewers do their work there, review forms are OJS's, and the decision you record here is written back into OJS. Second, nothing here reads the content of an article. There is no compliance check, no language editing, no plagiarism screening and no author correction letter generated from the text — that line of work was taken out of the product in September 2026 and nothing replaced it.

Conferences are the other way round: there, papers are submitted to Redaktum and reviewed in it. If you run both, the two lines do not mix.

Connecting your OJS

Journals → your journal → Setup. Three steps, shown one at a time: install the Redaktum plugin in OJS, then copy the address and the key that the plugin creates. The order matters and is the reason the boxes appear one after another: the address and key do not exist until the plugin is installed, so a screen showing all three at once has two fields nobody can fill in yet.

Installing an OJS plugin needs server access, and in most journals that belongs to somebody else. The setup screen has a button for that: it emails the steps and the download links to whoever runs your server, and they send the address and key back to you. Without it, this step leaves the product and turns into an email thread that often never comes back.

Once connected, the panel shows which OJS journal it reached, its version, and what that install is capable of. Two actions depend on it: assigning a reviewer needs an OJS that supports it and an acting editor chosen in the plugin's settings, and recording a decision needs the install to report which decisions it accepts. Where either is missing, the button is absent rather than failing when pressed.

The submission queue

One list across every journal you can see, not one tab per journal. The question an editor actually has on a Monday is "which submission needs me today", and the journal is a grouping in that question, not a wall.

Each row carries what OJS knows plus what Redaktum counted: stage and status, the section, the authors; how many reviewers are assigned, how many accepted, how many returned, how many are overdue; and a flag when something needs attention — overdue reviews, or no reviewer at all.

The list is a mirror, refreshed from your OJS, and it says how old it is. A mirror that cannot say when it was last filled would quietly show you yesterday's queue as today's. You can refresh a journal by hand from its own page.

Recording a decision writes it back to OJS. The panel works with decision names, never OJS's internal numbers: those numbers moved between OJS versions, and a panel holding them would silently record the wrong decision after an upgrade.

Finding and inviting reviewers

Open a submission and ask for suggestions. Candidates are ranked by interest match, median turnaround, experience, current load, refusal rate and how recently they were asked.

• No artificial intelligence, and none is needed. The job is counting, not reading.
• Open work is counted across all your journals and conferences. OJS counts each journal separately and never sees the conference; that is exactly why the same person gets three invitations in one week. Somebody halfway through three papers for your conference does not show up here as free.
• The score itself is not shown — its reasons are. If you disagree with the order you should be able to see what produced it.
• Somebody reviewing their own article never appears. A shared surname or a shared affiliation keeps them on the list but flagged and last: both are often false alarms, and the judgement is the editor's.

The invitation desk: instead of inviting one person and waiting ten days, set the order once. Redaktum invites them in waves and moves down the list on its own as refusals and silences come in, stopping when the number of acceptances you asked for is reached.

• The remaining candidates are never disturbed once the queue is filled.
• A late reply does not cancel an invitation. When the waiting time runs out the next person is invited as well; dropping the slow reviewer would mean throwing away a yes you already have.
• A bridge failure does not burn a candidate. Only OJS's own refusal is treated as final; an unreachable server is retried.
• If the candidates run out, the queue closes and says so. Stopping quietly would leave a gap the editor cannot see.
• The order lives in Redaktum, not in OJS — OJS has no idea of "try these in this order". Deleting it changes nothing about the assignments already made there.

Chasing late reviews

Reviewers → Overdue. One list across all journals, sorted into the two cases that need different letters: a reviewer who has not answered the invitation, and one who accepted and has not delivered.

The reminder is sent by Redaktum, not by your mail client, and the row shows when the last one went out — in a journal with two editors, that line is the only thing stopping both of them writing on the same day. The same reviewer cannot be reminded twice within three days.

The address and the letter come from the server, never from the browser. An endpoint that accepted a recipient from the client would be a relay for sending mail from Redaktum's address to anyone.

The reviewer ledger, certificates and payments

Reviewers is the view no OJS can give you: total load per person across every journal and every conference your institution runs, the history of who reviewed what and how long it took, and an export for the year-end report to your board.

• Journals and conferences sit in the same row. Somebody who worked on four conferences and two journals shows as six. Each OJS install knows only itself; conference tools never look at the journals — and so the same person stays five separate records.
• Where the load sits is visible too: which journal, which conference. The total tells you who to invite next; the breakdown tells you who to talk to.
• If a journal cannot be reached, the screen says so. Quietly showing a smaller number is the most expensive way to say "this person is free".
• Median turnaround counts journals only. The conference side does not measure it, and a half-measured average would mislead more than no average at all.

There is also a payments ledger. It records what was paid, with the receipt attached — it does not work out what is owed. The rate rule differs from journal to journal, and writing one into the product would be Redaktum deciding how much a reviewer is paid.

A reviewer can be given a private link — no account — showing how many reviews they have completed, their median turnaround, their thank-you certificate, and the payments recorded for them.

• Article titles are not on it. If the link is forwarded, what it reveals should be a number, not the name of an unpublished paper.
• The page counts everything too — your journals and your conferences, on marked separate rows. A page counting the journals while the certificate right below it counted everything would leave the reviewer unsure about their own record, with nobody to ask.
• Median turnaround comes from journals only. The conference side does not measure it, and a half-measured median would mislead more than showing none.
• The thank-you certificate carries a number and a verification address, like every other certificate the product issues.
• The certificate counts everything — journals and conferences together, each named with its own number. It is issued to someone who has only ever worked on one of your conferences too; for the reviewer that distinction never existed, it is work done for the same institution.
• Only an organisation administrator can create that link, because the page shows ledger payments and the ledger is theirs.
• Replacing a link kills the old one immediately, and the "has it been opened" mark resets — an old open says nothing about whether the new link arrived.

Telling the author where it stands

"What is happening with my article?" is the email every editor answers by hand. The answer is a private link you can paste into your own OJS correspondence: title, submission date, stage, "2 of 3 reviews are back", and when that information was last refreshed.

• You share it, not us. The bridge does not hand over the author's email address, so the link goes into the letter you were writing anyway.
• No reviewer identities, ever, and no review text: passing a review on to the author is an editorial decision, not an automatic one.
• Copying the link does not create a new one. Replacing it is a separate, deliberate act and the old link dies at that moment.
• A link that has never been opened means the author never received it.

Author payments

• The tariff — base fee plus extra items — is set per journal.
• Where the money goes is set once for the whole organisation: your own Stripe account, or bank transfer instructions shown on the public payment page.
• Money does not pass through Redaktum. The author pays the journal; Redaktum carries the reconciliation and closes the record in OJS when you confirm that the money arrived.
• "I have paid" is a claim, not a payment. It never closes a record on its own — the only place a payment is real is your own bank statement.
• If closing the record in OJS fails after you confirm, that row is flagged rather than hidden: the author paid, the journal confirmed, and OJS still shows a debt until somebody fixes it.

Authors, reviewers and session chairs never open the panel and have no accounts. Each gets a private link by email, and everything they need is on the page that link opens. The three guides below explain those pages, so you can put the address in your call for papers and your invitation letters instead of writing the instructions yourself.

guide-authors.html

For authors. Submitting, their own page and link, the correction window, responding to the reviews, the decision, camera-ready and supplementary files, registering.

guide-reviewers.html

For reviewers. The invitation, accepting or declining, what they see and when, the form and the two comment boxes, the discussion, bidding, area chairing.

guide-chairs.html

For session chairs. The link, the session list, the scoring form, what the scores are for.

Links you hand out

/e/adresiniz

The registration form. Goes in the announcement.

/e/adresiniz/submit

The call for papers form. Goes in the call.

/e/adresiniz/program

The published programme. Nothing is there until you publish it.

Coming from CMT

Most of what you do in CMT is here under a different name. These are the places where the answer is deliberately "no", so you are not looking for them at the wrong moment.

No "decide all selected"

Decisions are made paper by paper. One wrong filter and thirty people get the wrong letter, and the letter is the part that cannot be taken back. The slowness is the feature.

Bids do not become assignments

No button turns the bidding results into a distribution. A distribution nobody can explain would be standing in front of a scientific decision.

No per-track deadlines

One call has one window. Per-track dates would multiply every date field by the number of tracks and make "which deadline applies to me" a question asked on every screen.

No track chairs

The area chair covers it. A track chair would be a second copy of the same role with a different name.

No automatic scoring or recommendation

Redaktum never proposes accept or reject. That sentence is also in the legal terms, where it is a commitment.

Most of these are not mistakes but states: the page was drawn before something under it changed. Refreshing usually settles them.

For a message not listed here: replying to any email Redaktum sends you reaches a person.