Created a quick first draft of instructions for how to claim phab tasks and work on docs during the hackathon: https://www.mediawiki.org/wiki/Doc_Your_Tool:_Creating_user-friendly_documentation/Instructions

Draft of Tool Docs guide is now ready finalized at https://www.mediawiki.org/wiki/Documentation/Tool_docs. I welcome any edits and feedback on it (feel free to use the Talk page or comment on this task).

Status update:

• Timeline established (Google doc) and phab subtasks filed under T350914 for landing page review of the 4 major sections of the new Data platform docs portal page (the main landing page)
• Working group of subject matter experts created and we now have a dedicated Slack channel for coordinating this work
• Draft of the "Discover data" landing page (1 of 4) is shared and undergoing review with a deadline of April 12.
• Draft of the "Analyze data" landing page (2 of 4) is in progress with a deadline for sharing the draft for feedback on April 15

The fix looks good! If there's a way that I or other contributors could help improve this interface, I'd be happy to make additional improvements to make it easier to navigate and discover all this juicy data.

The new document I suggested creating when I filed this would be a how-to page focused on the task of managing tool quota and resources. For example, a new page entitled "Manage tool quota and resources". Right now, this content being in a k8s-specific document requires users to understand what k8s is and get familiar with it in order to be able to find the information. It also requires visiting many different docs to try to understand how to work with tool quota -- the information is not all covered in the k8s section on quota. The conceptual structure of the docs should be focused first on the user's task, then on the technologies that support that task, rather than vice versa -- because the underlying technologies change over time, but the users' tasks are generally the same. It's also easier to get things done when the information related to one task is in one document, rather than mixed with other content in a document focusing on a larger topic like k8s instead of a task-focused topic like "how to manage your tool's resources".

Note to self about which subpages of Analytics/Data_lake/Edits I'm choosing to feature on the "Discover data" landing page section for Edits data: it's based on pageview data for the past 4 years, for the wiki pages about private datasets only, as reported by the Pagevviews tool:

Status update:
I've been working on a draft of some tool-specific documentation guidelines:
https://www.mediawiki.org/wiki/User:TBurmeister_(WMF)/Sandbox/Tool_docs

Created draft landing pages with outlines based on initial content that was seeded in https://wikitech.wikimedia.org/wiki/Data_Platform_Engineering:
Main landing page: https://wikitech.wikimedia.org/wiki/User:Triciaburmeister/Sandbox/Data_platform
Sub-landing pages:

• https://wikitech.wikimedia.org/wiki/User:Triciaburmeister/Sandbox/Data_platform/Discover_data
• https://wikitech.wikimedia.org/wiki/User:Triciaburmeister/Sandbox/Data_platform/Analyze_data
• https://wikitech.wikimedia.org/wiki/User:Triciaburmeister/Sandbox/Data_platform/Publish_data
• https://wikitech.wikimedia.org/wiki/User:Triciaburmeister/Sandbox/Data_platform/Collect_data

Since work on this project has been stalled for a bit due to its large scope and complexity, today I built out a set of demo wiki pages in my sandbox, to try to help us feel out what our WIP content framework could look like when more fully built-out on wiki: https://wikitech.wikimedia.org/wiki/User:Triciaburmeister/Sandbox/Data_platform

I wasn't able to use the categories as I had hoped because it turns out the DynamicPageList extension isn't installed on Wikitech. So I put together a revised content outline just by linking to the categories and other key landing pages:

First draft of this doc has been shared with subject matter experts for their review and feedback. After that round of reviews, I'll move to the next stage of publishing on-wiki and planning for larger community feedback cycles.

Updated explanation of this task and how it fits in with other ongoing work:
This overview doc is part of a refresh of Research:Data and related data documentation pages on Meta. Research:Data will continue to function as the primary landing page for researchers to get started with Wikimedia data. However, instead of providing a one-page list of many available data access methods, in my proposed revision, it will instead provide links to several new pages:

Project page is now live at https://www.mediawiki.org/wiki/Doc_Your_Tool:_Creating_user-friendly_documentation

I'd like to add this task to the list of Documentation tasks for Wikimedia-Hackathon-2024 (see T358040), but I couldn't quickly find out if PattyPan is working again / working enough that this would be a valid task. If someone who has more insight could determine if this would be feasible or worthwhile to work on at the hackathon, please add those tags :-) Thanks!

I love this idea, it would also be a great way to connect our data documentation with tools that can serve as living examples of how to use the data sources and APIs.

I believe the following documentation and interactive tutorial covers the issues reported in this task, so I am resolving it. Please feel free to reopen if you disagree.
https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/Wikidata_Query_Help
https://www.wikidata.org/wiki/Wikidata:SPARQL_tutorial
https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/A_gentle_introduction_to_the_Wikidata_Query_Service
https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/queries
https://wdqs-tutorial.toolforge.org/

I believe the WMF data products team are already working on this as part of the Commons Impact Metrics project, see T355560 and https://commons.wikimedia.org/wiki/Commons:WMF_support_for_Commons/Commons_Impact_Metrics

Status update: Did more work to add categories as page metadata so we can more freely design landing pages and other navigation that isn't tied to page/subpage structure. For example, some of the pages within one category might go in different sections of the landing page navigation, like a page on how to use Spark vs. a page on how to administer it. Also hoping that having these categories can make it easier to divide and conquer when it comes to reviewing and archiving outdated content.

I just encountered Template:Namespaces on https://en.wikipedia.org/wiki/Wikipedia:Administration#Data_structure_and_development (and other pages), and I immediately thought it should exist as a Special: page on all wikis. In the past, I've struggled with figuring out the actual namespaces and their IDs for mediawiki.org and wikitech.wikimedia.org (especially because on the latter there are some pages with titles that masquerade as namespaces, like Portal:). Having an easily accessible list of namespaces like this would make it easier to understand and manage content on our technical wikis...without having to "poke the API or look at the wiki config". Also, even if you do poke the API or look at the config, the template's table format is just so much lovelier and easier to quickly understand.

Good point! I added a parent category for Contribution data and nested Edits data under that.

To help with making sense of this large corpus of docs (with many confusing page redirects), and to power future landing page design, I've created some categories on Wikitech and started categorizing the pages. So far, I've created the following categories and started applying them to pages that were obvious candidates based on their current/legacy page structure:

I provided my text phrase in the private paste. I hope it's correct because (facepalm) I just wrote it on a piece of paper so I don't know if there are actually new lines in the original text.

Status update:

• Did a deep dive ("research spike"?) into mediawiki_history dataset docs and working on understanding the different data products where that information is available, and assessing the state of the documentation for this dataset in those various contexts (i.e. https://wikitech.wikimedia.org/wiki/Analytics/Data_Lake/Edits/Mediawiki_history_dumps, https://dumps.wikimedia.org/other/mediawiki_history/readme.html, https://www.mediawiki.org/wiki/Manual:Revision_table)
• Focused most of my efforts on T343146, so no major additional progress to report on this task this week.

Status update:

• Made progress on content drafts this week, including starting to finalize a page structure that feels able to be consistently applied across overview docs for the different data domains. Estimated completion status before docs can be shared for initial feedback with SMEs:
  • Intro to Wikimedia Open Data: 60%
  • Overview of traffic/pageviews analysis: 30%
  • Overview of content analysis: 40%
  • Overview of edits/editors analysis: 50%
• Target date for sharing the above docs for SME feedback is Feb 2. After that initial feedback round and resulting content updates, the plan is that the docs will go on-wiki and I'll coordinate a community feedback process with Kinneret / the Research team.
• Met with Kinneret and Leila from Research to share about ongoing doc work and discuss plans potential future work on Research docs on Meta.
• Did some project management and diagramming work to try to clarify the scope of this work and related work on DPE docs, and separate that from work that needs to happen next fiscal year.
• Working on identifying how to best align and coordinate this docs work with related efforts like T333895

Hi Leila, I think content I'm working on drafting right now for T343146 might be useful for this course module. If you have any notes or outlines of what you had envisioned for the course content, could you share? Then I can look into whether it makes sense for the doc content on Meta to cover the same content. I will also share my draft as soon as I've finished the basic content outline. I'm glad I found this task while I was working on this!