Page MenuHomePhabricator
Search Advanced Search
Use the application-specific Advanced Search to set additional search criteria: Tasks, Commits. (More information)
    • Task
    ### Non-404 errors - `/commons-analytics/edits-per-category-monthly/{category}/{category-scope}/{edit-type}/{start}/{end}` - start timestamp should be before the end timestamp - `/commons-analytics/media-file-metrics-snapshot/{media-file}/{start}/{end}` - invalid date - all time series end-points - the end timestamp is exclusive, but the documentation suggests it's inclusive ### 404s - `/commons-analytics/category-metrics-snapshot/{category}/{start}/{end}` - `/commons-analytics/edits-per-category-monthly/{category}/{category-scope}/{edit-type}/{start}/{end}` - `/commons-analytics/top-viewed-categories-monthly/{category-scope}/{wiki}/{year}/{month}` - `/commons-analytics/top-wikis-per-category-monthly/{category}/{category-scope}/{year}/{month}` - `/commons-analytics/top-pages-per-category-monthly/{category}/{category-scope}/{wiki}/{year}/{month}` - `/commons-analytics/top-editors-monthly/{category}/{category-scope}/{edit-type}/{year}/{month}` - `/commons-analytics/media-file-metrics-snapshot/{media-file}/{start}/{end}` - `/commons-analytics/pageviews-per-media-file-monthly/{media-file}/{wiki}/{start}/{end}` - `/commons-analytics/top-viewed-media-files-monthly/{category}/{category-scope}/{wiki}/{year}/{month}` - `/commons-analytics/top-wikis-per-media-file-monthly/{media-file}/{year}/{month}` - `/commons-analytics/top-pages-per-media-file-monthly/{media-file}/{wiki}/{year}/{month}` - `/commons-analytics/edits-per-user-monthly/{user-name}/{edit-type}/{start}/{end}\`
    • Task
    [[ https://doc.wikimedia.org/analytics-api | AQS documentation ]] currently uses RapiDoc mini to display API sandboxes. This might not be the best long-term solution (RapiDoc's development seems to have stalled, and it's not as full-featured as some other tools). Investigate replacements for RapiDoc in AQS docs. Current list of alternatives to check: [] [[ https://github.com/scalar/scalar | Scalar ]]
    • Task
    Now that AQS 1.0 is shut down, we need to consolidate https://wikitech.wikimedia.org/wiki/Data_Platform/Systems/AQS and https://wikitech.wikimedia.org/wiki/AQS_2.0. To do: - [x] @SGupta-WMF to identify any sections on Data_Platform/Systems/AQS that are no longer applicable to AQS 2.0 - [x] @apaskulin to consolidate pages - [x] @SGupta-WMF to review consolidated page https://wikitech.wikimedia.org/wiki/Data_Platform/Systems/AQS
    • Task
    In the current docs [[ https://www.mediawiki.org/wiki/Extension:CommunityConfiguration/Technical_documentation#Getting_started | Technical_documentation#Getting_started ]] section there's general information about how to setup a provider but relevant details are missing. This task is to improve the status quo of docs around providers **Acceptance criteria** - [] Document available provider types explaining differences: //mw-config// and //data// - [] Documentation should mention some "guidelines" about constraints to pick one or the other or create a custom one - [] ...
    • Task
    **Current Situation:** Up to our last release `wmde.20` we released `wikibase` and `wikibase-bundle`, with different feature sets. With the upcoming releases we decided to deprecate `wikibase` and rename `wikibase-bundle` to `wikibase`. So the `wikibase` image now carries all the functionality the bundle image had before. **Goal** Announce this change with the next release announcement. **Acceptance Criteria** - [ ] deprecation and renaming is part of the release announcement
    • Task
    [placeholder task] Using Wikimedia's analytics instance to get better data points for understanding information architecture issues and general user behaviour for further optimizations.
    • Task
    It seems to be poorly documented what non/low/medium/high mean in terms of linter categories. One can work out from the `CategoryManager` that none is not visible, the rest are: ```lang=php private const HIGH = 'high'; private const MEDIUM = 'medium'; private const LOW = 'low'; private const NONE = 'none'; /** * Categories that are configured to be displayed to users * * @return string[] */ public function getVisibleCategories() { return array_merge( $this->categories[self::HIGH], $this->categories[self::MEDIUM], $this->categories[self::LOW] ); } /** * Categories that are configured to not be displayed to users * * @return string[] */ public function getInvisibleCategories() { return $this->categories[self::NONE]; } ``` Similar goes for the the various `config` items in `extension.json`. Again, specifically `LinterCategories`. Ideally they should be documented inline, as appropriate, and also on https://www.mediawiki.org/wiki/Extension:Linter
    • Task
    **Steps to replicate the issue** (include links if applicable): * Go to https://doc.wikimedia.org/oojs-ui/master/js/OO.ui.html#.alert * I want to see the options list. The docs say "Additional options, see OO.ui.MessageDialog#getSetupProcess" * This is not a link, but OK, I search this, find and click OO.ui.MessageDialog#getSetupProcess **What happens?**: {F55729604} * Options are still not explaned * The source links to Window.js, line 355 **What should have happened instead?**: * The actual source is https://doc.wikimedia.org/oojs-ui/master/js/dialogs_MessageDialog.js.html#line148 * Options are explained there Context: T185396
    • Task
    This will cause CI to fail if `npm run doc` emits any JSDoc warnings. This is good because it prevents the creation of code that emits new JSDoc warnings. This will require fixing up old code to not emit any JSDoc warnings. This aligns with the advice at https://www.mediawiki.org/wiki/JSDoc#2._Configure_NPM * [List of repos that already have && npm run doc.](https://codesearch.wmcloud.org/deployed/?q=%22test%22.*%26%26+npm.%2Brun+doc&files=&excludeFiles=&repos=) * [List of repos that have jsdoc-wmf-theme installed.](https://codesearch.wmcloud.org/deployed/?q=jsdoc-wmf-theme&files=jsdoc%5C.json%24&excludeFiles=&repos=) * The repos to work on will be the diff of jsdoc-wmf-theme repos minus repos that already have `&& npm run doc`
    • Task
    Create the AQS API spec style guide by converting the existing spreadsheet (created in T361890) to a doc format and publishing it to Wikitech. [x] Write initial draft [x] Review [x] Publish
    • Task
    https://www.mediawiki.org/wiki/Wikimedia_Product/Data_dictionary was created before we had datahub. It should ideally be deprecated to avoid having multiple sources of information. Since these are core metrics, I'm assigning #movement-insights team to handle this, after consulting with data users on Slack.
    • Task
    == Background goal The `CdxField` component supports both a description and a help-text. To me they feel very similar, and if I am presented with a given piece of supportive/supplementary copy, then I'm often unsure which of the two I should use/recommend to use. It would be great, if you could add some guidance to the codex docs (maybe in the [style guide on constructing forms](https://doc.wikimedia.org/codex/latest/style-guide/constructing-forms.html)?) about when to use which. The [examples in the component documentation](https://doc.wikimedia.org/codex/latest/components/demos/field.html#fieldset-with-radio-group) showcase the implementation very well, but don't make the conceptual difference clear for me. ==== Difference between elements - **Label's description:** use it to provide important additional information relating to the label; and/or when you need to include links. - **Helper text:** use it to provide additional information that will assist users in entering the correct information in the Field. - **Tooltip** (will be implemented in T338282): use a Tooltip to display supplementary information that can be hidden and does not contain links. {F55410245} === Acceptance criteria (or Done) [x] Include clear guidances on Field's component indicating the difference between these elements
    • Task
    Now that Table has been merged into the [[ https://www.figma.com/design/KoDuJMadWBXtsOtzGS4134/%E2%9D%96-Codex-components?node-id=16821-377 | Figma library ]], lets add a link to the Figma spec in the [[ https://doc.wikimedia.org/codex/latest/components/demos/table.html | Table component's guidelines ]].
    • Task
    There are 31 extensions in https://www.mediawiki.org/wiki/Category:MWStakeCommonUIRegisterSkinSlotComponents_extensions on MediaWiki.org. I could not find any documentation as to what this hook actually does and why, and it took me far more effort than it should have to even find the codebase it's defined in. Ditto for the other MWStake hooks in https://www.mediawiki.org/wiki/Category:Extensions_using_unrecognized_hooks
    • Task
    As opposed to JSDuck's MediaWiki core documentation, JSDoc's doesn't show methods from mixins. * Go to https://doc.wikimedia.org/oojs-ui/master/js/OO.ui.ButtonWidget.html * Try to find `setLabel`. You will find only the inherited method `setLabelledBy`. * Or search by "mixes in". You will only find properties and `highlightQuery` which is a static method (and it's not marked as such – another bug). Compare that to JSDuck's docs at https://doc.wikimedia.org/oojs-ui/v0.44/js/#!/api/OO.ui.ButtonWidget. I suspect this happens not only for OOUI, so I didn't include "OOUI" in the name of the task, but not sure. Context: {T185396} See also: {T366400}
    • Task
    As part of the redesign of Data Platform docs (T350911) and the deprecation of Data Engineering docs on wikitech in favor of new [[ https://www.mediawiki.org/wiki/Data_Platform_Engineering | Data Platform Engineering team pages on mediawiki.org ]], the team needs to decide to either deprecate, or update and migrate the content on the following pages: * https://wikitech.wikimedia.org/wiki/Data_Platform_Engineering/Onboarding * https://wikitech.wikimedia.org/wiki/Data_Platform_Engineering/Learning_Materials * https://wikitech.wikimedia.org/wiki/Data_Platform_Engineering/Team_roles_and_expectations * https://wikitech.wikimedia.org/wiki/Data_Platform_Engineering/Meeting_norms * https://wikitech.wikimedia.org/wiki/Data_Platform_Engineering/Show_your_work When the above pages are moved, the [[ https://wikitech.wikimedia.org/wiki/Data_Platform_Engineering | Data Platform Engineering portal page on Wikitech ]] can be simplified by removing the boxes for "Data Engineering team norms and processes" and "Team learning materials", since those will all be covered by the link in the "Team and project documentation" box.
    • Task
    The tutorial at https://wikitech.wikimedia.org/wiki/Data_Platform_Engineering/Dashboard_tutorial was previously somewhat buried under old docs, but it could contain valuable information, and having a tutorial doc is great for users. This page should be reviewed to verify its accuracy and completeness. It was linked from the main Dashiki doc at https://wikitech.wikimedia.org/wiki/Data_Engineering/Systems/Dashiki, but the link was hard to see, so I moved it to a more obvious section under the Quickstart.
    • Task
    * [x] make sure CI isn't broken (sign of an abandoned extension) * [] get JSDoc + jsdoc-wmf-theme installed, with `npm run jsdoc` working and /docs/js viewable * [] compare it to JSDuck site, make sure it's identical, fix anything as needed. check both left menu and homepage. homepage has some extra stuff on it that isn't in the left menu * [] create / make sure it has a readme, in markdown. make sure the readme links to the extension on mediawiki.org * [] switch JSDuck for JSDoc on doc.wikimedia.org (by switching `npm run doc` to jsdoc. after that it will deploy instantly and the cache will clear in an hour) * [] delete any remaining JSDuck code * [] add `&& npm run doc` to the npm test script
    • Task
    === Background Data Products and Data Platform Engineering have arrived at an alternative to dynamically creating/destroying stream configs: We create a stream per Metrics Platform Base Schema and submit all Base-Schema-conforming events to those streams. This decision should be documented for posterity. === AC [] The decision is documented on-wiki ** … on a subpage of https://wikitech.wikimedia.org/wiki/Metrics_Platform/Decision_Records, for example [] A timeline of tasks and discussions should be included in the document [] …
    • Task
    Current recommendations (eg. in [[ https://faculty.washington.edu/ebender/stochasticparrots/ | Stochastic Parrots ]]) are that researchers should include estimated environmental costs of their work and of model training in their final documentation. Those using the stat* machines and Cloud VPS can use generic online resources such as green-algorithms.org to reverse-engineer the actual impacts, but ideally the Wikimedia Foundation could provide us with its own baseline estimates for: * Energy use for compute unit (eg. kWh per core per hour) * Energy use for memory unit (eg. kWh per GB per hour) * Energy use for disk transfer unit (eg. kWh per GB written / read / stored long-term) * For both the Analytics cluster and for Cloud VPS. Then researchers and others can estimate their own environmental impact from usage in a consistent and simple way.
    • Task
    T366314#9869650 and some following discussion has comments that suggest `floatleft` and `floatright` classes are supported for general use of marking up floating content. I find the documentation around these classes a bit rough, with some actionables in various files and onwiki. (I think there's probably merit to using floatleft/right as a general class per previous discussion in T78176. Non-general use can use TemplateStyles where necessary.) # https://www.mediawiki.org/wiki/Manual:$wgUseLegacyMediaStyles currently says they are part of the legacy media display (which was started as part of T354740). The relevant classes were originally used at some point for thumb markup, and then Parsoid and/or figure migration for Parser.php changed how relevant elements were styled, so that makes sense. # Is their use shifting? This documentation should be updated if so. # If in fact they are still connected to this parameter, it would be wise to disconnect them on the software side if indeed the use is shifting (see also #3/#4). # This general use should be documented on wiki somewhere, and given the context in which it's used, that should probably be at [[https://www.mediawiki.org/wiki/Recommendations_for_mobile_friendly_articles_on_Wikimedia_wikis#Inline_styles_should_not_use_properties_that_impact_sizing_and_positioning | the mobile recs page # Inline styles should not use properties that impact sizing and positioning]]. # [[https://phabricator.wikimedia.org/source/mediawiki/browse/master/resources/src/mediawiki.skinning/content.thumbnails-print.less | content.thumbnails-print.less]] currently removes their borders. This looks like a now-unnecessary holdover from their use in the thumbnail context and can be removed (after checking that the figure structure is printing whatever is desired here without them)? # [[https://phabricator.wikimedia.org/source/mediawiki/browse/master/resources/src/mediawiki.skinning/content.thumbnails-common.less | content.thumbnails-common.less]] contains the actual CSS, but if they're now being suggested for general use, they probably shouldn't be living in a file pertaining to thumbnails (see also #1B). (The new CSS looks like it's in [[https://phabricator.wikimedia.org/source/mediawiki/browse/master/resources/src/mediawiki.skinning/content.media-common.less | content.media-common.less ]].) # [[https://phabricator.wikimedia.org/source/mediawiki/browse/master/resources/src/mediawiki.skinning/content.thumbnails-screen.less$3 | content.thumbnails-screen.less]] still contains a reference to these classes despite them being now-absent. # Lastly, a minor suggestion to improve their definitions: the margins are currently living separate to the clear/float definitions for some reason (don't want the margins to apply to `tleft/right`? resolved by moving floatleft/right out of the same place), but these objects probably shouldn't have their own margins (or at least left/right margins) when they're below the mobile breakpoint in responsive skins. I realize this is kind of a grabbag but it all also kind of goes together.
    • Task
    Adding documentation to explain how the tool works and other important information. https://www.mediawiki.org/wiki/Security/Wikimedia_Risk_Calculator
    • Task
    https://gerrit.wikimedia.org/r/plugins/gitiles/wikimedia/portals/ still says: www.wikipedia.org is built using a modern (circa 2015) front-end development stack which includes HTML templates, CSS preprocessors and build tooling to generate a static, optimized HTML page. Sister project portals (e.g. www.wiktionary.org) are generated using these Lua templates on meta-wiki. After these templates are updated, the pages need to be pulled into this repository for deployment. This needs to be updated to describe the current process.
    • Task
    * [ ] eliminate 8 excludes statements in jsdoc.json (and the errors causing them to be excluded) * fix `npm run doc` warnings * [ ] The @inheritdoc tag does not permit a value; the value will be ignored. File: LanguagesMultiselectWidget.js x10 * [ ] WARNING: No contribution link found (in package.json>repository.url, or jsdoc.json>templates.wmf.repository) * [ ] convert README to README.md (markdown), so that /doc/index.html is readable * [ ] check for missing classes and methods * [] RenameDropdown methods * [] GroupSynchronization class & methods * more? * [x] check for and fix doc-related linter errors. (add `npm run lint` to facilitate this)
    • Task
    ### Background ### Wikimedia is switching from JavaScript documentation engine JSDuck to JSDoc. All JavaScript docblocks that use tags and syntax unique to JSDuck should be switched to tags and syntax supported by JSDoc. ### Tags to refactor ### I diffed all the JSDuck tags and all the JSDoc tags, and came up with the following list of tags that only occur in JSDuck (and therefore should be mass refactored): https://www.mediawiki.org/wiki/JSDoc#Converting_from_JSDuck_to_JSDoc Doing codesearches of each tag, the following are present in our codebases: * [ ] [[ https://codesearch.wmcloud.org/deployed/?q=%40alternateClassName&files=%5C.js%24&excludeFiles=&repos= | @alternateClassName ]] * [ ] [[ https://codesearch.wmcloud.org/deployed/?q=%40inheritable&files=%5C.js%24&excludeFiles=&repos= | @inheritable ]] * [ ] [[ https://codesearch.wmcloud.org/deployed/?q=%40localdoc&files=%5C.js%24&excludeFiles=&repos= | @localdoc ]] * [x] [[ https://codesearch.wmcloud.org/deployed/?q=%40mixins&files=%5C.js%24&excludeFiles=&repos= | @mixins ]] * [ ] [[ https://codesearch.wmcloud.org/deployed/?q=%40singleton&files=%5C.js%24&excludeFiles=&repos= | @singleton ]] * [ ] [[ https://codesearch.wmcloud.org/deployed/?q=%40template&files=%5C.js%24&excludeFiles=&repos= | @template ]] * [ ] [[ https://codesearch.wmcloud.org/deployed/?q=%40uses&files=%5C.js%24&excludeFiles=&repos= | @uses ]] Let me know if one of these tags should not be refactored (e.g. we support it via a plugin (`@chainable`), or we want to keep it because it makes the code more readable (`@constructor`))
    • Task
    **Current Situation:** - WBS Deploy ships WDQS - We have no documentation about using this WDQS **Goal:** - Reference existing documentation for things not specific to WBS Deploy (e.g. WDQS, SPARQL) - For what remains, document how to use WDQS in the WBS Deploy context - Through the WDQS frontend - this is trivial - Via HTTP - Where is the actual endpoint / url - Which HTTP methods are support/blocked by WDQS Proxy - Is there Authentication in any way? **Acceptance Criteria:** [] Users have a documentation on how to interact with the SPARQL endpoint of a WBS Suite instance put up with WBS Deploy. This should cover all aspects mentioned on **Goal** [optional] **Notes:** - related tickets although out of the scope of this ticket: - {T192907} - {T179262} [optional] **Open Questions:** -
    • Task
    https://www.mediawiki.org/wiki/Manual:User_rights#Removing_predefined_groups >This code should be placed after any `require_once` lines that add extensions Enabling extensions like that is long deprecated, and will not work in almost all cases... It also wouldn't have the desired result either. The example after using the callback may be more valid
    • Task
    With the introduction of REST modules (T362480), there is no longer a single API spec that covers all endpoints. Instead, each component defines its own spec. For the purpose of discoverability, it seems useful to have a machine readable listing of all available modules on a wiki, including modules defined by MW core, by extensions, and potentially also modules provided by external services such as PCS. MediaWiki will have to know about this list anyway, for the benefit of T325558. There seems to be no standard for this kind of directory, so we are free to (force to) come up with a format that suites our needs.
    • Task
    ==== What to document on the extension page https://www.mediawiki.org/wiki/Extension:AbuseFilter/en [x] The new `user_unnamed_ip` variable added in {T364833} [] The new handling of privacy levels, new rights and new config added in {T363906} [] Link to temp accounts migration docs ==== What to document on the temp accounts page https://www.mediawiki.org/wiki/Trust_and_Safety_Product/Temporary_Accounts/For_developers#Updating_AbuseFilter_filters [x] The new `user_unnamed_ip` variable added in {T364833} [] The new handling of privacy levels, new rights and new config added in {T363906} [x] How to migrate filters that compare `user_name` to an IP address [] The visibility changes that will result from migrating a filter
    • Task
    {7add247e0882e1ec887e04555ad4f472cfa27028} removed `wmf-config/config` https://wikitech.wikimedia.org/wiki/Add_a_wiki still says >Create the YAML definition of the wiki in wmf-config/config, including making it inherit from relevant settings profiles, as follows:
    • Task
    * [x] get jsdoc running on latest version (jsdoc.json, package.json) * [x] add `@class` to any invisible classes * [x] remove any strings after `@class` when the variable name matches the class name * [x] search and replace `@constructor` with `@class`. JSDoc docs say they're synonyms * [] add docblocks to any invisible methods. examples: * [] mw.ApiUploadFormDataHandler.prototype.abort * [] mw.UploadWizardDetails.buildInterface() * [] fix invisible methods that have docblocks but still aren't showing up. examples: * [] $.fn.arrowSteps * [] mw.FlickrChecker.getPhotostream() * [] mw.UploadWizardDetails.attach() * [] eslint in the console, visit all the pages with docblock warnings, fix * [x] `@mixins` * [] more than one `@return` declaration * [] `@fires` * [] `@see {@link` * [] `npm run doc`, fix all those * [] `@inheritdoc` * [] unknown link * [] no contribution link found * [] figure out how to document non-classes. examples: * [] resources/mw.canvas.js * [] resources/mw.errorDialog.js * [x] check list of conversions in parent ticket. do those. examples: * [x] `@cfg` * [ ] `@inheritDoc foo` * [ ] `@property`
    • Task
    Write the access policy page for the AQS docs site URL: /documentation/access-policy Contents: - User-Agent instructions - link to terms - link to privacy policy - data licensing - rate limits - any other limitations we should call out from experience working with the dashboard - these datasets can also be downloaded via dumps.wikimedia.org/other/analytics/ Source: - https://wikimedia.org/api/rest_v1/#/
    • Task
    As part of the migration to Airflow, technical documentation about reportupdater should be archived and/or marked as deprecated, and pointers to Airflow documentation added so that readers can get to the right place. * https://wikitech.wikimedia.org/wiki/Data_Engineering/Systems/Reportupdater * https://wikitech.wikimedia.org/wiki/WMDE/Analytics/Technical_Wishes
    • Task
    As a WMF staff member who is a user of the data platform, I need to know where to get help if I have questions about publishing data, finding and using available data sources, developing a DAG, or clarifying a data modeling question. The [[ https://www.mediawiki.org/wiki/Data_Platform_Engineering/Intake_Process | formal Intake Process ]] doesn't cover the types of everyday tactical questions and advice-seeking that happen when users who are already using the platform have questions or want to get the input of other experts. The information on the [[ https://wikitech.wikimedia.org/wiki/Data_Engineering/Contact | old Data Engineering Contact Us ]] page lists various email groups and internal Slack channels where that type of information exchange happens. To enable users to get help in all the channels that are actually available to them, https://wikitech.wikimedia.org/wiki/Data_Engineering/Contact should be updated and/or integrated with https://www.mediawiki.org/wiki/Data_Platform_Engineering/Intake_Process, so that there is one doc that covers the full range of communication methods and interaction types available to data platform users.
    • Task
    The link specified in the [OO.ui.ProcessDialog description](https://gerrit.wikimedia.org/g/oojs/ui/+/master/src/dialogs/ProcessDialog.js#15) is broken due to the `[1]` referent being below the example. To do: Move [line 56](https://gerrit.wikimedia.org/g/oojs/ui/+/master/src/dialogs/ProcessDialog.js#56) directly after [line 15](https://gerrit.wikimedia.org/g/oojs/ui/+/master/src/dialogs/ProcessDialog.js#15)
    • Task
    Originally reported at https://github.com/wikimedia/grunt-stylelint/issues/50 ---- When working with filter (I use a filter to only verify staged files), stylelint throws an error when there is no file to verify. ``` eslint: { staged: { files: [ { expand: true, src:[ 'scripts/**/*.js' ], filter: function(filepath) { // do some filtering return found; } } ] } }, ``` > Warning: Running stylelint failed > Error: undefined does not match any files > at globby.then.filePaths (D:\src\uc_webclient\src\client_revision\ui\node_modules\stylelint\lib\standalone.js:128:33) > at <anonymous>:null:null > at process._tickCallback (internal/process/next_tick.js:169:7) > at Function.Module.runMain (module.js:607:11) > at startup (bootstrap_node.js:158:16) > at bootstrap_node.js:575:3 > Use --force to continue. > > Aborted due to warnings. It should just display a message like "No Files specified" (behavior from guntify-eslint) instead and not abort with an error --- @Tgr: Can be avoided with a config like stylelint: { options: { allowEmptyInput: true }, all: [ '**/*.{css,less}', ] } See stylelint/stylelint#2048. --- @Jdforrester-WMF: I'd rather not try to exhaustively copy-and-paste upstream's config options in our README, but at the same time just implicitly saying RTFM isn't very helpful. :-) Do you think this is worth calling out explicitly? ---- @Tgr: Yes, it's not very well documented (the `--help` output is the only place where it is mentioned I think).
    • Task
    https://static-codereview.wikimedia.org/ exists from {T243056}, and then moved in {T346309}. While we know 1 was the first commit... What's the highest/last commit in both repos? For MediaWiki it is 115794 - https://static-codereview.wikimedia.org/MediaWiki/115794.html For pywikipedia it is 11781 - https://phabricator.wikimedia.org/diffusion/SVNP/history/ We should also cross link to the SVN dumps available at https://dumps.wikimedia.org/other/misc/ It is potentially also worth cross linking the SVN archive in Phab: mediawiki - https://phabricator.wikimedia.org/diffusion/SVN/ pywikipedia - https://phabricator.wikimedia.org/diffusion/SVNP/ --- Changes need making over at https://gitlab.wikimedia.org/repos/sre/miscweb/static-codereview/
    • Task
    There are multiple pages of documentation that provide conceptual and reference information about the concept of a "session" and how it is handled/measured, both generally and in specific WMF data sources. These documentation pages should be combined or deduplicated, and a single source of truth page should be linked to from the related Glossary entries in DataHub. Currently, https://wikitech.wikimedia.org/wiki/Analytics/Sessions is linked to from the DataHub glossary entries, but the wiki page hasn't had a meaningful content edit since 2023, and it isn't easily discoverable from related documentation in the Data_Lake/Traffic subpages nor from the related documentation on Meta-Wiki. - https://wikitech.wikimedia.org/wiki/Analytics/Sessions - https://wikitech.wikimedia.org/wiki/Analytics/Data_Lake/Traffic/SessionLength - https://wikitech.wikimedia.org/wiki/Analytics/Data_Lake/Traffic/mobile_apps_session_metrics - https://meta.wikimedia.org/wiki/Research:Activity_session - https://meta.wikimedia.org/wiki/Research:Estimating_session_duration - DataHub glossary entry: [[ https://datahub.wikimedia.org/glossaryTerm/urn:li:glossaryTerm:0f6b8770-8db9-4eb5-b205-4225daf5bb1b/Documentation?is_lineage_mode=false | Activity Session ]] - DataHub glossary entry: [[ https://datahub.wikimedia.org/glossaryTerm/urn:li:glossaryTerm:1921bcda-850a-42b4-aa57-9c3cd093d069/Documentation?is_lineage_mode=false | Browser session ]] - T358873#9840667
    • Task
    ###Background Product teams across our organization have been implementing single page application (SPAs) tools and other pages outside of the MediaWiki domain. These pages are not influenced by skins, and their designs were freely tailored to their projects and users' needs. As a result, the interfaces of these solutions are not consistent with each other or the rest of Wikimedia core pages. Some examples of these tools are: - [[ https://en.wikipedia.org/wiki/Special:ContentTranslation#suggestions | Special:ContentTranslation ]] (Actually part of the MediaWiki domain, but overriding the default skins) - [[ https://mismatch-finder.toolforge.org/ | Wikidata Mismatch Finder ]] - [[ https://query.wikidata.org/querybuilder/?uselang=en | Wikidata Query Builder ]] - [[ https://item-quality-evaluator.toolforge.org/ | Wikidata Item Quality evaluator ]] ###Problem There's ambiguity regarding whether SPAs and other non-MediaWiki pages should conform, and to which degree, to Codex/Wikimedia design style guidelines involving layout and grid design, font styles, etc. The ambiguity increases in cases where the tools need to transition to utilizing Codex components and styles. Without a clear direction, future design efforts may continue to face challenges in deciding whether and when to maintain consistency and alignment with Wikimedia standards. ###Solution We should decide on the expected level of standardization of SPAs and document whether it is acceptable for them to maintain the current level of freedom or if, instead, these pages should adhere more closely to Codex and/or Wikimedia design style guidelines. ###Potential approaches We should evaluate the advantages and disadvantages (implications for scalability, consistency and usability) of the following options: 1. The design of non-MediaWiki pages should adhere to Codex design guidelines: We should define the necessary design requirements (layout, font styles, etc.) that these tools should follow. 2. Non-MediaWiki pages should be aligned with the rest of Wikimedia core pages (e.g. emulate the default Vector 2022 skin). 3. Maintain the current level of freedom. ###Considerations - We should evaluate which (other) key stakeholders should be involved in this decision. ###Aceptance criteria [] We have defined and documented a unified approach to designing non-MediaWiki pages
    • Task
    **Feature summary** : I would like to (I assume) use the props param on wbsearchentities. The documentation currently says: https://www.wikidata.org/w/api.php?action=help&modules=wbsearchentities props: Return these properties for each entity. Values (separate with | or alternative): url Default: url but it doesn't explain what the URL should be. The example at the bottom of the page passes the value as: https://www.wikidata.org/w/api.php?action=wbsearchentities&search=alphabet&language=en&props= which I assume is a mistake (why would you pass an empty value?) **Use case(s)** : Using wbsearchentities would be good. Or at least understanding what it does. **Benefits** : This has confused multiple people. For example on telegram: https://t.me/c/1224298920/93369 and https://t.me/c/1224298920/100604 and myself
    • Task
    Some of the toolforge repos contain outdated instructions. Now that we have adopted lima-kilo, we should remove minikube-related instructions and update accordingly.
    • Task
    • ·Closed
    **Task summary:** Revise and test all documentation in `/example`. The most recent refactor in this area and in the Docker images imply substantial changes, mostly simplifications, of what documentation we already had. Reference what is there, but be prepared that this is mostly a re-write. A draft the README document will be attached to this ticket. Whatever instructions should be manually tested and confirmed to work. Comments in `template.env` and the `docker-compose.yml` files are more up-to-date and complete but need to be carefully reviewed with whatever ends-up in the README to make they are adequately and appropriately keyed to the steps and notes in the README. **Acceptance criteria: ** * `example/README.md`, and comments in `example/template.env` and `example/docker-compose.yml` are up-to-date/accurate, adequate for guiding at least initial setup of the example, and tested. * Resulting documentation has been reviewed and approved by Dan via a PR review
    • Task
    We have a Swagger-UI interface for exploring REST APIs exposed by RESTbase: https://en.wikipedia.org/api/rest_v1/ We want to have the same ability for APIs exposed by MediaWiki core and extensions.
    • Task
    ```lang=irc [16:20] < taavi> what's up with that toolforge-push email? [16:27] < dhinus> I was also wondering. it looks like it's a pretty old github account https://github.com/toolforge-push [16:27] < bd808> It wasn't me. The "firefox" tag on it made me think it wasn't Phorge either (which is where the credentials are properly used) [16:28] < bd808> The account is used from Phorge (phabricator) to mirror repos into the toolforge GitHub org account [16:28] < bd808> https://github.com/toolforge/ [16:28] < bd808> https://github.com/toolforge/admin is an example of a repo that those credentials are used to keep updated [16:31] < bd808> The account is wired into phabricator in places like https://phabricator.wikimedia.org/source/tool-admin-web/uri/view/18249/ [16:32] < dhinus> thanks bd808, do you know of other people who interacted with that account in the past? [16:32] < bd808> just me. [16:32] < dhinus> is the password shared somewhere? [16:33] < bd808> It may be in the SRE pwstore? I can't remember if I gave it to Brooke os someone for safekeeping there [16:33] < bd808> *or someone [16:34] < bd808> I "own" the toolforge-push and composer-rate-limits-suck github accounts today [16:35] < bd808> the https://github.com/composer-ratelimits-suck account is used in Jenkins [16:38] < bd808> T242898 has some historical info related to the push account. The account and the service it facilitates are things I should have documented on wikitech. I'll make myself a task to do that. [16:38] < stashbot> T242898: Mirroring Diffusion repositories to GitHub seems to be broken - https://phabricator.wikimedia.org/T242898 ``` Semi-related things from the past: * {T242898} * {T143969}
    • Task
    We recently component guidelines to the docs, a herculean effort by our design team that migrated existing content from the DSG and involved the creation of a huge amount of new content. Now that this content has been written and included in the docs, we should review component pages for consistency and clarity of structure and language, to ensure that our users have a smooth and consistent reading experience across all components. ### Areas for review #### Component naming and casing A decision on how to handle this will be made in T361285. We are mixing casing of component names (text input vs. TextInput) and component properties (primary progressive button vs. Primary Progressive Button). This can be confusing, especially because capitalization changes the meaning of some things, and is needed to differentiate between things that have the same name, such as the Button component and the button element. #### Pluralization We sometimes mix singular and plural, such as in this example: > Avoid using buttons when: > - The action is to navigate the user to a new resource, which would take them away from the current context. In such cases, consider Link instead. Instead, we should err on the side of referring to a single component in most cases (e.g. replace "buttons" with "a Button" in the example above). The exception will be components that are usually used in groups, such as Radios or MenuItems. We should still use singular when referring to a single component usage, but may use plural when talking about using a group of components. #### Dos and don'ts We often us "dos and don'ts" on component pages to list out things you should and should not do. The design of these sections is meant to start with a "Do:" or "Don't" label, then a list of items that are assumed ot start with that word. For example: {F43691121} Sometimes, the text in the list does not follow this structure, which could be confusing. These examples should be udpated to flollow the right pattern. For example: {F43691162} In the first example, the "Do" text does not sound like it starts with the word "Do." In the second example, the "Don't" text does not follow this structure either.
    • Task
    == Background Let's settle on how we refer to components in our docs, we’re mixing them at the moment. We don’t follow any way consistently though. In a recent comment on a patch by @bmartinezcalvo, @AnneT raised a point about uppercasing only at begin of sentence for consistency. The currently worked on patch by @DTorsani-WMF goes into an also already introduced casing in a different direction. Example from current docs: - Normal buttons have three variants (“flavors”) But then we’re uppercasing also the weight/variant etc in order to separate and make clear that its describing an attribute of the component: - Use Quiet Buttons to emphasize Normal Buttons when both are combined on the same page. And the plot is getting thicker when talking about components like: - The primary action should be represented by a Primary Progressive Button. While when talking about the concept of a component, more than the component itself, we’ve lowercased again: - Reserve destructive buttons for actions that involve removal or limitation, such as deleting a page or blocking a user. Avoid using them for actions like cancel buttons. == Goal Choose one way and follow it consistently in our public docs and code comments == Open questions Which of the following options/ways to take? # Uppercasing first-letter when talking about the Codex component, and lowercasing when speaking of the general concept. E.g. “Use **Quiet Buttons** to emphasize **Normal Buttons**… cancel **buttons**”. That would be my suggestion. # Uppercasing only components, never attributes/props, e.g. “Use **quiet Buttons** to emphasizes **normal Buttons**… cancel **buttons**” # Uppercasing only beginning of a sentence, e.g. “Use **quiet buttons** to emphasizes **normal buttons**… cancel **buttons**” Please note, that - uppercasing results in a different pronunciation in screen readers, helping them to understand the component concept. - there’s research has shown that uppercasing helps increase readability, an insightful SO thread
    • Task
    == Background For marketing reasons and information architecture clarity it seems useful to add a subdomain codex.wikimedia.org for our design system #codex. The current content on https://doc.wikimedia.org/codex/ is highly disturbing, it’s only understandable for tech-savvy folks. On the other hand, https://doc.wikimedia.org/codex/latest is not crystal clear/any more self-explaining as virtual root of the Codex docs either. === Open questions # Evaluate design.wikimedia.org/codex as alternative to codex.wikimedia.org # Should this forward to https://doc.wikimedia.org/codex/latest/ or be self-contained? == Goal Add codex.wikimedia.org
    • Task
    ```lang=php /** * Controls whether stderr should be included in stdout, including errors * from wrappers. Default: don't include. * * @param bool $includeStderr * @return $this */ public function includeStderr( bool $includeStderr = true ) { $this->includeStderr = $includeStderr; return $this; } ``` Should the docs be fixed, or the default inverted?
    • Task
    ```lang=php /** * Executes command. Afterwards, getExitCode() and getOutput() can be used to access execution * results. * * @return UnboxedResult * @throws Exception */ public function execute(): UnboxedResult { ``` https://github.com/search?q=repo%3Awikimedia%2Fmediawiki-libs-Shellbox+getExitCode&type=code exists, but https://github.com/search?q=repo%3Awikimedia%2Fmediawiki-libs-Shellbox%20getOutput&type=code doesn't. Is `getOutput()` supposed to be `getStdout()` and/or `getStderr()`?
    • Task
    As part of {T349039} and setting up JSDoc for the CommunityConfiguration extension, look into how we can document Vue components using JSDoc. - Code example: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/CommunityConfiguration/+/fc65d70a0af2109969975759342a21e091bdefa5/resources/ext.communityConfiguration.Editor/lib/json-form/controls-codex/src/mediawiki/MultiPageTitleControl.vue - Goal: Generate at least the props and events tables, similar to https://doc.wikimedia.org/GrowthExperiments/master/js/frontend/demos/onboarding-dialog.html
    • Task
    # Overview We added new color tokens to Codex for night mode (T358032). Let's include these colors in the docs https://doc.wikimedia.org/codex/latest/style-guide/colors.html ## Acceptance Criteria For each color that is added to the docs: - [] Confirm with designers the WCAG conformance level (AA, AAA) - [] Confirm the HSB (Hue, Saturation, and Brightness) - [] Add the agreed on colors to the doc
    • Task
    # Overview Due to changes in the codebase [insert tasks], we can update the documentation of Pixel (VRT) and maybe PatchDemo since it no longer uses the extension VueTest. Docs to update: - https://www.mediawiki.org/wiki/Design_System_Team/Codex_Manual_Testing_Guidelines - https://www.mediawiki.org/wiki/Design_System_Team/Test_environments#MediaWiki_integrations ## Acceptance criteria - [ ]
    • Task
    In T358790 we added a section to the [[ https://doc.wikimedia.org/codex/main/style-guide/constructing-forms.html | form building guidelines ]] to explain the difference between `readonly` and `disabled` states for TextInput and TextArea. The following were some improvements suggested as follow up to that task: [] This should be its own section (h2) so that it shows up in the "On this page" navigation. [] Link to the TextInput and TextArea component pages from within this section. [] Link to this section from the Interaction States sections in TextInput and TextArea components pages.
    • Task
    The "Hosting a model" instructions on [[ https://wikitech.wikimedia.org/wiki/Machine_Learning/LiftWing#Hosting_a_model | this page ]] do not mention any requirements for licensing of the code or requirements for the open source nature of the code. This task is to consider adding those requirements to the deployment documentation. Bonus task: Add a link for the hosting a model documentation to the ML team homepage
    • Task
    ## Background We need to update the [[ https://www.mediawiki.org/wiki/Design_System_Team/Design_System_Governance_Model#Model_Flowchart | Governance Model ]] to represent the flows when product teams design/implement custom components exclusive for their projects, which won't be part of Codex components. While the DST focus remains on supporting the creation of new Codex components, these custom components will use the Codex guidelines anyway. These custom components might: 1. Be created as custom components in that project and not be reused more. 2. Be created as a custom component in that project and then be reused in other projects (in this case, we will need to decide if they can be included as Codex components). ### Governance model | Updated governance model | ### Open questions [] Given that these custom components must follow to Codex guidelines, even though they won't be implemented as Codex components but rather as custom components within individual product projects, should we document this creation process on the [[ https://doc.wikimedia.org/codex/main/contributing/overview.html | Codex site ]]? ### Acceptance criteria (or Done) [] Update the governance model including the flows commented above [] Validate the governance model with the DST [] Update the governance model and steps in [[ https://www.mediawiki.org/wiki/Design_System_Team/Design_System_Governance_Model#Model_Flowchart | Mediawiki ]]
    • Task
    == Background **Steps to replicate the issue** (include links if applicable): * Visit a page on the docs site that has a sidebar menu (example) on mobile * Click the "Menu" button on the left **What happens?**: The sidebar menu overlaps with the header menu: {F41830542 width=full} == Goal {F41830546 width=full}
    • Task
    As a user I want to have access to the following information on the dashboard: [] List and number of Phabricator tasks that mention the page [] General page information, page categories, incoming and outgoing links (only for individual pages), numbers of incoming and outgoing links (aggregated for the entire page pile). So that I can reason about the quality of pages and collections
    • Task
    Integrate dashboard's localization mechanisms with translatewiki.net
    • Task
    Placeholder for features to be implemented after the MVP
    • Task
    The page https://wikitech.wikimedia.org/wiki/Analytics/Geoeditors is hard to find and its status as a subpage of "Analytics" doesn't align to the current and evolving structure of the Data Platform docs. Its content should be integrated into docs that are more current and better integrated into the existing page structure. A subject matter expert from the Data Platform group (or someone else with the appropriate expertise) should: [] Review https://wikitech.wikimedia.org/wiki/Analytics/Geoeditors [] Move any content that is still correct and relevant into EITHER: https://wikitech.wikimedia.org/wiki/Analytics/Data_Lake/Edits/Geoeditors (if the info is relevant for consumers of the data) OR a subsection (or subpage) of https://wikitech.wikimedia.org/wiki/Analytics/Systems/Cluster (if the info is relevant for producers/maintainers of the data) [] Add the {{Archive}} template to https://wikitech.wikimedia.org/wiki/Analytics/Geoeditors
    • Task
    Right now, the only source of dataset documentation for the analytics clickstream dataset is https://meta.wikimedia.org/wiki/Research:Wikipedia_clickstream. The page at https://dumps.wikimedia.org/other/clickstream/readme.html points to that Meta page, and to a Figshare page that seems outdated: https://figshare.com/articles/dataset/Wikipedia_Clickstream/1305770. The Meta page links to https://github.com/ewulczyn/wiki-clickstream which has no additional documentation and also appears outdated. To make it clear that this is a maintained and current data source, the dataset documentation should be extracted from the historical record of the Research project that created it. It should be discoverable along with [[ https://wikitech.wikimedia.org/wiki/Analytics/Data_Lake/Traffic | similar analytics dataset documentation ]], which currently is on Wikitech.
    • Task
    **Steps to replicate the issue** (include links if applicable): * go to the official WikibaseLexeme code documentation on doc.wikimedia.org: https://doc.wikimedia.org/WikibaseLexeme/master/php/ * Click on "Topics" in the left sidebar **What happens?**: * The url of the page opened is https://doc.wikimedia.org/WikibaseLexeme/master/php/md_docs_2topics_2index.html (note the two "2"s) * the links to subpages are broken **What should have happened instead?**: * The url should have been https://doc.wikimedia.org/WikibaseLexeme/master/php/md_docs_topics_index.html (no "2"s) * the links should work **Software version** (skip for WMF-hosted wikis like Wikipedia): Based on the existing docs, it uses Doxygen 1.9.8 **Other information** (browser name/version, screenshots, etc.): * Locally, it works as expected with Doxygen 1.9.**4** * However, tests with Doxygen 1.10.0 also show the error, so it might be harder to fix * It is still not clear if that is a #upstream Doxygen bug, or an issue with Wikibase Lexeme * it seems to run the doxygen executable without extra arguments, based on https://gerrit.wikimedia.org/g/integration/config/+/69a52467c2f5b2b75a257c88da6842fcfee75622/dockerfiles/doxygen/run.sh * In particular, this means that all the links to our official documentation for WikibaseLexeme Lua are now broken everywhere (because https://doc.wikimedia.org/WikibaseLexeme/master/php/md_docs_topics_lua.html is the canonical link in all the on-wiki documentation, announcement emails, etc. Changing that to https://doc.wikimedia.org/WikibaseLexeme/master/php/md_docs_2topics_2lua.html will just mean further breakage once that bug is fixed.) * This makes it significantly harder to share that documentation with the respective communities, because either we have to share a broken link or a soon-to-be-broken link
    • Task
    ===== Background There is a lack of data for the following dates: 2019.3, 2019.4 and 2019.5 when using the "all-days" value as "day" in mediarequest_top_files dataset (media-analytics service). For instance: `https://wikimedia.org/api/rest_v1/metrics/mediarequests/top/all-referers/all-media-types/2019/03/all-days` ===== Goal I would say that the goal should be, at least, to document somewhere this lack of data to inform consumers about it. There is a plan to create some documentation for consumers and it would be a good place to include this. But maybe it's something we should discuss first. ===== AC [] This lack of data is documented [] Anything else?
    • Task
    README File etc. No idea what is available, or not available, and in which state
    • Task
    == Background With updated VitePress in {T352587} the software features a number of new vars, that are not covered by DST design decisions yet: ```lang=css --vp-code-block-color: rgba( 255, 255, 245, 0.86 ); --vp-code-block-bg: #292b30; --vp-code-block-divider-color: #000; --vp-code-color: var( --color-emphasized ); --vp-code-lang-color: rgba( 235, 235, 245, 0.38 ); --vp-code-tab-text-color: rgba( 235, 235, 245, 0.6 ); --vp-code-tab-hover-text-color: rgba( 255, 255, 245, 0.86 ); --vp-code-tab-active-text-color: rgba( 255, 255, 245, 0.86 ); ``` {F41663479 width=50%} {F41663483 width=50%} == Goal Ensure that all code interface parts on the Codex documentation site are using design system colors.
    • Task
    The support channels are getting questions about why some of their templates for thumbnails are breaking. This is because they copy examples from Wikipedia, which still rely on tright etc. On wikipedia, this works because the styles for the old thumbnails are still included. This is being done by `wgUseLegacyMediaStyles` it seems. This configuration setting defaults to false, but is undocumented on Mediawiki.org and thus not discoverable for most people. The setting also isn't mentioned in any of the release notes as far as I could quickly determine. We should rectify this.
    • Task
    Recordings have been added alongside Upload Batches as "key concepts" of Lingua Libre, but they currently lack a resource sheet that showcases their usecases, database model, and any other properties that could be useful to know for onboarding developers on the project. Examples of Resource Sheets: - [[ https://gitlab.wikimedia.org/repos/wikimedia-france/lingua-libre/lingua-libre/-/blob/main/doc/LOCUTORS.md?ref_type=heads | Locutors ]] - [[ https://gitlab.wikimedia.org/repos/wikimedia-france/lingua-libre/lingua-libre/-/blob/main/doc/UPLOAD_BATCHES.md?ref_type=heads | Upload Batches ]]
    • Task
    The RecordWizard is divided into "Steps". Each one of them is developed as a Vue SFC and located in the [[ https://gitlab.wikimedia.org/repos/wikimedia-france/lingua-libre/lingua-libre/-/tree/main/front-end/src/views/record-wizard?ref_type=heads | views/record-wizard ]] folder. We must document what these steps are, and for each one: - what they do - which conditions the user must fulfill to be able to go to the next one (see when they emit `canGoToNextStep` or `canNotGoToNextStep`) - what should happen if the user comes back to it (?) - which API calls they use (?) Additionally, we should also document how to create and implement a new Step. Examples of Resource Sheets: - [[ https://gitlab.wikimedia.org/repos/wikimedia-france/lingua-libre/lingua-libre/-/blob/main/doc/LOCUTORS.md?ref_type=heads | Locutors ]] - [[ https://gitlab.wikimedia.org/repos/wikimedia-france/lingua-libre/lingua-libre/-/blob/main/doc/UPLOAD_BATCHES.md?ref_type=heads | Upload Batches ]]
    • Task
    https://www.mediawiki.org/wiki/Manual:Edit_token has a notice at the top of the page that says "The information on this page needs to be verified by a developer." Based on a cursory review of the revision history, this page's content has likely not been updated in awhile, so it may need more than just a review by a developer...but that would be a good place to start. As is, the notice at the top makes the page appear unreliable and untrustworthy. Along with a some manual and extension pages, many MediaWiki API pages [[ https://www.mediawiki.org/w/index.php?title=Special:WhatLinksHere/Manual:Edit_token&limit=50&offset=104%7C44708&dir=prev | link to this page ]], including: - API:Edit ‎ - API:Rollback ‎ - API:Protect - API:Undelete - API:Block - API:Move ‎ - API:Upload - API:Watch - API:SetPageLanguage ‎ - API:Options
    • Task
    Anomie made a comment in T241946#5777938 about the minimum standardization level that he tried to make CSS sanitizer follow: > It appears that prefers-color-scheme is only at the Editor's Draft stage. Ideally we like to wait for at least a Working Draft if not a Candidate Recommendation. I would like to see this (or any other expectation with consensus - I have a preference toward some version of CR) formalized in the [[https://gerrit.wikimedia.org/r/plugins/gitiles/css-sanitizer/+/refs/heads/master/README.md | library README]]. That way I can stop pointing to thin air/that comment when I leave comments about this concern on specific requests for support of some CSS and just say "here's what WMF has said about the patches it will accept into the codebase". For reference, the [[https://www.w3.org/2023/Process-20231103/#rec-track | recommendation track]] is currently: 1. Publication of the First Public Working Draft. 2. Publication of zero or more revised Working Drafts. 3. Publication of one or more Candidate Recommendations. 4. Publication of a Proposed Recommendation. 5. Publication as a W3C Recommendation. This task should be taken to be orthogonal to {T162379} (i.e. strictly about standardization level for draft standards properties) and any change to the README worded as such.
    • Task
    So we know when can eventually drop them...
    • Task
    We don't need to test the PHP serialization any more, and we don't need to test versions as far back as 1.35. Just "the last version" and "the next version" should be sufficient.
    • Task
    ### Background This task covers adding a search input that filters items on the All Icons page. It does not cover changing the display of the icons on that page. See the parent task for design specs. ### Implementation details - For the input, we could use the IconLookup component, which is part of the `codex-docs` package already. Having autocomplete suggestions would be really helpful. - Should the icons be filtered as the user types, or only when they select an item in the Lookup? --- ### Acceptance criteria - [] An input is added to the All Icons page that allows a user to type in the name of an icon and select an option - [] The icon table updates to only display the selected option (unless we decide that we want to filter the icons as the user types)
    • Task
    ## Background At the moment there are 2 different type of [[ https://doc.wikimedia.org/codex/main/components/demos/card.html#demos | Cards ]] in Codex: - Non-interactive: they just provide `default` state - Interactive: they provide different states (default, hover, focus/active) *Loading state will apply for both non-interactive and interactive cards. We need to indicate this in the interaction states in both [[ https://doc.wikimedia.org/codex/main/components/demos/card.html#interaction-states | Card's guidelines ]] and [[ https://www.figma.com/file/KoDuJMadWBXtsOtzGS4134/%E2%9D%96-Codex-components?type=design&node-id=6842-69713&mode=design&t=GaViVDcgpSuiur6A-11 | Figma spec ]]. ### Documentation | [[ https://docs.google.com/document/d/1ijapYGCW_0MP3PT5A6DyDooUtcq_ndp4gbK1-A3io7k/edit?disco=AAAA9_t1t4w | Google doc with info updated ]] | ### Open questions // Add here the questions to be answered in order to design and implement the component // ### Acceptance criteria (or Done) **Design** [x] Update the interaction states in both: [x] [[ https://www.figma.com/file/KoDuJMadWBXtsOtzGS4134/%E2%9D%96-Codex-components?type=design&node-id=6842-69713&mode=design&t=GaViVDcgpSuiur6A-11 | Figma spec ]] in the library [x] Component's guidelines in the [[ https://docs.google.com/document/d/1ijapYGCW_0MP3PT5A6DyDooUtcq_ndp4gbK1-A3io7k/edit?disco=AAAA9_t1t4w | Google doc ]] **Code** [] Update the Card component's guidelines in Codex including the info added in in the [[ https://docs.google.com/document/d/1ijapYGCW_0MP3PT5A6DyDooUtcq_ndp4gbK1-A3io7k/edit?disco=AAAA9_t1t4w | Google doc ]]
    • Task
    Here's a random example: ``` includes/Output/IframeSandbox.php:240 SecurityCheck-DoubleEscaped Calling method \MediaWiki\Html\Html::element() in \MediaWiki\Output\IframeSandbox::getHtml that outputs using tainted argument #2. (Caused by: includes/Html/Html.php +264) (Caused by: includes/Output/OutputPage.php +2988; includes/Output/OutputPage.php +2974; includes/Output/OutputPage.php +2973) ``` I can't for the life of me tell what Phan thinks is being double-escaped here. The code snippet is ```lang=php public function getHtml(): string { return Html::element( 'iframe', [ // bunch of attributes ] ); } ``` Is "argument #2" 1-based or 0-based? Is it even claiming that the double-escaping happens in argument #2, or is that only mentioned in passing? Does "outputs using tainted argument" refer to `Html::element` or `IframeSandbox::getHtml`? (I guess the former because the other doesn't have arguments, but the phrasing is ambiguous.) What are the two "Caused by" remarks trying to say? Now imagine a new developer (who is unfamiliar with Phan and with MediaWiki) having to interpret this error message. Some ideas of how it could be improved: * Say what's going on, do not rely on the error code. An error message can't be too verbose of course, but it can include a short URL to a wiki page which explains what this type of error is about. * Use something more understandable instead of "tainted". (What does it even mean in this context? That it's unsafe input? That it's already escaped?) * Be clear about 0-based vs. 1-based indexes. * If the parent method (`IframeSandbox::getHtml` in this case) is only mentioned to orient the reader to where this is happening , and isn't related to the actual problem, move it to the error prefix (after the filename / line number). * Instead of "Caused by", say something like "Call stack for method1", "Call stack for method 2". Also if the call stack can include method names, that would make it more convenient to follow.
    • Task
    There are (as far as I can tell, haven't done thorough research yet) no docs about how much Harbor quota each tool has, if the quota is per-image, per-tool or both, if there is a process to get more, etc. In addition, trying to push an image larger than the quota results in an unhelpful raw 413 error.
    • Task
    Sample app that can be used for the tutorial here: https://github.com/blancadesal/flask-vue
    • Task
    ## Overview Based on the design review feedback of [Apps guidelines](https://doc.wikimedia.org/codex/main/style-guide/wikipedia-apps.html), here are some ways to improve this page: - Add a `border` and `border-radius` around the images (mainly images that are screenshots) to create a distinction between an image with a white background and the content body's white background. - When the elements are vertically stacked in mobile view (breakpoints smaller than 640px), some of these images are very tall (ie. KaiOS images) and exceed the viewport height. We can discuss ways to create a better user experience. For example, allowing the grid to display on mobile view. Mobile view {F41472262} ### Open questions //Please add questions here// ### Possible solutions //Please add solutions here// #### Option 1: Allow the grid to display on mobile view. Examples: iPhone SE {F41472106} iPhone 12 Pro {F41472107} #### Option 2: Set a max-height on images. ### Acceptance Criteria - [] Add a `border` and `border-radius` around the appropriate PNG images (screenshots) that have a white background - [] `border` of ? - [] `border-radius` of ? - [] Discuss with the team a solution to display tall images in mobile view - [] An engineer will implement the agreed solution
    • Task
    # Overview The [[ https://doc.wikimedia.org/codex/main/composables/overview.html | Codex composable documentation ]] includes a list of the exported composables that are useful for Codex users. Here are ways we can improve the documentation. **Purpose**: Continuous improvement. ### Questions 1. Should we consider adding links to the composable docs when mentioned in contributing code docs? For example: - https://doc.wikimedia.org/codex/main/contributing/contributing-code/developing-components.html#direction-specific-behavior-in-components ### Acceptance Criteria - [] Update the `import` path of `useFloatingMenu` in this [[ https://doc.wikimedia.org/codex/main/composables/demos/use-floating-menu.html#full-example | example ]]. The path is incorrect and should reflect that the composable is being exported from `lib`. Therefore, the composable should be imported from `'@wikimedia/codex'`. - [] In this [[ https://doc.wikimedia.org/codex/main/composables/demos/use-computed-language.html#full-example | example ]], remove the `div` that has the `lang` attribute set on it so that the composable can actually do its work (see [[ https://gerrit.wikimedia.org/r/c/design/codex/+/961479/comments/b8d55162_6c52312e | comment ]]). - [] Add links to components mentioned in the composable docs
    • Task
    Probably could use a full review, but the specific pain point that led to the creation of this task was the vague nature of https://www.mediawiki.org/wiki/OAuth/For_Developers#Authorisation_2 There should be: * a clearer explanation of what to do; * a link to proper API docs for the `oauth2/authorize` and `oauth/access_token` endpoints, with all (required and optional) parameters explained * a link to some actual examples, either URLs or something simple like `curl` Also maybe move public clients to a separate section?
    • Task
    # Overview Several Codex components can be wrapped by [[ https://doc.wikimedia.org/codex/main/components/demos/field.html | Field ]] because they are form input types or form elements. Let's demonstrate how to display the error status in these components within a Field. Using the Field component, Field will pass the error `status` prop set on Field to its children components. ### Questions 1. What components should we consider adding an error-handling demo using Field? | **Codex Component** | **Has a demo using Field?** | ** Consider adding an error-handling demo using Field?** | Checkbox | No | Yes | Combobox | Yes | Not needed - component doesn't have an error state | Lookup | Yes | Not needed - component doesn't have an error state | Radio | Yes | Not needed - component doesn't have an error state | SearchInput | Yes | Not needed - component doesn't have an error state | Select | Yes | Yes | TextArea | Yes | Yes | TextInput | Yes | Yes | ToggleSwitch | Yes | Not needed - component doesn't have an error state ### Acceptance Criteria - [] Add demos to the following component's demo page displaying error handling using Field - [] Checkbox - [] Select - [] TextArea - [] TextInput
    • Task
    This ticket involves the work with expanding [Help:Edit check](https://www.mediawiki.org/wiki/Help:Edit_check) so that it equips volunteers with the information they need to understand Edit check. === Stories - As someone who is reviewing edits and happens upon an edit tag I don't recognize (`editcheck-references-activated`) - As someone who is hearing about the Edit Check project for the first time WARNING: @ppelberg to finish drafting the stories above
    • Task
    We should probably create a page (maybe at [[ https://meta.wikimedia.org/wiki/Community_Tech/API_keys | Community Tech/API keys ]]?) which details: - the API keys which are available for community use (iirc only those for use with [[ https://wikitech.wikimedia.org/wiki/Nova_Resource:Google-api-proxy | google-api-proxy ]]?) - which tools (and their maintainers) have access to the key - how to request access to the key
    • Task
    ## Background The [[ https://doc.wikimedia.org/codex/main/components/demos/tabs.html#:~:text=tabs%20have%20a-,Gray200,-background%2C%20with%20the | components guidelines in Codex ]] were documented using the option token's name (e.g. `Gray200`) instead the decision one (e.g. `background-color-disabled-subtle`). After reviewing this within the DST we decided to use the decision token's name and provide a way to link directly to the token where more information about the underlying color can be found. We will need to update the component guidelines to use decision tokens and link them to the associated token documentation. ### Documentation | [[ https://docs.google.com/document/d/1ijapYGCW_0MP3PT5A6DyDooUtcq_ndp4gbK1-A3io7k/edit#heading=h.44j4hicgxpd3 | Google doc with the components guidelines ]] | ### Acceptance criteria **Design** [] Rename color names from option tokens to decision token in the [[ https://docs.google.com/document/d/1ijapYGCW_0MP3PT5A6DyDooUtcq_ndp4gbK1-A3io7k/edit#heading=h.44j4hicgxpd3 | Google doc ]] **Code** [] Update documentation in the Codex site [] Link the decision tokens to the specific token in the demo once this task is done {T349262}
    • Task
    == Background and goal How do we want to (if at all) handle guidelines for MediaWiki (or in doubt general wiki) special interaction needs, like “Red Links”? How technology agnostic do we make the descriptions and guidance? From the [[ https://doc.wikimedia.org/codex/latest/components/mixins/link.html#types | Link guidelines ]]: > **Red links (aka new links)** > Links to pages that do not exist yet. These display the color Red600 for both the normal or underlined types.[3] > **Card** > Cards can be clickable and offer a way to navigate to the content they represent (e.g. Wikipedia articles). > **Dialog** > ![A white overlay separating a dialog from a Wikipedia page.] > … > Use of the Dialog component in features which don't rely on SSR (which includes all MediaWiki usage for now) can dispense with this. > **TypeaheadSearch** > All references to Wikipedia and Wikidata. TahS has a special position, nonetheless, or even more so we should consider it here. == Acceptance criteria [] Identify the best possible way to go forward for Codex, as design system for Wikimedia on wiki agnosticism question [] Update guidelines accordingly of outcome, by expanding or contracting them
    • Task
    From {T347313}. Initial attempts to solve this on Figma export were unsuccessful. In the image in the [[ https://doc.wikimedia.org/codex/main/components/demos/tabs.html#interaction-states | Tabs > Interaction states ]] section, the lines within the Tabs component should be 1px for the gray one and 2px for the blue one.
    • Task
    ## Background This task collects possible improvements to the component guidelines in [[ https://doc.wikimedia.org/codex/latest/ | Codex ]]. **High impact:** - Review the content in each component's demo page and make sure the information is not duplicated in the Guidelines and Demos sections - The link to the Figma spec sheet in each "Specifications" section is a bit hidden ([[ https://doc.wikimedia.org/codex/latest/components/demos/button.html#specifications | an example ]]). We could emphasize it. - [[ https://doc.wikimedia.org/codex/latest/components/demos/button.html#progressive-button | Button > Content > Progressive button ]]: the current example is wrong ("Discover more articles") since Buttons are not used for navigating content but for actions instead. We should rename this using actions instead (e.g. "Accept"). - Card: in the "[[ https://doc.wikimedia.org/codex/latest/components/demos/card.html#interaction-states | Interaction states ]]" section just the `with link` version is currently represented. We need to represent both `default` and `with link` cards. - Combobox: - The images in the "Specifications" is wrong since the menu displayed needs to be the same width as the input. Update image with this new one [[ https://drive.google.com/file/d/1RwDfw9B6QsZbhERZ-c2Pk3Y77ZjNtnPp/view?usp=sharing | combobox-specifications.svg ]] - The "No results" state is missing in the "Interaction states". So we need to update the image [[ https://drive.google.com/file/d/1kO7f0mkpiWEoaEtW-vUFivRPV0iP1EGw/view?usp=sharing | combobox-interaction-states.svg ]] and its text description and alt text (updated them in the [[ https://docs.google.com/document/d/1ijapYGCW_0MP3PT5A6DyDooUtcq_ndp4gbK1-A3io7k/edit | doc ]]). - Link: we refer to the blue link as "Default link" in the component's guidelines while we refer to "Standard link" in the demos. We need to unify its name. - Lookup: the "No results" state is missing. So we need to update the image [[ https://drive.google.com/file/d/1pqSEKzN6AqU6erhKZwbSKDqn_hPjpsnD/view?usp=sharing | lookup-interaction-states.svg ]] and its text description and alt text (updated them in the [[ https://docs.google.com/document/d/1ijapYGCW_0MP3PT5A6DyDooUtcq_ndp4gbK1-A3io7k/edit | doc ]]). - Menu: menu orientation upward is not represented in the component's guidelines. We need to include both downward and upward orientations. - ~~Progress bar: elevated image asset is slightly misleading with the very hard to recognize scaled-down size~~ {F41695285} - ~~Radio: There is an erratum in the [[ https://doc.wikimedia.org/codex/latest/components/demos/radio.html#specifications:~:text=to%20ensure%20consistency-,withthe%20body%20text,-.%20It%20can%20also | Specifications > Label ]] text (missing space in "withthe")~~ - [[ https://doc.wikimedia.org/codex/main/components/demos/tab.html#content | Tab > Content ]]: we need to update the Do and Don't images since the lines below the selected tabs are wrong. Also, this content recommendations could fit better within the Tabs component instead, since "Tab" is just for the tab items. - ToggleButton: include the "Content" section to explain about how to write content for these Toggle Buttons (as we do with Button component). //"Use short, precise verbs, ideally with fewer than 38 characters for English. The average character length of language translations is 42 characters."// - {T355415} - {T357429} - {T359647} **Medium impact:** - Color's documentation: decide if we want to use the option token's name (e.g. `Gray200`) or the decision one (e.g. `background-color-disabled-subtle`)~~ To be discussed in a future DST Design/Eng sync instead of creating a task - Evaluate if we want to remove the "Interaction states" section from the guidelines - Evaluate if we want to rename the "Specifications" section to "Anatomy" - Ensure that we only use DS components in our imagery. We currently feature buttons (and illustrations) that are not part of our DS {F41693817} **Low impact:** - References section: just the components moved from the DSG contain a "References" section. We need to review the [[ https://docs.google.com/document/d/1ijapYGCW_0MP3PT5A6DyDooUtcq_ndp4gbK1-A3io7k/edit#heading=h.uteb407jne6h | new Codex components ]] list and include references when needed - Also decide where to put the References, if we continue with it. Right now it's hanging in the air underneath Guidelines, where the more natural expectation would be to have it end of page. - If References, then add direct link references, not links to the heading. For satisfying UX and a11y needs: See https://gerrit.wikimedia.org/r/c/design/codex/+/959603/14/packages/codex-docs/component-demos/button/button.md for example. We put in a enumerated list of Reference ids, otherwise the link is no semantic connection. We can leave this for post MVP. - We could improve the component's guidelines by adding: - {T357714} - {T311671} --- ### Acceptance criteria [] Evaluate each one of the items in the list above and create subtasks if needed [] Update the components guidelines in Codex
    • Task
    As of yesterday, October 6 2023, the tideways_xhprof PHP extension [[https://github.com/tideways/php-xhprof-extension/commit/767fcd7f6a09954a77f48321ea3c7078de694c9b | has been archived ]]. The suggested replacement is the "classic" xhprof extension, which has been made compatible with PHP 7 (and then 8) a few years ago. Even though we primarily use Excimer nowadays (TTBOMK), MW still supports tideways_xhprof and uses it in a bunch of places. Some of them, like [[https://gerrit.wikimedia.org/g/mediawiki/core/+/c80a8d36529d2e86ea95f0e85cd63148714be3dd/includes/profiler/ProfilerXhprof.php | ProfilerXhprof.php]], already support both xhprof and tideways_xhprof, so for them this is just a matter of removing the latter. In places where we currently install tideways_xhprof (e.g., CI, vagrant), we should replace that with xhprof. - [[https://codesearch.wmcloud.org/search/?q=tideways&files=&excludeFiles=&repos= | Codesearch for "tideways" ]] - [[https://www.mediawiki.org/w/index.php?search=tideways&title=Special%3ASearch&profile=advanced&fulltext=1&ns0=1&ns1=1&ns2=1&ns3=1&ns4=1&ns5=1&ns7=1&ns8=1&ns9=1&ns10=1&ns11=1&ns12=1&ns13=1&ns14=1&ns15=1&ns90=1&ns91=1&ns92=1&ns93=1&ns100=1&ns101=1&ns102=1&ns103=1&ns104=1&ns105=1&ns106=1&ns107=1&ns486=1&ns487=1&ns710=1&ns711=1&ns828=1&ns829=1&ns1198=1&ns1199=1&ns2300=1&ns2301=1&ns2302=1&ns2303=1&ns5500=1&ns5501=1 | Pages mentioning tideways on mw.org]] - [[https://wikitech.wikimedia.org/w/index.php?search=tideways+-intitle%3A%22Server+admin+log%22&title=Special:Search&profile=advanced&fulltext=1&ns0=1&ns1=1&ns2=1&ns3=1&ns4=1&ns5=1&ns7=1&ns8=1&ns9=1&ns10=1&ns11=1&ns12=1&ns13=1&ns14=1&ns15=1&ns110=1&ns111=1&ns112=1&ns113=1&ns116=1&ns117=1&ns498=1&ns499=1&ns666=1&ns667=1&ns828=1&ns829=1&ns2300=1&ns2301=1&ns2302=1&ns2303=1 | Pages to update on wikitech ]]
    • Task
    I just realised by chance that we now have a [[https://gerrit.wikimedia.org/g/mediawiki/core/+/b1725d9a13d99d7cb6b538bf3779258b93fffdd6/includes/htmlform/CodexHTMLForm.php | CodexHTMLForm]]. However, it is not documented in https://www.mediawiki.org/wiki/HTMLForm or any other place that I could think of. I was curious to see how it works in practice, so I tried it in a few places, but it looks like it might be a WIP, given that some fields look incomplete/partially styled. It would be nice to have documentation and a task to follow the progress.
    • Task
    As part of T341364, I created some [[ https://wikitech.wikimedia.org/wiki/Category:Documentation | Documentation subcategories on Wikitech ]] to help with navigation, search, and aligning the content to [[ https://www.mediawiki.org/wiki/Documentation/Toolkit#Use_templates_to_create_documentation | standard templates ]]. I wasn't able to review and apply categories to all the [[ https://wikitech.wikimedia.org/wiki/Help:Cloud_VPS | Cloud VPS ]] docs, so I'm filing this task for anyone who wants to pick it up. Suggested work is: 1) Review each of the pages linked in the [[https://wikitech.wikimedia.org/wiki/Template:Cloud_VPS_nav | Cloud VPS navigation menu ]]. 2) Try to identify if the page aligns with a standard doc type, as defined [[ https://www.mediawiki.org/wiki/Documentation/Toolkit#Use_templates_to_create_documentation | here. ]] For example, if it is primarily a [[ https://wikitech.wikimedia.org/wiki/Category:How-to-guide | how-to guide ]], add that category to the page. ([[ https://en.wikipedia.org/wiki/Help:Category#Summary | Here are instructions for how to add categories to pages ]]). It's very likely that these pages are a mix of different types of content, and don't align clearly with one doc type or another. This is still useful information. You can tag docs as more than one doc type, and that will help people know that the page probably needs some work to clarify its purpose and make sure it achieves its goals.
    • Task
    As part of T341364, I created some [[ https://wikitech.wikimedia.org/wiki/Category:Documentation | Documentation subcategories on Wikitech ]] to help with navigation, search, and aligning the content to [[ https://www.mediawiki.org/wiki/Documentation/Toolkit#Use_templates_to_create_documentation | standard templates ]]. I wasn't able to review and apply categories to all the Toolforge docs, so I'm filing this task for anyone who wants to pick it up. Suggested work is: 1) Review each of the pages linked in the [[ https://wikitech.wikimedia.org/wiki/Template:Toolforge_nav | Toolforge navigation menu ]]. 2) Try to identify if the page aligns with a standard doc type, as defined [[ https://www.mediawiki.org/wiki/Documentation/Toolkit#Use_templates_to_create_documentation | here. ]] For example, if it is primarily a [[ https://wikitech.wikimedia.org/wiki/Category:How-to-guide | how-to guide ]], add that category to the page. ([[ https://en.wikipedia.org/wiki/Help:Category#Summary | Here are instructions for how to add categories to pages ]]). It's very likely that these pages are a mix of different types of content, and don't align clearly with one doc type or another. This is still useful information. You can tag docs as more than one doc type, and that will help people know that the page probably needs some work to clarify its purpose and make sure it achieves its goals.
    • Task
    https://dumps.wikimedia.org/ and https://meta.wikimedia.org/wiki/Data_dumps seem to be the primary landing pages for Dumps as a product/service. These pages could be improved to be more effective and user-friendly. Without having done an in-depth review, the major opportunities I see here are: - Choose one page/platform to serve as the landing page for dumps, and make that landing page follow best practices like providing task-based navigation, organizing content into easily-consumable units, and using progressive disclosure to guide users to more detailed information. https://meta.wikimedia.org/wiki/Data_dumps is providing links to a lot of great information, but it is overwhelming and should be audited to make sure it's linking to reliable and relevant resources. - Consolidate duplicate information scattered on multiple pages/wikis/platforms - Restructure pages and add navigation based on audience and critical user journeys / data tasks. Figure out a way to provide clear and consistent navigation between all the different places where there's dump related content, like... https://www.mediawiki.org/wiki/SQL/XML_Dumps Pages linked from https://meta.wikimedia.org/wiki/Data_dumps/More_resources https://gitlab.wikimedia.org/repos/research/html-dumps/-/blob/main/README.md Pages at https://meta.wikimedia.org/wiki/Category:Data_dumps https://wikitech.wikimedia.org/wiki/Dumps - Standardize language for how we refer to the various data sources and content of the dumps. For example, when I look at https://meta.wikimedia.org/wiki/Data_dumps/What%27s_available_for_download I have a hard time aligning that with what I see at https://dumps.wikimedia.org/ Related docs tasks (that I'm aware of; there are likely more that I didn't yet find): {T193296} {T343146}
    • Task
    https://wikitech.wikimedia.org/wiki/Portal:Data_Services could function more effectively as a [[ https://www.mediawiki.org/wiki/Documentation/Portal_pages | portal page ]] if it was shorter and used a layout that is more navigation-focused. There may also need to be some clarification about which of the products/services linked on this page are sufficiently stand-alone to be considered products/services in their own right, vs. features of other products/services like Toolforge or Cloud VPS. Ambiguity about this makes for a confusing user experience because someone navigating from this portal page may not be expecting to be linked into the middle of the Toolforge or Cloud VPS docs when they were navigating in the context of accessing data, and may not be familiar with or be users of Toolforge/Cloud VPS. (For example, from the Wikitech main page directly to this portal page). Suggested improvements in addition to the above: * One link per section: only link to one single best page for the products/services being linked to; ideally the link should go to the product/service [[ https://www.mediawiki.org/wiki/Documentation/Landing_pages | landing page ]], not to a very detailed content page. * Reduce the amount of text to only include 1-2 sentences for basic context; all other text should be on the product/service landing page to which this page links. * Avoid linking to very detailed content pages from this portal page. As a cross-collection landing page, a portal should link to landing pages that provide a more gentle introduction to the product or service, not to content pages. * Use a layout grid or other easy-to-skim format that emphasizes the navigational purpose of the page.
    • Task
    [[https://wikitech.wikimedia.org/wiki/Help:Toolforge/Performance|Help:Toolforge/Performance]] has valuable information about troubleshooting and improving performance of web services running on Toolforge. It's written from an SRE perspective focused on performance testing scenarios and identifying improvements for each of them. Some of this type of information is in more visible Toolforge docs, but it would be good to have a single page people could visit to learn about performance improvement and pitfalls to avoid. 1) Check if information in https://wikitech.wikimedia.org/wiki/Help:Toolforge/Performance is still valid. If not, remove it. 2) Remove or relocate all information that is overly-detailed or focused on admins / SREs; refocus the page on what users would need and want to know to test their web services' performance and improve it. 3) Add section content / links to tools that are available to tool developers for monitoring their tool performance, like https://grafana.wmcloud.org/d/TJuKfnt4z/kubernetes-namespace?orgId=1 (?) Others? 4) Contextualize content in other docs by highlighting how [[ https://wikitech.wikimedia.org/wiki/Help:Toolforge/Redis_for_Toolforge | Redis ]] and other Toolforge services can help improve tool performance. 5) Add a link to this page in https://wikitech.wikimedia.org/wiki/Template:Toolforge_nav
    • Task
    As a developer using Toolforge, I shouldn't need to understand Kubernetes as a primary topic; this is backend infrastructure that the platform admins manage for me. The existence of [[ https://wikitech.wikimedia.org/wiki/Help:Toolforge/Kubernetes | this doc just about Kubernetes ]] made sense when the team was migrating from Grid Engine to k8s, but now it is problematic because information about running jobs and web services is sharded between existing docs about those topics, and the k8s doc. 1. Move content about running webservices on k8s into [[https://wikitech.wikimedia.org/wiki/Help:Toolforge/Web|Help:Toolforge/Web]]. This includes the [[https://wikitech.wikimedia.org/wiki/Help:Toolforge/Kubernetes#Kubernetes_webservices|"Kubernetes webservices"]] section and the [[https://wikitech.wikimedia.org/wiki/Help:Toolforge/Kubernetes#Container_images|"Container images"]] section, though the latter may need a cross-ref from the jobs doc if it lives primarily in the web services doc (it's unclear to me how much container images matter for jobs, if at all). 2. Move content about running jobs on k8s into [[https://wikitech.wikimedia.org/wiki/Help:Toolforge/Jobs_framework | Help:Toolforge/Jobs_framework]]. 3. Move troubleshooting content into https://wikitech.wikimedia.org/wiki/Help:Troubleshooting_Toolforge. 4. Move information about [[ https://wikitech.wikimedia.org/wiki/Help:Toolforge/Kubernetes#Namespaces | namespaces ]] into the [[ https://wikitech.wikimedia.org/wiki/Portal:Toolforge/About_Toolforge | Toolforge concepts overview ]], or include it in both the web and jobs framework docs. 5. Move information about quota and resources into a new doc: T347887 6. Any concepts or info about Kubernetes that is useful for users to know can be added to [[ https://wikitech.wikimedia.org/wiki/Portal:Toolforge/About_Toolforge#Kubernetes_cluster | the k8s section in the Toolforge overview ]]. 7. If/when https://wikitech.wikimedia.org/wiki/Help:Toolforge/Kubernetes is ready to be deprecated due to this content redistribution: there are many links throughout the Toolforge docs that should be updated -- a simple redirect won't be able to cover all the different final destinations of the content. Also, remove the link from https://wikitech.wikimedia.org/wiki/Template:Toolforge_nav.
    • Task
    As a Toolforge user or prospective user, I want to be able to quickly understand the memory and resources available to me for running my tool(s). I want to know how to monitor my tools' memory and resource usage, how and when to request a quota increase, and things I should consider before doing that. 1. Content in the following sections should be consolidated into one new document: - https://wikitech.wikimedia.org/wiki/Help:Toolforge/Kubernetes#Quotas_and_Resources - https://wikitech.wikimedia.org/wiki/Help:Toolforge/Web#Runtime_memory_limits - https://wikitech.wikimedia.org/wiki/Help:Toolforge/Web#Requesting_additional_tool_memory - https://wikitech.wikimedia.org/wiki/Help:Toolforge/Jobs_framework#Job_quotas 2. Once a new doc is created for all the above content, pieces of it that are relevant to web services or jobs framework can be transcluded into those pages, or the pages can link to the new resources doc. Only include the minimum amount of information necessary -- one goal of this work is to reduce how many times this information is duplicated across the docs. 3. The new doc should include a section that outlines the Quota Increase request process and the considerations that may cause a Toolforge user to request to use [[https://wikitech.wikimedia.org/wiki/Help:Trove_database_user_guide|Trove]]. 4. When this new doc is created, it should be linked from the following docs, replacing the current links about the topic: -- https://wikitech.wikimedia.org/wiki/Portal:Toolforge/About_Toolforge#Shared_services_and_resources -- https://wikitech.wikimedia.org/wiki/Help:Toolforge#Constraints_of_Toolforge -- Also, add a link to it in the [[ https://wikitech.wikimedia.org/wiki/Template:Toolforge_nav | Toolforge docs navigation menu ]]
    • Task
    What does permission denied mean? Permission to what? How would I go about fixing it? ``` Traceback (most recent call last): File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 699, in urlopen httplib_response = self._make_request( File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 394, in _make_request conn.request(method, url, **httplib_request_kw) File "/usr/lib/python3.10/http/client.py", line 1283, in request self._send_request(method, url, body, headers, encode_chunked) File "/usr/lib/python3.10/http/client.py", line 1329, in _send_request self.endheaders(body, encode_chunked=encode_chunked) File "/usr/lib/python3.10/http/client.py", line 1278, in endheaders self._send_output(message_body, encode_chunked=encode_chunked) File "/usr/lib/python3.10/http/client.py", line 1038, in _send_output self.send(msg) File "/usr/lib/python3.10/http/client.py", line 976, in send self.connect() File "/home/reedy/.local/lib/python3.10/site-packages/docker/transport/unixconn.py", line 30, in connect sock.connect(self.unix_socket) PermissionError: [Errno 13] Permission denied During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/local/lib/python3.10/dist-packages/requests/adapters.py", line 489, in send resp = conn.urlopen( File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 755, in urlopen retries = retries.increment( File "/usr/lib/python3/dist-packages/urllib3/util/retry.py", line 532, in increment raise six.reraise(type(error), error, _stacktrace) File "/usr/lib/python3/dist-packages/six.py", line 718, in reraise raise value.with_traceback(tb) File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 699, in urlopen httplib_response = self._make_request( File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 394, in _make_request conn.request(method, url, **httplib_request_kw) File "/usr/lib/python3.10/http/client.py", line 1283, in request self._send_request(method, url, body, headers, encode_chunked) File "/usr/lib/python3.10/http/client.py", line 1329, in _send_request self.endheaders(body, encode_chunked=encode_chunked) File "/usr/lib/python3.10/http/client.py", line 1278, in endheaders self._send_output(message_body, encode_chunked=encode_chunked) File "/usr/lib/python3.10/http/client.py", line 1038, in _send_output self.send(msg) File "/usr/lib/python3.10/http/client.py", line 976, in send self.connect() File "/home/reedy/.local/lib/python3.10/site-packages/docker/transport/unixconn.py", line 30, in connect sock.connect(self.unix_socket) urllib3.exceptions.ProtocolError: ('Connection aborted.', PermissionError(13, 'Permission denied')) During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/reedy/.local/lib/python3.10/site-packages/docker/api/client.py", line 214, in _retrieve_server_version return self.version(api_version=False)["ApiVersion"] File "/home/reedy/.local/lib/python3.10/site-packages/docker/api/daemon.py", line 181, in version return self._result(self._get(url), json=True) File "/home/reedy/.local/lib/python3.10/site-packages/docker/utils/decorators.py", line 46, in inner return f(self, *args, **kwargs) File "/home/reedy/.local/lib/python3.10/site-packages/docker/api/client.py", line 237, in _get return self.get(url, **self._set_request_timeout(kwargs)) File "/usr/local/lib/python3.10/dist-packages/requests/sessions.py", line 600, in get return self.request("GET", url, **kwargs) File "/usr/local/lib/python3.10/dist-packages/requests/sessions.py", line 587, in request resp = self.send(prep, **send_kwargs) File "/usr/local/lib/python3.10/dist-packages/requests/sessions.py", line 701, in send r = adapter.send(request, **kwargs) File "/usr/local/lib/python3.10/dist-packages/requests/adapters.py", line 547, in send raise ConnectionError(err, request=request) requests.exceptions.ConnectionError: ('Connection aborted.', PermissionError(13, 'Permission denied')) During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/reedy/.local/bin/docker-pkg", line 8, in <module> sys.exit(main()) File "/home/reedy/.local/lib/python3.10/site-packages/docker_pkg/cli.py", line 179, in main application = builder.DockerBuilder(args.directory, config, select, nocache, pull) File "/home/reedy/.local/lib/python3.10/site-packages/docker_pkg/builder.py", line 218, in __init__ self.client = docker.from_env(version="auto", timeout=600) File "/home/reedy/.local/lib/python3.10/site-packages/docker/client.py", line 96, in from_env return cls( File "/home/reedy/.local/lib/python3.10/site-packages/docker/client.py", line 45, in __init__ self.api = APIClient(*args, **kwargs) File "/home/reedy/.local/lib/python3.10/site-packages/docker/api/client.py", line 197, in __init__ self._version = self._retrieve_server_version() File "/home/reedy/.local/lib/python3.10/site-packages/docker/api/client.py", line 221, in _retrieve_server_version raise DockerException( docker.errors.DockerException: Error while fetching server API version: ('Connection aborted.', PermissionError(13, 'Permission denied')) ```
    • Task
    There is existing information in several docs about the file directory structure within Tool Accounts, file permissions, and how to work with files as a tool maintainer. I think there's enough content that this topic could have its own page, which would make the [[ https://wikitech.wikimedia.org/wiki/Help:Toolforge/Tool_Accounts | Tool Accounts page ]] a bit less overwhelming, while still grouping information together in a way that makes sense. Suggested content to move out of existing pages and into a new page: - https://wikitech.wikimedia.org/wiki/Help:Toolforge/Tool_Accounts#Manage_files_in_Toolforge - Information about per-project, private directories: https://wikitech.wikimedia.org/wiki/Help:Shared_storage#/data/scratch and other sections; with added content or formatting to make it easier to understand what is private, what is shared, and the intended uses for the directories. - Information about file permissions and related errors or pitfalls, like https://wikitech.wikimedia.org/wiki/Help:Access_to_Toolforge_instances_with_PuTTY_and_WinSCP#Troubleshooting_permissions_errors - https://wikitech.wikimedia.org/wiki/Help:Toolforge/Developing_successful_tools#Sharing_files_via_packages_or_version_control For tips and doc templates to help you get started writing a new doc, visit https://www.mediawiki.org/wiki/Documentation/Toolkit