Change Details

The Pages Created downloadable report gives details on all articles created during an event. It's purpose is to provide event organizers with data they can sort or combine with other reports to meet their various reporting needs. - **Format:** The report will be downloadable as a CSV file. The work to create that report is in T206045. - **Report filename:** when the user saves, prepopulate the filename field with the following: pages-created_//event-name// =Report content The report will include data as well as some descriptive information at the bottom. Find descriptions and definitions of each of these columns below. ===Data / column names - The left-most column of the report will be a list of page titles. - The default order will be alphabetical The column headings will be, in order (use this approved wording) - Title - URL - Description - Creator - Wiki - Namespace - Still exists? - Edits during event - Edits subsequently - Bytes changed during event - Bytes changed subsequently - Words added during event - Words added subsequently - Article class (where available) - Pageviews, cumulative - Avg. pageviews per day - Incoming links ===Descriptive info and settings At the bottom of the report, please list the following in the left column below a header that says: **Event details and report settings** - //Eventname// - From: //Start date/time// - To: //End date/time// (//timezone//) - Last data update: //date// - Filter settings for download: - ~~Article Worklist: possible answers = Applied/Not applied/None supplied~~ !![not applicable until we add Worklist features]!! - Category filter: possible answers = Applied/Not applied/None supplied - Participants list: possible answers = Applied/Not applied/None supplied - Wikis: //list wikis// !![if a variable like *.wikipedia is used, just list that, not all 300 wikipedias. Are variables like that allowed?]!! =Default filter settings In the its first incarnation, users will not be able to change the default reporting settings, since the filtering tools we're planning won't be built. The defaults, therefore, are as follows: - **Time period: EVENT** —the articles must have been created during the time period of the event. - **Participants: ON**— if the user has defined a list of participants, then metrics will be restricted to these. - **Categories: ON**—if the user has set categories for the event, the articles must be in those categories. - **Wikis:** those defined for the event in Event Setup **LOGIC** - **Logic = AND**: The relationship among the filters above will be as follows: //Time period AND Participants AND Categories.// In other words, if the organizer has supplied all three types of filtering info, then all three will be applied and results will reflect the intersection of all three (or of whichever of the three the organizer has supplied). - **When we have filters, what is the minimum?**: As we add download controls and users gain the ability to turn filters off, we'll have to face the question: what is the minimum before performance degrades too much? [[ https://meta.wikimedia.org/w/index.php?title=Talk:Community_Tech/Tools_for_program_and_event_organizers&curid=10575790&diff=18415098&oldid=18415077 | We've had one request from a user already ]] to be able to turn Time Period off and just get all data about a Category, for example. This would be something that would happen on a per-download basis (i.e., not across the board for all metrics at once). !!Would it work? @MusikAnimal, @Mooeypoo?!! =Metric definitions - **Title: ** include pages as defined in Default Filter Settings, above. Until we build filter controls, this will be Main namespace only. Show title as displayed at page top (e.g., when we do add more namespaces, it will be Talk:Pagetitle). - **URL** of the page. - **Description** Pull from the article the first sentence, truncated to X characters !![X to be determined; @Mooeypoo, what did we do in Notifications? I remember we had to increase the allotment at some point because it was too few for some scripts/languages. On English, for reference, 100 chars would be plenty. That is, of course, counting display text only, not wikitext.]!! !!If this gets too complex, we can drop but it is a useful feature for users.]]!! - **Creator** The username of the person who created the article. - **Wiki** where the article exists. Limited to the short list of wikis defined on the Event Setup screen for the event. - ~~**Namespace**~~ !![leave out of reports until we add Namespace filters?!! - **Still exists?** answers = yes/deleted. Tells whether the page still exists at the time the data was updated. (E.g., if something was deleted but reinstated, then the answer is "yes".) !!@MusikAnimal, is this something you said somehow wouldn't work with Category filter?!! - **Edits during event** The edit count to the article during the event period. - **Edits subsequently** The edit count to the article from the end of the event period until the last data update. If the event is ongoing, answer="ongoing" - **Bytes changed during event** The net bytes changed to the page during the event period. Show all numbers with a + sign to indicate direction of change. (For //this// report, all numbers will all be positive, but in other reports this number may be negative.) - ~~**Bytes changed subsequently** The net bytes changed to the page from the end of the event period until the last data update. If the event is ongoing, answer="ongoing". Show all numbers with a + or - sign to indicate direction of change. ~~ - **Words changed during event** The net change in words to the page during the event period. Show all numbers with a + sign to indicate direction of change. In our discussions, the point was raised that this calculation may be feasible for some scripts/languages more than others. We will implement for the scripts where we can and leave others for later. - For scripts/languages where this calculation is not feasible, we can either 1) omit the column, which is preferred, or 2) answer=unavailable !![@Mooeypoo, should I make a separate ticket to investigate this?]!! - ~~**Words changed subsequently** The net change in words to the page from the end of the event period until the last data update. If the event is ongoing, answer="ongoing". Show all numbers with a + or - sign to indicate direction of change. As above, omit for scripts/languages where not feasible and present as decided.~~ - **Article class (where available)** These rankings are [[ https://github.com/x-tools/xtools/blob/master/app/config/assessments.yml | available on five wikis ]]. Each has its own ranking system and codes. Use the codes appropriate to the wiki. - For wikis where article class is unavailable, we can either 1) omit the column, which is preferred, or 2) answer=unavailable !![@Mooeypoo, should I make a separate ticket to investigate this?]!! - **Pageviews, cumulative** Pageviews to the article from creation until last data update. - **Avg. pageviews per day** Cumulative total pageviews divided by days since creation, presumably. Figure allows comparison of articles from different events and of different ages. - **Incoming links** A count as of last data update of links to the article.

The Pages Created downloadable report gives details on all articles created during an event. It's purpose is to provide event organizers with data they can sort or combine with other reports to meet their various reporting needs. - **Format:** The report will be downloadable as a CSV file. The work to create that report is in T206045. - **Report filename:** when the user saves, prepopulate the filename field with the following: pages-created_//event-name// =Report content The report will include data as well as some descriptive information at the bottom. Find descriptions and definitions of each of these columns below. ===Data / column names - The left-most column of the report will be a list of page titles. - The default order will be alphabetical The column headings will be, in order (use this approved wording) - Title - URL - Description - Creator - Wiki - Namespace - Still exists? - Edits during event - ~~Edits subsequently~~ - Bytes changed during event - ~~Bytes changed subsequently~~ - Words added during event - ~~Words added subsequently~~ - Article class (where available) - Pageviews, cumulative - Avg. pageviews per day - Incoming links ===Descriptive info and settings At the bottom of the report, please list the following in the left column below a header that says: **Event details and report settings** - //Eventname// - From: //Start date/time// - To: //End date/time// (//timezone//) - Last data update: //date// - Filter settings for download: - ~~Article Worklist: possible answers = Applied/Not applied/None supplied~~ !![not applicable until we add Worklist features]!! - Category filter: possible answers = Applied/Not applied/None supplied - Participants list: possible answers = Applied/Not applied/None supplied - Wikis: //list wikis// !![if a variable like *.wikipedia is used, just list that, not all 300 wikipedias. Are variables like that allowed?]!! =Default filter settings In the its first incarnation, users will not be able to change the default reporting settings, since the filtering tools we're planning won't be built. The defaults, therefore, are as follows: - **Time period: EVENT** —the articles must have been created during the time period of the event. - **Participants: ON**— if the user has defined a list of participants, then metrics will be restricted to these. - **Categories: ON**—if the user has set categories for the event, the articles must be in those categories. - **Wikis:** those defined for the event in Event Setup **LOGIC** - **Logic = AND**: The relationship among the filters above will be as follows: //Time period AND Participants AND Categories.// In other words, if the organizer has supplied all three types of filtering info, then all three will be applied and results will reflect the intersection of all three (or of whichever of the three the organizer has supplied). - **When we have filters, what is the minimum?**: As we add download controls and users gain the ability to turn filters off, we'll have to face the question: what is the minimum before performance degrades too much? [[ https://meta.wikimedia.org/w/index.php?title=Talk:Community_Tech/Tools_for_program_and_event_organizers&curid=10575790&diff=18415098&oldid=18415077 | We've had one request from a user already ]] to be able to turn Time Period off and just get all data about a Category, for example. This would be something that would happen on a per-download basis (i.e., not across the board for all metrics at once). !!Would it work? @MusikAnimal, @Mooeypoo?!! =Metric definitions - **Title: ** include pages as defined in Default Filter Settings, above. Until we build filter controls, this will be Main namespace only. Show title as displayed at page top (e.g., when we do add more namespaces, it will be Talk:Pagetitle). - **URL** of the page. - **Description** Pull from the article the first sentence, truncated to X characters !![X to be determined; @Mooeypoo, what did we do in Notifications? I remember we had to increase the allotment at some point because it was too few for some scripts/languages. On English, for reference, 100 chars would be plenty. That is, of course, counting display text only, not wikitext.]!! !!If this gets too complex, we can drop but it is a useful feature for users.]]!! - **Creator** The username of the person who created the article. - **Wiki** where the article exists. Limited to the short list of wikis defined on the Event Setup screen for the event. - ~~**Namespace**~~ !![leave out of reports until we add Namespace filters?!! - **Still exists?** answers = yes/deleted. Tells whether the page still exists at the time the data was updated. (E.g., if something was deleted but reinstated, then the answer is "yes".) !!@MusikAnimal, is this something you said somehow wouldn't work with Category filter?!! - **Edits during event** The edit count to the article during the event period. - **Edits subsequently** The edit count to the article from the end of the event period until the last data update. If the event is ongoing, answer="ongoing" - **Bytes changed during event** The net bytes changed to the page during the event period. Show all numbers with a + sign to indicate direction of change. (For //this// report, all numbers will all be positive, but in other reports this number may be negative.) - ~~**Bytes changed subsequently** The net bytes changed to the page from the end of the event period until the last data update. If the event is ongoing, answer="ongoing". Show all numbers with a + or - sign to indicate direction of change. ~~ - **Words changed during event** The net change in words to the page during the event period. Show all numbers with a + sign to indicate direction of change. In our discussions, the point was raised that this calculation may be feasible for some scripts/languages more than others. We will implement for the scripts where we can and leave others for later. - For scripts/languages where this calculation is not feasible, we can either 1) omit the column, which is preferred, or 2) answer=unavailable !![@Mooeypoo, should I make a separate ticket to investigate this?]!! - ~~**Words changed subsequently** The net change in words to the page from the end of the event period until the last data update. If the event is ongoing, answer="ongoing". Show all numbers with a + or - sign to indicate direction of change. As above, omit for scripts/languages where not feasible and present as decided.~~ - **Article class (where available)** These rankings are [[ https://github.com/x-tools/xtools/blob/master/app/config/assessments.yml | available on five wikis ]]. Each has its own ranking system and codes. Use the codes appropriate to the wiki. - For wikis where article class is unavailable, we can either 1) omit the column, which is preferred, or 2) answer=unavailable !![@Mooeypoo, should I make a separate ticket to investigate this?]!! - **Pageviews, cumulative** Pageviews to the article from creation until last data update. - **Avg. pageviews per day** Cumulative total pageviews divided by days since creation, presumably. Figure allows comparison of articles from different events and of different ages. - **Incoming links** A count as of last data update of links to the article.

The Pages Created downloadable report gives details on all articles created during an event. It's purpose is to provide event organizers with data they can sort or combine with other reports to meet their various reporting needs. - **Format:** The report will be downloadable as a CSV file. The work to create that report is in T206045. - **Report filename:** when the user saves, prepopulate the filename field with the following: pages-created_//event-name// =Report content The report will include data as well as some descriptive information at the bottom. Find descriptions and definitions of each of these columns below. ===Data / column names - The left-most column of the report will be a list of page titles. - The default order will be alphabetical The column headings will be, in order (use this approved wording) - Title - URL - Description - Creator - Wiki - Namespace - Still exists? - Edits during event - - ~~Edits subsequently~~ - Bytes changed during event - - ~~Bytes changed subsequently~~ - Words added during event - - ~~Words added subsequently ~~ - Article class (where available) - Pageviews, cumulative - Avg. pageviews per day - Incoming links ===Descriptive info and settings At the bottom of the report, please list the following in the left column below a header that says: **Event details and report settings** - //Eventname// - From: //Start date/time// - To: //End date/time// (//timezone//) - Last data update: //date// - Filter settings for download: - ~~Article Worklist: possible answers = Applied/Not applied/None supplied~~ !![not applicable until we add Worklist features]!! - Category filter: possible answers = Applied/Not applied/None supplied - Participants list: possible answers = Applied/Not applied/None supplied - Wikis: //list wikis// !![if a variable like *.wikipedia is used, just list that, not all 300 wikipedias. Are variables like that allowed?]!! =Default filter settings In the its first incarnation, users will not be able to change the default reporting settings, since the filtering tools we're planning won't be built. The defaults, therefore, are as follows: - **Time period: EVENT** —the articles must have been created during the time period of the event. - **Participants: ON**— if the user has defined a list of participants, then metrics will be restricted to these. - **Categories: ON**—if the user has set categories for the event, the articles must be in those categories. - **Wikis:** those defined for the event in Event Setup **LOGIC** - **Logic = AND**: The relationship among the filters above will be as follows: //Time period AND Participants AND Categories.// In other words, if the organizer has supplied all three types of filtering info, then all three will be applied and results will reflect the intersection of all three (or of whichever of the three the organizer has supplied). - **When we have filters, what is the minimum?**: As we add download controls and users gain the ability to turn filters off, we'll have to face the question: what is the minimum before performance degrades too much? [[ https://meta.wikimedia.org/w/index.php?title=Talk:Community_Tech/Tools_for_program_and_event_organizers&curid=10575790&diff=18415098&oldid=18415077 | We've had one request from a user already ]] to be able to turn Time Period off and just get all data about a Category, for example. This would be something that would happen on a per-download basis (i.e., not across the board for all metrics at once). !!Would it work? @MusikAnimal, @Mooeypoo?!! =Metric definitions - **Title: ** include pages as defined in Default Filter Settings, above. Until we build filter controls, this will be Main namespace only. Show title as displayed at page top (e.g., when we do add more namespaces, it will be Talk:Pagetitle). - **URL** of the page. - **Description** Pull from the article the first sentence, truncated to X characters !![X to be determined; @Mooeypoo, what did we do in Notifications? I remember we had to increase the allotment at some point because it was too few for some scripts/languages. On English, for reference, 100 chars would be plenty. That is, of course, counting display text only, not wikitext.]!! !!If this gets too complex, we can drop but it is a useful feature for users.]]!! - **Creator** The username of the person who created the article. - **Wiki** where the article exists. Limited to the short list of wikis defined on the Event Setup screen for the event. - ~~**Namespace**~~ !![leave out of reports until we add Namespace filters?!! - **Still exists?** answers = yes/deleted. Tells whether the page still exists at the time the data was updated. (E.g., if something was deleted but reinstated, then the answer is "yes".) !!@MusikAnimal, is this something you said somehow wouldn't work with Category filter?!! - **Edits during event** The edit count to the article during the event period. - **Edits subsequently** The edit count to the article from the end of the event period until the last data update. If the event is ongoing, answer="ongoing" - **Bytes changed during event** The net bytes changed to the page during the event period. Show all numbers with a + sign to indicate direction of change. (For //this// report, all numbers will all be positive, but in other reports this number may be negative.) - ~~**Bytes changed subsequently** The net bytes changed to the page from the end of the event period until the last data update. If the event is ongoing, answer="ongoing". Show all numbers with a + or - sign to indicate direction of change. ~~ - **Words changed during event** The net change in words to the page during the event period. Show all numbers with a + sign to indicate direction of change. In our discussions, the point was raised that this calculation may be feasible for some scripts/languages more than others. We will implement for the scripts where we can and leave others for later. - For scripts/languages where this calculation is not feasible, we can either 1) omit the column, which is preferred, or 2) answer=unavailable !![@Mooeypoo, should I make a separate ticket to investigate this?]!! - ~~**Words changed subsequently** The net change in words to the page from the end of the event period until the last data update. If the event is ongoing, answer="ongoing". Show all numbers with a + or - sign to indicate direction of change. As above, omit for scripts/languages where not feasible and present as decided.~~ - **Article class (where available)** These rankings are [[ https://github.com/x-tools/xtools/blob/master/app/config/assessments.yml | available on five wikis ]]. Each has its own ranking system and codes. Use the codes appropriate to the wiki. - For wikis where article class is unavailable, we can either 1) omit the column, which is preferred, or 2) answer=unavailable !![@Mooeypoo, should I make a separate ticket to investigate this?]!! - **Pageviews, cumulative** Pageviews to the article from creation until last data update. - **Avg. pageviews per day** Cumulative total pageviews divided by days since creation, presumably. Figure allows comparison of articles from different events and of different ages. - **Incoming links** A count as of last data update of links to the article.