Jump to navigation Jump to search
|Users by language|
Hello! I'm Stephen. My Phabricator, GitHub, and IRC nick is niedzielski and I'm usually on #wikimedia-mobileconnect. Welcome to my so-called wiki.
- mw:Vue.js and mw:TypeScript for MediaWiki
- EventLogging schemas and visual EventLogging debugging
- User:Niedzielski (short link)
- My Vagrant setup
- Patches dashboard
- Provenance URL query parameters for sharing and X-Analytics
- Beta Cluster EventLogging debugging
- Finish moving mw:Wikimedia_Product/Component_responsibility to mw:Developers/Maintainers.
- Revise MediaWiki Docker config. Check out Brennen's latest. Try to archive boxwiki. Also check out Monte's setup.
- Revisit the browser support matrix discussion with the latest.
- Revise SOS script to decode tags and convert to node-fetch (see recent Phab statistics script). (I also have a note to attempt to use
project.searchbut I can no longer remember what that's for.)
- Present a compelling argument as to why ESLint stylistic errors should be reduced to warnings during development (they should be errors only at commit time). Proposed patch. Aren't the PHP lints warnings (I hope)?
- Improve eventlogging.error to use toasts and update wiki.
- Add Minerva, Vector, and general unhandled error toasters and socialize.
- Taskify or revise SVGO usage to leverage thew new recursive option (context)
- Consider adding type checking to Popups or another repo. It'd be nice to get more momentum behind it. How can we share the WMDE MediaWiki Core definition and where should that live?
- Read MDN CSS Key Concepts and reread this article on CSS performance.
- Does YouTube have more educational content than Wikipedia? What can we do about that?
- Is it practical to make a codemod to translate JSDuck syntax to JSDuck (T138401)? What will the social challenges be? Just themeing concerns?
- Regardless of codemod, could we set all files for exclusion by default and gradually convert every file over to well-type JSDocs?
- What else can we use codemods to automate?
- China is partially blocked. What does that mean? Are there ways we can split the wikis to better serve noncontroversial content? Is this a branding issue? A language issue? I don't think Wikidata is blocked.
- Technical Writing Courses from Google
- Read about Stack Overflow's dark mode.
What are the big problems developing for wikis?
- What are the biggest problems bots workaround? Are they solving the problem adequately or only addressing some of the symptoms?
- Sharing templates, gadgets sucks requires file copies. What's the smallest subset of template and module sharing that could be tackled? Some kind of very niche infobox? Some presentation around a single Wikidata property? Something else? It's funny that I can access Wikidata anywhere from the database but not a template. Would it be awful to put "schema templates" in Wikidata that can be used elsewhere? What would that look like?
- Setting up MediaWiki locally with Wikibase is heavy.
- Proxying content from production wikis is challenging, fragile, not seamless, and not part of Core. This seems solveable. What would a more robust version of this look like?
- It's hard to use external code within the MediaWiki ecosystem. It's hard to use MediaWiki cost outside the MediaWiki ecosystem. Code sharing sucks.
- Gadgets can really only leverage dependencies already in ResourceLoader.
Problems to avoid
These are being worked on for two years by WMDE. They'll get it.
- Templates are hard to share across wikis, especially third-party installs. The only option currently is copy and paste by hand or by bot. There's an RFC for the Wikimedia interwiki support at least.
- Templates have TemplateStyles but there's no "TemplateSchemas" slot. Separating presentation and data (making the data accessible independent of the presentation) feels like the holy grail of templates. What can we do about it?
- Responsive / mobile support for templates usually isn't so good yet most readers our on mobile.
- This could be solved with research, documentation, and outreach. E.g., maybe some guidelines around always having a root node, using TemplateStyles instead of inline styles, etc.
- There's not great guidelines on building great templates yet many articles use templates.
- This could be solved with research and documentation.
- Search engines like Google report SEO errors on templates (there are millions on enwiki alone). The nature of templates is that a single fix has great impact yet we're not tracking and fixing these in our chores.
- What is the typical template lifecycle? How do they iterate, grow, fork, and stabilize? Is there a first-class citizenship a template can graduate into in Core? E.g., "this template is useful everywhere so we're promoting it into Core. Future changes are going to be harder since its PHP but it will be available everywhere and versioned in Git."
- What are the common presentations for templates? E.g., table, bar graph, etc. How should we optimize each for presentation on smaller screens?
- How can we mine template data like we do categories or Wikidata? How can we present it different in a service like PCS?
- Can we provide template parameter descriptions in localized form?
- How can we validate not just HTML but custom MediaWiki templates?
- Disable gadgets:
- Disable skinning:
- Disable CentralNotice banners:
- Disable QuickSurveys:
- Use Vector skin version (Latest = 2, Legacy = 1):
- User preference overriding and Dummy language codes
- Old CSS can be shipped with new HTML for up to 30mins. It must be backwards and forwards compatible so check old HTML with new CSS and new HTML with old CSS.
- Caching overview