MediaWiki

Developer Wishlist/2017/Documentation

< Developer Wishlist
Developer Wishlist 2017
Documentation

15 proposals, 86 editors, 207 votes

The voting phase has concluded. Thanks for participating!

You can view the results or discuss how to follow up.


Introduce and document a minimum rights hierarchy

Tracked in Phabricator
Task T156789

Problem

There seems to be an undocumented and inconsistent hierarchy of rights. For example, if I cannot view a page, I cannot edit it. But: if I can't edit, can I still move? In particular, the API has no concept of a hierarchy of rights. This leads to potential security issues in read protected MediaWikis.

Who would benefit

Extension developers and MediaWiki maintainers will have a more clear cut security model.

Proposed solution

We should add a minimum hierarchy in our rights, such as read > edit > other actions, similar to the way we have a hierarchy in the user groups: * > user > other groups. If one cannot read, they cannot do anything else. If one cannot edit, they cannot do any other modifications. I know this is too simplistic, so we need to sketch out a proper hierarchy. The hierarchy should also be documented.

Endorsements (T156789)

Support (T156789)

  1. ThurnerRupert (talk) 12:22, 6 February 2017 (UTC)[reply]
  2. Osnard (talk) 12:57, 6 February 2017 (UTC)[reply]
  3. [[kgh]] (talk) 23:21, 6 February 2017 (UTC)[reply]
  4. Ricordisamoa 11:28, 8 February 2017 (UTC)[reply]
  5. RichardHeigl (talk) 23:15, 9 February 2017 (UTC)[reply]
  6. Smalyshev (WMF) (talk) 02:35, 10 February 2017 (UTC)[reply]
  7. --Alexmar983 (talk) 10:51, 11 February 2017 (UTC)[reply]
  8. BSitzmann (WMF) (talk) 23:22, 11 February 2017 (UTC)[reply]
  9. Mglaser (talk) 10:26, 13 February 2017 (UTC)[reply]
  10. Martin Urbanec (talk) 18:14, 13 February 2017 (UTC)[reply]
  11. Matěj Suchánek (talk) 21:05, 13 February 2017 (UTC)[reply]

Add examples of the three security review processes

Tracked in Phabricator
Task T156757

Problem

Wikimedia Security Team/Security reviews lists three separate processes which are either recommended or required in order to get an extension deployed on Wikimedia servers.

For non-WMF developers it can be unclear what is needed for each review step and how the Security team expects the information to be presented.

Who would benefit

  • Anyone unfamiliar with the current review practices, likely meaning extension developers outside of the WMF.
  • The security team: Clearer expectations/instructions should hopefully help streamline new external review requests.

Proposed solution

Identify one or a few good real-life examples for each process (or at least the latter two) to promote as case studies.

Endorsements (T156757)

  1. There is indeed quite some confusion around security processes. I checked a few days ago and the biggest problem is IMHO that we recently got a series of redundant and poorly connected pages, which sometimes may even be slightly contradictory. See Talk:Reporting security bugs and Talk:Wikimedia Security Team. --Nemo 18:32, 14 February 2017 (UTC)[reply]

Support (T156757)

  1. ThurnerRupert (talk) 12:22, 6 February 2017 (UTC)[reply]
  2. Jan Dittrich (WMDE) (talk) 12:43, 6 February 2017 (UTC)[reply]
  3. Daniel Mietchen (talk) 22:41, 6 February 2017 (UTC)[reply]
  4. André Costa (WMSE) (talk) 15:37, 8 February 2017 (UTC)[reply]
  5. Mglaser (talk) 10:27, 13 February 2017 (UTC)[reply]
  6. Sebastian Berlin (WMSE) (talk) 11:14, 13 February 2017 (UTC)[reply]
  7. B20180 (talk) 13:49, 14 February 2017 (UTC)[reply]

Complete documentation about different types of caching for extension developers

Tracked in Phabricator
Task T156693

Problem

As an extension developer, I often ran into issues where my code would not be executed / updated due to some cache hit in earlier parts of the code. Documentation is spread out all over MediaWiki, and incomplete.

Who would benefit

Extension developers who write code that dynamically changes page content and need to know when and how to invalidate the caches.

Proposed solution

A good starting point is https://www.mediawiki.org/wiki/Manual:Caching. We need to complete the information missing for some cache types. A rough description of which caches are used when in the execution order would be extremely helpful (maybe in relation to some central hooks). Also, some information of how these caches can be invalidated within the code and in general should be added.


Endorsements (T156693)

Support (T156693)

  1. Osnard (talk) 12:57, 6 February 2017 (UTC)[reply]
  2. BDavis (WMF) (talk) 17:34, 6 February 2017 (UTC)[reply]
  3. Jack Phoenix (Contact) 23:08, 6 February 2017 (UTC)[reply]
  4. FFS Talk 10:49, 8 February 2017 (UTC)[reply]
  5. Seddon (WMF) (talk) 11:47, 8 February 2017 (UTC)[reply]
  6. André Costa (WMSE) (talk) 15:37, 8 February 2017 (UTC)[reply]
  7. Smalyshev (WMF) (talk) 17:53, 10 February 2017 (UTC)[reply]
  8. Mglaser (talk) 10:27, 13 February 2017 (UTC)[reply]
  9. Sebastian Berlin (WMSE) (talk) 11:16, 13 February 2017 (UTC)[reply]
  10. 47.222.203.135 18:28, 13 February 2017 (UTC)[reply]
  11. Nemo 18:32, 14 February 2017 (UTC)[reply]
  12. Quiddity (WMF) (talk) 20:06, 14 February 2017 (UTC)[reply]

Fix or replace Module:Assemble multilingual message

Tracked in Phabricator
Task T156674

Problem

The process for updating users about technical changes is far more complex than it should be. If I have a technical newsletter (Tech News, specific newsletters for teams or products) and want to reach out in several languages, this is the process to send it out:

  • Generate the text on Meta using a Lua module that combines all languages and adds a switch. See example.
  • Realize you had too many languages, the module can't handle more than 20.
  • Generate the first 20.
  • Generate the next batch.
  • Carefully insert the new languages.
  • Find the duplication of the source text (typically English) and remove one of them.
  • Test it.
  • Find a mistake.
  • Fix it on Meta.
  • Redo the entire process.
  • Finally send it out.

Who would benefit

Anyone keeping users updated about technical changes: upcoming, things they can give feedback on, or new changes.

Proposed solution

At least make sure we can send out messages to more than 20 languages without inviting mistakes by manual insertion prior to MassMessaging all the wikis.

Module:Assemble multilingual message

Endorsements (T156674)

  1. I feel you. However I'm not sure this fits in the scope for this process. Tech News is a needed service and it indeed expensive in terms of time and fatigue, especially for the non-developers running it. Nemo 18:34, 14 February 2017 (UTC)[reply]

Support (T156674)

  1. Nikerabbit (talk) 08:14, 7 February 2017 (UTC)[reply]

Review and update the Examples extension

Tracked in Phabricator
Task T156568

Other than ContentAction, which was touched during GCI, the code in the Examples extension hasn't really been touched for a few years. It would be nice to give it a spring clean, updating code to follow modern coding practices for MediaWiki extensions.

Endorsements (T156568)

  1. When I started extension development, I found several parallel example extensions. They were at the same time overlapping and contradicting each other. A clear go-to example would have helped a lot. Sebastian Berlin (WMSE) (talk) 11:23, 13 February 2017 (UTC)[reply]

Support (T156568)

  1. Tim Landscheidt 11:39, 6 February 2017 (UTC)[reply]
  2. ·addshore· talk to me! 12:22, 6 February 2017 (UTC)[reply]
  3. Osnard (talk) 12:57, 6 February 2017 (UTC)[reply]
  4. Felipe (talk) 13:52, 6 February 2017 (UTC)[reply]
  5. BDavis (WMF) (talk) 17:34, 6 February 2017 (UTC)[reply]
  6. --Marco Aurelio (talk • meta) 19:51, 6 February 2017 (UTC)[reply]
  7. SamanthaNguyen (talk) 22:12, 6 February 2017 (UTC)[reply]
  8. [[kgh]] (talk) 23:21, 6 February 2017 (UTC)[reply]
  9. Santhosh.thottingal (talk) 03:44, 7 February 2017 (UTC)[reply]
  10. André Costa (WMSE) (talk) 15:38, 8 February 2017 (UTC)[reply]
  11. RichardHeigl (talk) 23:17, 9 February 2017 (UTC)[reply]
  12. Pragya99 (talk) 16:37, 10 February 2017 (UTC)[reply]
  13. — Mr. Stradivarius ♪ talk ♪ 08:54, 11 February 2017 (UTC)[reply]
  14. Mglaser (talk) 10:28, 13 February 2017 (UTC)[reply]
  15. Sebastian Berlin (WMSE) (talk) 11:17, 13 February 2017 (UTC)[reply]
  16. Matěj Suchánek (talk) 21:07, 13 February 2017 (UTC)[reply]
  17. B20180 (talk) 13:50, 14 February 2017 (UTC)[reply]
  18. Quiddity (WMF) (talk) 20:07, 14 February 2017 (UTC)[reply]

Document extensions' MediaWiki version compatibility better

Tracked in Phabricator
Task T156500

Problem

Extensions are (supposed to be) documented on a page on MediaWiki. This documentation includes Template:Extension to provide a summary of important information about the extension, including the "required version of MediaWiki".

This version field is inadequate: does specifying "1.19+" mean that the extension's master branch is intended to be compatible with MediaWiki 1.19, or that the extension has release branches going back to REL1_19 while the extension's master branch is only intended to be compatible with MediaWiki core's master branch, or perhaps some middle ground?

Some extensions have solved this by including detailed text in the existing "version" parameter, such as "1.26+ . Flow master is only supported with core's master; otherwise, use matching branches (e.g. Flow REL1_26 with core REL1_26, or matching WMF release branches).", but this is currently done inconsistently and infrequently.

Who would benefit

Developers making updates to extensions for a core change in compliance with the new deprecation policy will no longer have to guess at whether backwards compatibility with older versions of MediaWiki core should be maintained.

Developers of extensions that don't maintain compatibility with old versions of MediaWiki won't have unnecessary and sometimes complex backwards-compatibility code added.

Developers of extensions that do maintain compatibility with old versions of MediaWiki won't have to -1 or -2 as many changes that break backwards compatibility.

Proposed solution

  1. Update Template:Extension with parameters to indicate the MediaWiki versions for which release branches exist versus the MediaWiki versions the extension's master branch maintains compatibility with.
  2. Update existing extension pages to use these parameters, which may involve determining the master-compatibility policy where it's not already specified.

Endorsements (T156500)

Support (T156500)

  1. This, that and the other (talk) 08:20, 6 February 2017 (UTC)[reply]
  2. ·addshore· talk to me! 12:22, 6 February 2017 (UTC)[reply]
  3. Anomie (talk) 15:50, 6 February 2017 (UTC)[reply]
  4. Daniel Mietchen (talk) 22:42, 6 February 2017 (UTC)[reply]
  5. [[kgh]] (talk) 23:22, 6 February 2017 (UTC)[reply]
  6. Nikerabbit (talk) 08:14, 7 February 2017 (UTC)[reply]
  7. Matěj Suchánek (talk) 14:00, 7 February 2017 (UTC)[reply]
  8. Tgr (WMF) (talk) 09:08, 8 February 2017 (UTC)[reply]
  9. Cindy.cicalese (talk) 14:19, 8 February 2017 (UTC)[reply]
  10. André Costa (WMSE) (talk) 15:41, 8 February 2017 (UTC)[reply]
  11. Edy7222 (talk) 12:26, 10 February 2017 (UTC)[reply]
  12. Ciencia Al Poder (talk) 12:02, 12 February 2017 (UTC)[reply]
  13. Mglaser (talk) 10:28, 13 February 2017 (UTC)[reply]
  14. 47.222.203.135 18:28, 13 February 2017 (UTC)[reply]
  15. --Nemo 18:35, 14 February 2017 (UTC)[reply]

Create a developer documentation special interest group

Tracked in Phabricator
Task T156301

Problem
Documentation is out of date, incomplete (T2001: Documentation is out of date, incomplete (tracking))

Wikimedia produces a large number of FLOSS software products targeted at various audiences. The audiences need documentation in the form of tutorials, API references, platform overviews, etc to effectively use and extend the products. MediaWiki itself is a highly extensible platform for creating solutions for collaborative, open sharing of information. Sadly, this platform itself is under-documented which slows down the rate at which developers can produce innovative solutions based on it. "Read the source code" is not an acceptable way to gain an initial understanding of a product offering, but many software developers lack the time, motivation, and skills needed to effectively and completely document the solutions they produce. Improved technical documentation of the internal and external interfaces that can be used to extend or programmatically consume MediaWiki hosted content should make use and development easier for existing and future technical contributors.

Solution
Create special interest group in charge of:

  • Triaging/grooming the #documentation workboard.
  • Identifying top priorities based on impact and interest.
  • Organizing activities (including lobbying to the Wikimedia Foundation) in order to complete the top priorities.
  • Attracting people interested in working on documentation.
  • Connecting documentation volunteers with people and projects who can help get them started.
  • Advocating documentation best practices for Wikimedia products.
  • Developing resources to make contributing technical documentation easier.


See also

Endorsements (T156301)

  1. I thought it already existed. :) Project:PD help, Project:WikiProject Extensions and Project:WikiProject Bug Squad are similar; is this just a proposal to create yet another such project but with a much larger scope? Nemo 18:40, 14 February 2017 (UTC)[reply]

Support (T156301)

  1. Info-farmer (talk) 05:26, 6 February 2017 (UTC)[reply]
  2. Natkeeran (talk) 13:47, 6 February 2017 (UTC)[reply]
  3. BDavis (WMF) (talk) 17:35, 6 February 2017 (UTC)[reply]
  4. Miriya52 (talk) 21:23, 6 February 2017 (UTC)[reply]
  5. Daniel Mietchen (talk) 22:43, 6 February 2017 (UTC)[reply]
  6. Xephyr826 (talk) 22:50, 6 February 2017 (UTC)[reply]
  7. [[kgh]] (talk) 23:22, 6 February 2017 (UTC)[reply]
  8. MHolloway (WMF) (talk) 22:32, 7 February 2017 (UTC)[reply]
  9. Calexit (talk) 22:26, 9 February 2017 (UTC)[reply]
  10. SamanthaNguyen (talk) 01:11, 13 February 2017 (UTC)[reply]
  11. Quiddity (WMF) (talk) 20:07, 14 February 2017 (UTC)[reply]

Improve documentation of OOjs UI

Tracked in Phabricator
Task T155473

Problem

Extension developers and even core MediaWiki developers want to, or should want to, use a standardized design. Even if we don't like the standard itself, by using a standard we can then inherit improvements to the standard with little to no additional work.

OOjs UI is the standard. However, it is difficult to work with, owing to poor documentation. This discourages its use and adoption as a standard.

Compare this to other frameworks such as Semantic UI that make it very easy to use its design. You can use its JavaScript widgets for specialized features, or just use the CSS to get the look and feel if you are dealing with static HTML.

Who would benefit

People developing new extensions and those working on improvements to MediaWiki core and existing extensions. The Wikimedia Foundation would benefit from less time wasted on figuring out this system.

Proposed solution

Better documentation that makes it easier for developers to integrate OOjs UI.

Endorsements (T155473)

  1. Same endorsement as I wrote at Developer_Wishlist/2017/Frontend#Make_OOjs_UI_easier_to_use_for_gadgets. Very much needed. There is a beginning of a documentation page, but it needs major expansion. Probably the best way to do this would be to actually start porting existing gadgets to OOJS and document the solutions to problems, or at least ask questions. Amir E. Aharoni (talk) 09:27, 7 February 2017 (UTC)[reply]

Support (T155473)

  1. Dvorapa (talk) 09:01, 6 February 2017 (UTC)[reply]
  2. Ladsgroup (talk) 10:02, 6 February 2017 (UTC)[reply]
  3. Jan Dittrich (WMDE) (talk) 12:43, 6 February 2017 (UTC)[reply]
  4. Osnard (talk) 12:58, 6 February 2017 (UTC)[reply]
  5. Felipe (talk) 13:53, 6 February 2017 (UTC)[reply]
  6. Amir E. Aharoni (talk) 14:06, 6 February 2017 (UTC)[reply]
  7. SamanthaNguyen (talk) 22:12, 6 February 2017 (UTC)[reply]
  8. Jdlrobson (talk) 01:05, 7 February 2017 (UTC)[reply]
  9. Santhosh.thottingal (talk) 03:44, 7 February 2017 (UTC)[reply]
  10. Sunfyre (talk) 07:31, 7 February 2017 (UTC)[reply]
  11. Prtksxna (talk) 07:54, 7 February 2017 (UTC)[reply]
  12. Nikerabbit (talk) 08:15, 7 February 2017 (UTC)[reply]
  13. Yamaha5 (talk) 09:28, 7 February 2017 (UTC)[reply]
  14. Chico Venancio (talk) 13:27, 7 February 2017 (UTC)[reply]
  15. Iniquity (talk) 00:22, 8 February 2017 (UTC)[reply]
  16. Tpt (talk) 09:17, 8 February 2017 (UTC)[reply]
  17. Ricordisamoa 11:30, 8 February 2017 (UTC)[reply]
  18. Enterprisey (talk) 20:38, 8 February 2017 (UTC)[reply]
  19. — Mr. Stradivarius ♪ talk ♪ 08:56, 11 February 2017 (UTC)[reply]
  20. Helder 18:13, 12 February 2017 (UTC)[reply]
  21. Mglaser (talk) 10:29, 13 February 2017 (UTC)[reply]
  22. Sebastian Berlin (WMSE) (talk) 11:24, 13 February 2017 (UTC)[reply]
  23. Ainali (talk) 11:43, 14 February 2017 (UTC)[reply]
  24. Thiemo Mättig (WMDE) 15:42, 14 February 2017 (UTC)[reply]
  25. 0x010C (talk) 18:55, 14 February 2017 (UTC)[reply]
  26. Quiddity (WMF) (talk) 20:09, 14 February 2017 (UTC)[reply]
  27. Daniel Renfro 20:44, 14 February 2017 (UTC)[reply]

Organize a MediaWiki Documentation Day (similar to the Gerrit Cleanup Day)

Tracked in Phabricator
Task T126500

It would be awesome if we devoted 1 entire day to doing nothing but documenting MediaWiki. There are countless classes and functions in MediaWiki core and its extensions that have no documentation. There is also a serious lack of high level documentation for developers. The problem is that documentation is often an after-thought and rarely gets focused attention from developers.

Some suggested projects that could be part of MediaWiki Documentation Day:

  • Tackle some of the blocking tasks at T2001: Documentation is out of date, incomplete (tracking) or #tracking.
  • Add in-code function descriptions for important functions that don't have them.
  • Add in-code class descriptions to classes that don't have them.
  • Create documentation pages on MediaWiki.org for important classes in core that don't have them. See Manual:User.php for an example of a page that does exist. High-level documentation, like Manual:Title.php#Title_structure is especially useful.
  • Clean up our outdated documentation on MediaWiki.org.
  • Create README files for all the extensions that don't have them and make sure that all configuration variables are documented there.
  • Create some high-level documentation on how to write new API modules.

See Also:

Endorsements (T126500)

Support (T126500)

  1. Info-farmer (talk) 05:28, 6 February 2017 (UTC)[reply]
  2. BDavis (WMF) (talk) 17:38, 6 February 2017 (UTC)[reply]
  3. ABaso (WMF) (talk) 18:17, 6 February 2017 (UTC)[reply]
  4. --Marco Aurelio (talk • meta) 19:51, 6 February 2017 (UTC)[reply]
  5. Miriya52 (talk) 21:24, 6 February 2017 (UTC)[reply]
  6. Daniel Mietchen (talk) 22:43, 6 February 2017 (UTC)[reply]
  7. Iniquity (talk) 00:26, 8 February 2017 (UTC)[reply]
  8. Tgr (WMF) (talk) 09:09, 8 February 2017 (UTC)[reply]
  9. Ricordisamoa 11:30, 8 February 2017 (UTC)[reply]
  10. Headbomb (talk) 21:05, 8 February 2017 (UTC)[reply]
  11. Calexit (talk) 22:25, 9 February 2017 (UTC)[reply]
  12. Smalyshev (WMF) (talk) 02:34, 10 February 2017 (UTC)[reply]
  13. Ov1k*dsa (talk) 22:41, 12 February 2017 (UTC)[reply]
  14. SamanthaNguyen (talk) 01:11, 13 February 2017 (UTC)[reply]
  15. Sebastian Berlin (WMSE) (talk) 11:25, 13 February 2017 (UTC)[reply]
  16. James Martindale (talk) 17:09, 13 February 2017 (UTC)[reply]
  17. Quiddity (WMF) (talk) 20:09, 14 February 2017 (UTC)[reply]

Relocate CI generated docs and coverage reports

Tracked in Phabricator
Task T137890

Part of / blocker of T133300: Target architecture without gallium.wikimedia.org

Another blocker, and potentially a prerequisite, is publishing the generated documentation. From the drawing and https://www.mediawiki.org/wiki/Continuous_integration/Documentation_generation

CI Target 2016 - Relocation of Doc / coverage reports (private) gives an overview of the documentation flow.

{Image size=full}

As summarized by thcipriani :

Current:

  • Doc and coverage reports are generated on Nodepool instances (they have lot of build dependencies)
  • Building instance rsync to a labs instance integration-publisher
  • A Jenkins job publish-on-gallium is executing on gallium to rsync the doc from the publisher instance.

We would need an instance to host the material with PHP5 (some docs need that). Most probably out of the labs support host / on an isolated network. We would need some intermediary system to have the Nodepool building instances to push to.

  • Doc and coverage reports are still generated on Nodepool instances
  • Building instance push to a publisher system
    • might reuse integration-publisher
  • Jenkins (or another system) runs a task that fetch from the publisher system to doc.wikimedia.org document root.


We need to find a target host on which to migrate documentation to. It would have Apache / PHP5 code and run code as generated by the various code repository that have doc/coverage enabled.

Flow originating from webhost

Proto source host source IP dest network dest Host dest IP dest port description
TCP webhost ??? labs project publisher 10.68.16.255 873 Jenkins job doing a rsync from Webhost to fetch material

Flow going to webhost

Proto source network source host source IP dest Host dest port description
TCP labs support hosts scandium  10.64.4.12 webhost 22 Jenkins master ssh connection
TCP production misc varnish - webhost 80 Misc cache to Apache serving doc.wm.o

Endorsements (T137890)

Support (T137890)

Create an authoritative and well promoted catalog of Wikimedia tools

Tracked in Phabricator
Task T115650
Resolved

Suggested by Qgil at https://lists.wikimedia.org/pipermail/wikitech-l/2015-October/083580.html

Brief list of catalogs that have been suggested thus far:

Somewhat related:

See also: T1238: Central Code Repository for code used on wikis (Templates, Lua modules, Gadgets)

Endorsements (T115650)

  1. I have to say this and the entire page here are only symptoms of MW being treated as a side-effect of Wikimedia's existence and not as a platform that if honestly catered can bring multitudes of benefits to WM in the long run. Calexit (talk) 22:38, 9 February 2017 (UTC)[reply]
  2. Super important. On this I can speak on behalf of whole communities: in my travels and encounters with different communities, especially in the developing world, I see whole communities laboring without the benefit of available tools, just because they're so hard to discover. I regularly promote Hay's Tools Directory, and contributed some toolinfo.json files for other people's tools so that HTD would make them discoverable, but a canonical/complete one would be far superior. Ijon (talk) 00:49, 14 February 2017 (UTC)[reply]

Support (T115650)

  1. Info-farmer (talk) 05:29, 6 February 2017 (UTC)[reply]
  2. David1010 (talk) 06:47, 6 February 2017 (UTC)[reply]
  3. Dvorapa (talk) 09:02, 6 February 2017 (UTC)[reply]
  4. Vriullop (talk) 09:49, 6 February 2017 (UTC)[reply]
  5. Ladsgroup (talk) 10:03, 6 February 2017 (UTC)[reply]
  6. Frettie (talk) 10:08, 6 February 2017 (UTC)[reply]
  7. Abbe98 (talk) 11:35, 6 February 2017 (UTC)[reply]
  8. Natkeeran (talk) 13:47, 6 February 2017 (UTC)[reply]
  9. Felipe (talk) 13:54, 6 February 2017 (UTC)[reply]
  10. --Marco Aurelio (talk • meta) 19:50, 6 February 2017 (UTC)[reply]
  11. Miriya52 (talk) 21:24, 6 February 2017 (UTC)[reply]
  12. Daniel Mietchen (talk) 22:44, 6 February 2017 (UTC)[reply]
  13. — MusikAnimal talk 22:49, 6 February 2017 (UTC)[reply]
  14. Tshrinivasan (talk) 02:40, 7 February 2017 (UTC)[reply]
  15. Sunfyre (talk) 07:32, 7 February 2017 (UTC)[reply]
  16. Prtksxna (talk) 07:55, 7 February 2017 (UTC)[reply]
  17. Yamaha5 (talk) 09:28, 7 February 2017 (UTC)[reply]
  18. Tgr (WMF) (talk) 09:10, 8 February 2017 (UTC)[reply]
  19. Ricordisamoa 11:31, 8 February 2017 (UTC)[reply]
  20. NicoV (talk) 18:58, 8 February 2017 (UTC)[reply]
  21. Headbomb (talk) 21:05, 8 February 2017 (UTC)[reply]
  22. Calexit (talk) 22:27, 9 February 2017 (UTC)[reply]
  23. Sam Wilson 01:25, 10 February 2017 (UTC)[reply]
  24. — Mr. Stradivarius ♪ talk ♪ 08:59, 11 February 2017 (UTC)[reply]
  25. Deniz (talk) 22:59, 11 February 2017 (UTC)[reply]
  26. Helder 18:13, 12 February 2017 (UTC)[reply]
  27. Mglaser (talk) 10:25, 13 February 2017 (UTC)[reply]
  28. Sebastian Berlin (WMSE) (talk) 11:10, 13 February 2017 (UTC)[reply]
  29. TerraCodes (talk) 21:12, 13 February 2017 (UTC)[reply]
  30. Ijon (talk) 00:47, 14 February 2017 (UTC)[reply]
  31. Lluis tgn (talk) 14:21, 14 February 2017 (UTC)[reply]
  32. Framawiki (talk) 18:05, 14 February 2017 (UTC)[reply]
  33. Quiddity (WMF) (talk) 20:11, 14 February 2017 (UTC)[reply]

Document common low level site requests (namespace + logo changes, IP throttling expectations) for potential technical contributors and advertise those docs in tasks

Tracked in Phabricator
Task T126330

A good bunch of #Wikimedia-Site-Requests items are pretty common / repetitive: Namespace translation changes, namespace additions, site logo changes, IP throttling exceptions for editathons etc.

Let's make sure they are documented for the patch writers (maybe they already are?) so aklapper can link to such docs everytime aklapper sees a request via his Phabricator stock answers. We don't want to burn out our existing contributors in this area like Dereckson etc. and we want to grow our technical contributor base.

Endorsements (T126330)

  1. No doubt working on code requires some technical knowledge but for people who has started coding, are new to code-review/Phabm etc. it'd be good to have updated docs for the most common and easy site requests such as userrights configuration (and their restrictions), project-logos and known issues related to handling those. I think that'll help all of us. --Marco Aurelio (talk • meta) 19:48, 6 February 2017 (UTC)[reply]

Support (T126330)

  1. --Marco Aurelio (talk • meta) 19:48, 6 February 2017 (UTC)[reply]
  2. Tgr (WMF) (talk) 09:10, 8 February 2017 (UTC)[reply]
  3. Martin Urbanec (talk) 18:13, 13 February 2017 (UTC)[reply]
  4. TerraCodes (talk) 21:10, 13 February 2017 (UTC)[reply]
  5. Framawiki (talk) 18:05, 14 February 2017 (UTC)[reply]

Run a documentation sprint for Labs

Tracked in Phabricator
Task T101659

Currently documentation is way too out of date and inconsistent. Setup a weeklong sprint with specific tasks to fix documentation, and run the weeklong sprint, with help from Admins and volunteers.

Should involve both general labs and tool labs.

See also:

Endorsements (T101659)

  1. Updated docs are always welcome and very useful for all of us, specially those such as me who are not so technically savy as others. --Marco Aurelio (talk • meta) 19:50, 6 February 2017 (UTC)[reply]
  2. I have on two separate occasions had trouble getting things up and running on Labs (not Tool Labs), and it was only through my relatively easy access to Labs engineers that I was able to get it done. We probably lose potential innovation and contribution because the documentation is so out of date and confusing. Ijon (talk) 00:46, 14 February 2017 (UTC)[reply]
  3. There were some larger changes in the last year or so which don't seem to have been documented much, or at all. I'm not sure a sprint is the correct solution (how many people are actually able to contribute) but the problem is real. Nemo 18:46, 14 February 2017 (UTC)[reply]

Support (T101659)

  1. BDavis (WMF) (talk) 17:42, 6 February 2017 (UTC)[reply]
  2. --Marco Aurelio (talk • meta) 19:50, 6 February 2017 (UTC)[reply]
  3. Miriya52 (talk) 21:25, 6 February 2017 (UTC)[reply]
  4. Daniel Mietchen (talk) 22:45, 6 February 2017 (UTC)[reply]
  5. Xephyr826 (talk) 19:51, 7 February 2017 (UTC)[reply]
  6. Tgr (WMF) (talk) 09:11, 8 February 2017 (UTC)[reply]
  7. Ricordisamoa 11:32, 8 February 2017 (UTC)[reply]
  8. Cindy.cicalese (talk) 14:20, 8 February 2017 (UTC)[reply]
  9. Enterprisey (talk) 20:38, 8 February 2017 (UTC)[reply]
  10. Headbomb (talk) 21:06, 8 February 2017 (UTC)[reply]
  11. Calexit (talk) 22:25, 9 February 2017 (UTC)[reply]
  12. James Martindale (talk) 17:08, 13 February 2017 (UTC)[reply]
  13. Martin Urbanec (talk) 18:13, 13 February 2017 (UTC)[reply]
  14. desperately needed. Ijon (talk) 00:44, 14 February 2017 (UTC)[reply]
  15. Quiddity (WMF) (talk) 20:12, 14 February 2017 (UTC)[reply]

Define the architecture areas for MediaWiki core and platform extensions

Tracked in Phabricator
Task T1287

We really miss a high level architecture overview of MediaWiki core and platform extensions (the ones that provide APIs and enable user features). Reasons to have one:

  • MediaWiki and relatives form a very complex family. https://www.mediawiki.org/wiki/Developers/Maintainers lists 210 components only for core, and there is no subdivision to be seen. Without a shared high level map it is a lot more complex to have shared high level discussions and plans.
  • New potential contributors need an overview to understand the basics of MediaWiki and find the area where they want to work on. Such diagram would be really helpful to identify an area as a starting point. After many conversations with many newcomers with different skill levels, we know that most of them get simply lost / overwhelmed in their first contact.
  • Defining areas is a premise required to discuss whether we want to have architects / owners / maintainers for a specific area that would work with the #ArchCom or be part of it.


How a v0.1 could look like:

MediaWiki Core

  • Configuration
  • Database
  • i18n/L10n
  • Parser
  • Skins
  • Media
  • API
  • ...

Platform extensions

  • Parsoid
  • ...

Endorsements (T1287)

Support (T1287)

  1. Osnard (talk) 12:59, 6 February 2017 (UTC)[reply]
  2. Natkeeran (talk) 13:48, 6 February 2017 (UTC)[reply]
  3. Amir E. Aharoni (talk) 14:07, 6 February 2017 (UTC)[reply]
  4. [[kgh]] (talk) 23:23, 6 February 2017 (UTC)[reply]
  5. FFS Talk 10:53, 8 February 2017 (UTC)[reply]
  6. Cindy.cicalese (talk) 14:20, 8 February 2017 (UTC)[reply]
  7. RichardHeigl (talk) 23:16, 9 February 2017 (UTC)[reply]
  8. Liuxinyu970226 (talk) 01:10, 10 February 2017 (UTC)[reply]
  9. SamanthaNguyen (talk) 01:10, 13 February 2017 (UTC)[reply]
  10. Mglaser (talk) 10:26, 13 February 2017 (UTC)[reply]
  11. Necessary. 47.222.203.135 18:28, 13 February 2017 (UTC)[reply]
  12. Daniel Renfro 20:44, 14 February 2017 (UTC)[reply]

MediaWiki.org: Generate infoboxes from extension.json in git

Tracked in Phabricator
Task T155029

Problem

There are some widely used information templates on mediawiki.org which display some software information that could be easily extracted from the source code, but those templates are currently created and maintained manually. This is inefficient and ineffective - it's a significant amount of manual work and often not done, or not updated when code changes. Example: extension, extension install, hook and config variable templates.

Who would benefit

  • Developers who don't need to spend time on creating or updating hook/config var pages whenever they
  • Extension maintainers (especially people who routinely change others' extensions) who don't need to track things like required MW version in two different places
  • Developers and site admins who will gain access to correct and complete documentation
  • Possibly site admins running older MW versions because this would allow a much more user-friendly presentation of MW compatibility information

Proposed solution

  1. find a place to store structured mw.org infobox data - there are several possible approaches, see T155024: Store structured needed for MediaWiki documentation for discussion
  2. write a bot to extract the data from git (extension.json, hooks.txt, DefaultSettings.php phpdoc) and upload it
  3. fetch the data in the infoboxes
  4. for hook/configvar pages, make the bot create them automatically with stub content when they don't exist
  5. run a bot with some regular frequency (e.g. weekly) to update the pages accordingly

Endorsements (T155029)

Support (T155029)

  1. ·addshore· talk to me! 12:22, 6 February 2017 (UTC)[reply]
  2. Osnard (talk) 12:56, 6 February 2017 (UTC)[reply]
  3. Felipe (talk) 13:51, 6 February 2017 (UTC)[reply]
  4. Jdforrester (WMF) (talk) 16:24, 6 February 2017 (UTC)[reply]
  5. Krinkle (talk) 19:59, 6 February 2017 (UTC)[reply]
  6. SamanthaNguyen (talk) 22:12, 6 February 2017 (UTC)[reply]
  7. Santhosh.thottingal (talk) 03:43, 7 February 2017 (UTC)[reply]
  8. Prtksxna (talk) 07:54, 7 February 2017 (UTC)[reply]
  9. Tgr (WMF) (talk) 09:08, 8 February 2017 (UTC)[reply]
  10. Cindy.cicalese (talk) 14:18, 8 February 2017 (UTC)[reply]
  11. André Costa (WMSE) (talk) 15:36, 8 February 2017 (UTC)[reply]
  12. Krishna moorthy 2004 (talk) 11:52, 9 February 2017 (UTC)[reply]
  13. Edward Chernenko (talk) 22:42, 9 February 2017 (UTC)[reply]
  14. RichardHeigl (talk) 23:18, 9 February 2017 (UTC)[reply]
  15. Sam Wilson 01:28, 10 February 2017 (UTC)[reply]
  16. Smalyshev (WMF) (talk) 02:34, 10 February 2017 (UTC)[reply]
  17. BSitzmann (WMF) (talk) 23:21, 11 February 2017 (UTC)[reply]
  18. Mglaser (talk) 10:26, 13 February 2017 (UTC)[reply]
  19. Martin Urbanec (talk) 18:13, 13 February 2017 (UTC)[reply]
  20. BrentLaabs (talk) 01:10, 14 February 2017 (UTC)[reply]
  21. I especially like that we'd get comprehensive categorisation. Some manual customisation is needed though. Nemo 18:27, 14 February 2017 (UTC)[reply]
  22. Quiddity (WMF) (talk) 20:05, 14 February 2017 (UTC)[reply]
Retrieved from "https://www.mediawiki.org/w/index.php?title=Developer_Wishlist/2017/Documentation&oldid=5734709"