1 / 10

Report on the Early-copy-editing Experiment Bert Wijnen bwijnen@lucent Nov, 2005

Report on the early copy-editing experiment conducted by IETF, listing objectives, impacts, data points, and next steps for improving document quality and streamlining editorial processes. Contact: Bert Wijnen (bwijnen@lucent.com)

glendab
Download Presentation

Report on the Early-copy-editing Experiment Bert Wijnen bwijnen@lucent Nov, 2005

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Report on the Early-copy-editingExperimentBert Wijnenbwijnen@lucent.comNov, 2005

  2. Up-to-date info • Ops.ietf.org/ece • Lists the documents that have gone through the process up to now • Will be kept up to date as we learn more later in the process or if we do more documents

  3. Experiment Initiators • Leslie Daigle (IAB) • Allison Mankin (IESG) • Bert Wijnen (IESG) • Aaron Falk (RFC-Editor) • Joyce Reynolds (RFC-Editor) • Bob Braden (RFC-Editor)

  4. Experiment Workers • Alice Hagens (RFC-Editor) – Great Job • Editors/WG-chairs of these WGs: • Aaa (OPS area) • Adslmib (OPS area) • Mobike (SEC area) • Secsh (SEC area) • Sip (TSV area) • V6ops (OPS area)

  5. The experiment objectives • Improve document quality early on • Experiment to perform as much of the editorial work as possible early in the process, e.g., before working group last call. • This was/is a very limited initial experiment that should begin to sort out the issues. We can then decide whether further experimentation is warranted.

  6. Expected (or hoped for) Impact • positive impact on WG Last Call, AD review, IETF Last Call and IESG review. • This is expected because of clearer/better text early on. • less copy-editing, so faster process after IESG approval. • This hopefully reduces the time between IESG approval and RFC publication. • Reduction of time spend in status AUTH48. • This is expected because there should be less changes (if any) between the approved text and the rfc-to-be-published.

  7. What we did • Serialize input from WGs into RFC-Editor via Bert • Submit/edit .XML source files to/by the RFC-editor • RFC-editor returned .XML file via Bert • Author checks/edits .XML and then regenerates I-D • That I-D gets WG Last Called • .XML file of that ID to Bert • Kept track of timings and number of changes

  8. Data Points – my summary • Average elapsed days at RFC-Editor • 17 days for 6 docs = approx. 3 • Hours spend by RFC-Editor • 43 total 354 page = approx 1 hr/8-9 pages • # of changes by RFC-Editor • 1149 lines • # of changes by Author to returned doc • 1360 (311 for future tense) (860 by error) • Number of changes after WG Last Call • Still to be checked (not sure all LCs ended)

  9. Summary of my perception • We skipped the source control steps • Pity. We may need an IETF service for that • Positive experience • Great turnaround • Cannot channel/serialize if production • Need to be careful what we ship each way • Need to follow what happens in WGLC, AD review, IETFLC, IESG review, RFC_ED and AUTH48

  10. Next steps • Follow up what happens with docs that participated in experiment • More experiments • To get more data points • To check other source formats • Using a commodity copy-editor • But wonder if we can channel it all via one person (for the serialization and recording of changes and ensuring proper steps followed)

More Related