Managing P3 Qualifiers

From DPWiki
Jump to navigation Jump to search

This page explains how P3 Qualifier projects are managed. It is intended as a reference for volunteers who want to run P3 Qualifier projects in languages other than English, and as general information for anybody who's curious about what goes on with qualifiers.

Identifying Qualifier Projects

The first step is to choose appropriate projects to be used as qualifiers. Qualifiers are usually chosen from the projects in the P2 queue. Projects in the P3 queue can also be used, by sending them back for a second pass through P2.

Because perfect pages are not counted in evaluating P3 candidates, a qualifier project should ideally have plenty of imperfectly proofed pages. However, pages should not have too many errors. If a P1 proofer has clicked through pages without proofing them, they should be tidied up before the project is used as a qualifier.

As a rule of thumb, do a few quick searches through the text for easily spotted errors. The things I look for are:

  • Spacey punctuation.
  • Unclothed dashes at beginning or end of line.
  • 3-hyphen dashes.
  • letters and numbers adjacent to one another.
  • æ ligatures proofed as ae (in projects that use æ)

Of course you have to weed out the false positives, e.g. ditto marks in tables (which look like spacey quotes), dashes at end of paragraph or in poetry, and abbreviations like 1st, 2nd, 8vo.

If at least 10% of the pages are seen to have errors remaining in them, then it's probably OK to use it as a qualifier.

Some things to avoid in qualifiers:

  • Excessive exceptions to the Guidelines. If a project has just one or two exceptions, it may be OK. But if there's lots of weird stuff in the project comments, it's probably better to find a different project.
  • Long passages in foreign languages. Short phrases, citations with titles of foreign books, and the like are OK.
  • Illegible page images.
  • Offensive subject matter. A book about Judaism would probably be OK; a book describing Judaism as "the scourge of the earth" would not.

Projects labelled "easy" often have many errors remaining, as proofreaders seem to be less careful if they think the job should be easy.

Who can do this: Anybody can suggest a qualifier. Each language has a coordinator who keeps track of which projects are quals. Current coordinators are:

Labeling Qualifiers

Once a project has been chosen for a P3 Qual, somebody needs to label it. The steps that need to be taken (in no particular order) are:

  • Move the project to P2_unavailable.
  • Add the tag {P3 Qual} to the project title.
  • Add P3 Qual boilerplate to the top of the project comments.

The P3 Qual boilerplate for English projects is stored in a template file, so it can be added by putting [template=P3Qu.txt] at the top of the project comments. Templates for other languages can be created by sending a request to db-req with the desired text.

If the project does not already have (nopmq) at the top, add it before the P3 Qual boilerplate. This prevents Qual projects from being released prematurely through PM queues.

If a project has (hold) at the top, this should be removed.

Who can do this: The PM of the project, or a Project Facilitator.

Splitting Qualifiers

Large projects need to be split into pieces so that they go through the P2/P3 rounds reasonably quickly, to give the evaluators fresh material to check. The size of the pieces depends on how popular the projects are. For English qualifiers, projects are split into roughly 70-130 page chunks. LOTE projects will probably need to be split into smaller pieces. It may take some experimentation to find the optimal size for any given language.

Who can do this: ortonmc, or db-req.

Releasing Qualifiers Into Rounds

Ideally, there will be one qualifier project in P2 for each language at any time. Qualifiers should always be moved into P3 as soon as they are ready. There are two ways this can be done:

Manual Release

In the absence of an automated system, a new project is manually pushed into P2 whenever the previous project finishes, and projects are manually pushed into P3 whenever they finish P2.

Who can do this: a Project Facilitator.

Automatic Release (Queues)

Queues can be set up to release a Qual project into P2 whenever there are none available, and to always release Qual projects into P3. However, this system is not foolproof, and it needs to be monitored. Some things that need to be watched are:

  • PM limits: If the project manager of a Qual project already has 13 projects in the round, his projects will not be released. In this case, it will probably be necessary to manually release the projects. This problem can occur in both P2 and P3 queues.
  • Author limits: If there's another project with the same author as a Qual project in the round, the Qual will not be released. This is another case where manual release is needed. This problem can occur in both P2 and P3 queues.
  • PM queues: Sometimes a Qual project may be released into P2 before its turn via a Project Manager queue. This can be avoided by putting (nopmq) at the top of the project comments, before the P3 Qual boilerplate. This is only a problem in the P2 queue.
  • Genre queues: Sometimes a Qual project may be released into P2 before its turn via a genre queue. Most of the time this is unlikely, because if the project's genre queue is that short, it would probably be released into P2 before you have a chance to choose it as a qualifier. If it does happen, manual release is probably necessary. This is only a problem in the P2 queue.

Who can do this: a Project Facilitator can manually release projects. db-req can set up new queues.

Currently, a P2 queue is set up for English P3 Quals. All other languages require manual release of Qual projects into P2. There is a language-independent P3 queue for Qual projects, but occasionally one may need to be pushed in manually if it's blocked by a PM or author limit.

Updating Project Comments In P3

When a Qual project moves into P3, the project comments should be modified so that they begin with (HOLD). This is so that the split pieces of the project will remain together in the F1 queue until they are merged (see below). Any existing (nopmq) tag can be removed at this point.

This is not necessary for small projects that were not split up.

Who can do this: the Project Manager, or a Project Facilitator.

Updating News Items

This task no longer needs to be done manually, as the P2 and P3 news items update automatically as qualifier projects move through the rounds.

Merging Projects

After all the pieces of a split qualifier have finished P3, they are merged back into a single project. In order for this to happen, all the pieces must be in the same round. In normal circumstances, ortonmc does this every couple of weeks, so it may be considered automatic.

Who can do this: ortonmc. If he is unavailable, db-req can also merge projects upon request.