Organizers, and their sponsors and partners want to understand the impact and quality of articles created during an event. Organizers who are focused on creating content also have a desire to know precisely which of the articles created during an event have been deleted, so they can attempt to rescue those articles.
The task here is to figure out how to provide this data in (to begin with)This metric will be used (initially) in the Event Summary (T205561 and T206692 ) and Pages Created (T206058 and T205502) reports.
The data will be somewhat different in these twoeach of the reports.
- **In Event Summary reports:** here, the metric will be the overall "New Page Survival Rate" for the whole event, expressed as a percentage. E.g., if 100 articles were created during the event and 15 deleted afterwards, the New Page Survival Rate is 85%. (At the close of the event timer period, all events will have a 100% survival rate).
- **In Pages Created**: reports**: this report is a list of articles created. So the metric here will be an indication, for each individual article, of whether it "Still Exists?". Possible answers = "yes" or "deleted".
=The p=Proposed method and its limitationsstrengths/weaknesses
- **Method—make a record at close of event:** To track pages created and lost with perfect accuracy, we would have to make a record of all existing articles every time the data was updated and keep all the diffs for comparison. This is not practical for our system. InsteadBased on the Archive log** After discussing various approaches, we propose to automatically trigger a data update at the close of the event period and save a snapshot of extant articles at that timethe method we've selected here uses the Archive log. All future statistics and reports will be compared to thatThis has certain strengths and weaknesses.
- **Save as much data as possible** In addition to saving the article title, URL and ID, it would be ideal if we can save a number of other relevant figuresWon't work with Category filter:** if the organizer has used the Category filter to define the event, in order to provide comparison metrics in future reports. For example:
- Edits during event—saving would enable us to add an "edits subsequently" metricno Survival Rate figures will be possible.
- Bytes changed during event—saving would enable us to add an "bytes subsequently" metric.
- ~~Words added during event—saving would enable us to add an "words subsequently" metric.~~ - **In such cases**, the system will post an answer of "n/a", for not available. I.e., we will not simply omit the column from spreadsheets or screen display.
- Article class (where available)—saving would enable us to track improvements in class.
- Incoming links—saving would enable us to track growth in links.
- **No figure until event close: **prior to event closeWill track articles deleted during the event:** If an article is created during the event and then deleted before the end of the event, no figure will be reported and relevant fields will be filled with the notation "n/a" for not availablewe can still track that article.
- **Won't count articles deleted during event period: ** At any given time during the event period, the Pages Created reports will show only those articles that are present at the time of the report (or of the last data update). So if an article is created and deleted before the report is madeMetric can be run at any time: **This metric will be available during the time period of the event (i.e., that articleorganizers will not show up inhave to wait until the reportevent is over to see the metric).
- **Surviving articles tracked indefinitely: **All surviving articles at the close of the event period will continue to be a part of the Pages Created report indefinitelyMetric continues to develop:** The number of articles created during an event is fixed once the event ends. However, whether they are subsequently deletedthe metric for survival rate can continue to go up or not.down, as created articles are either deleted or restored.