Change Details

[Pagepile](https://tools.wmflabs.org/pagepile/howto.html) is a really powerful way for exchanging data in the Wikimedia ecosystem -- it allows for sets of content pages to interact with tools like Petscan, Tabernacle, the Programs and Events dashboard, Citation Hunt, AC/DC and others to meaningfully exchange sets of pages. Wikimedia content is constantly changing so a query or list generated at one point of time, can very likely be different the next day by using the exact same strategy -- having a stable list of content allows for end users to do more consistent batch processing, tracking and support can be done with the same stable list of content. However, because Pagepile is a Magnus tool and kindof obscure for folks who don't use batch processing tools -- creating a stable content list is often not very "easy" or user friendly: folks output data in unstable or not well-integrated formats like Wikidata Queries, on-wiki text lists, and CSV files which have to be reconverted (typically through something like Petscan) to be used elsewhere in the Wikimedia system. Moreover, because it is a volunteer-supported service we can't, for instance, rely on such a list in core platform features (i.e. if we build the neighbourhoods described in the Audiences strategy papers, if we support great content campaigns for projects on Commons through upload campaigns, etc). Moreover pagepiles are static -- which means that they only output at one point, but the options for updating it mean you have to "regenerate" the list as a new output, even if its just an extension of the previous list (there is not "list history" so to speak -- instead each pile is a separate independent object). This means that "list owners" can't lean on these lists too update multiple other locations -- instead you have to recreate the list and manually update its use elsewhere. This kind of application is partially being solve by tools like Listeria, but that is entirely dependent on the Wikidata Query Service, but that only includes a subset of the criteria that you might use to form a list (with a tools like PattyPan, Quarry or Manual work). WMF has already begun integrating a content list tool for the ContentTranslation Campaigns (see T96147) but it is not on a higher-level roadmap to generalize such a tool beyond the ContentTranslation environment. List building is a core behaviour of almost every type of knowledge creation, maintenance and reporting in the movement -- and without a core-supported portable format for exchanging those lists across the projects a content list from a translation campaign, is not very useful for reporting/metrics, or for, example, generating a list for illustrating those same articles across the multiple languages, or for monitoring that same set of content for recent changes. Is anyone thinking about these opportunities or issues? P.S. We built a tool that demonstrates the kinds of applications that a more complex exchange format might encourage (i.e. prototype of creating a generic worklist separate from Translation for a GSOC project with @Surlycyborg @Meghasharma213: https://phabricator.wikimedia.org/T190555 and https://tools.wmflabs.org/worklist-tool/).

[Pagepile](https://tools.wmflabs.org/pagepile/howto.html) is a really powerful way for exchanging data in the Wikimedia ecosystem -- it allows for sets of content pages to interact with tools like Petscan, Tabernacle, the Programs and Events dashboard, Citation Hunt, AC/DC and others to meaningfully exchange sets of pages. Wikimedia content is constantly changing so a query or list generated at one point of time, can very likely be different the next day by using the exact same strategy -- having a stable list of content allows for end users to do more consistent batch processing, tracking and support can be done with the same stable list of content. However, because Pagepile is a Magnus tool and kindof obscure for folks who don't use batch processing tools -- creating a stable content list is often not very "easy" or user friendly: folks output data in unstable or not well-integrated formats like Wikidata Queries, on-wiki text lists, and CSV files which have to be reconverted (typically through something like Petscan) to be used elsewhere in the Wikimedia system. Moreover, because it is a volunteer-supported service we can't, for instance, rely on such a list in core platform features (i.e. if we build the neighbourhoods described in the Audiences strategy papers, if we support great content campaigns for projects on Commons through upload campaigns, etc). Moreover pagepiles are static -- which means that they only output at one point, but the options for updating it mean you have to "regenerate" the list as a new output, even if its just an extension of the previous list (there is not "list history" so to speak -- instead each pile is a separate independent object). This means that "list owners" can't lean on these lists to update multiple other locations -- instead you have to recreate the list and manually update its use elsewhere. This kind of application is partially being solved by tools like Listeria, but that is entirely dependent on the Wikidata Query Service, but that only includes a subset of the inputs that you might use to form a list (with a tools like PattyPan, Quarry or Manual work). WMF has already begun integrating a content list tool for the ContentTranslation Campaigns (see T96147) but it is not on a higher-level roadmap to generalize such a tool beyond the ContentTranslation environment. List building is a core behavior of almost every type of knowledge creation, maintenance and reporting in the movement -- and without a core-supported portable format for exchanging those lists across the projects a content list from a translation campaign, is not very useful for reporting/metrics, or for, example, generating a list for illustrating those same articles across the multiple languages, or for monitoring that same set of content for recent changes. Is anyone thinking about these opportunities or issues? P.S. We built a tool that demonstrates the kinds of applications that a more complex exchange format might encourage (i.e. prototype of creating a generic worklist separate from Translation for a GSOC project with @Surlycyborg @Meghasharma213: https://phabricator.wikimedia.org/T190555 and https://tools.wmflabs.org/worklist-tool/).

[Pagepile](https://tools.wmflabs.org/pagepile/howto.html) is a really powerful way for exchanging data in the Wikimedia ecosystem -- it allows for sets of content pages to interact with tools like Petscan, Tabernacle, the Programs and Events dashboard, Citation Hunt, AC/DC and others to meaningfully exchange sets of pages. Wikimedia content is constantly changing so a query or list generated at one point of time, can very likely be different the next day by using the exact same strategy -- having a stable list of content allows for end users to do more consistent batch processing, tracking and support can be done with the same stable list of content. However, because Pagepile is a Magnus tool and kindof obscure for folks who don't use batch processing tools -- creating a stable content list is often not very "easy" or user friendly: folks output data in unstable or not well-integrated formats like Wikidata Queries, on-wiki text lists, and CSV files which have to be reconverted (typically through something like Petscan) to be used elsewhere in the Wikimedia system. Moreover, because it is a volunteer-supported service we can't, for instance, rely on such a list in core platform features (i.e. if we build the neighbourhoods described in the Audiences strategy papers, if we support great content campaigns for projects on Commons through upload campaigns, etc). Moreover pagepiles are static -- which means that they only output at one point, but the options for updating it mean you have to "regenerate" the list as a new output, even if its just an extension of the previous list (there is not "list history" so to speak -- instead each pile is a separate independent object). This means that "list owners" can't lean on these lists too update multiple other locations -- instead you have to recreate the list and manually update its use elsewhere. This kind of application is partially being solved by tools like Listeria, but that is entirely dependent on the Wikidata Query Service, but that only includes a subset of the criteriainputs that you might use to form a list (with a tools like PattyPan, Quarry or Manual work). WMF has already begun integrating a content list tool for the ContentTranslation Campaigns (see T96147) but it is not on a higher-level roadmap to generalize such a tool beyond the ContentTranslation environment. List building is a core behaviour of almost every type of knowledge creation, maintenance and reporting in the movement -- and without a core-supported portable format for exchanging those lists across the projects a content list from a translation campaign, is not very useful for reporting/metrics, or for, example, generating a list for illustrating those same articles across the multiple languages, or for monitoring that same set of content for recent changes. Is anyone thinking about these opportunities or issues? P.S. We built a tool that demonstrates the kinds of applications that a more complex exchange format might encourage (i.e. prototype of creating a generic worklist separate from Translation for a GSOC project with @Surlycyborg @Meghasharma213: https://phabricator.wikimedia.org/T190555 and https://tools.wmflabs.org/worklist-tool/).