Google Code-in/Admins

Participating in Google Code-in requires the Wikimedia organization administrators to perform certain preparation steps and also recurring tasks while the contest is running.

This page is supposed to cover these steps and best practices in order to help next year's organization administrators and improve our processes.

Before getting accepted
For tasks that are **proposed** for Wikimedia's potential participation in Google Code-in 2015. If Wikimedia will get accepted by Google, these tasks will be made available to GCI students once the contest has started. Tasks **must** have at least one mentor defined: Add a comment "I will mentor this in #GCI2015".
 * Read Admin responsibilities
 * Fill out org application
 * Subscribe to the general "Google Code-in Mentors" list (gci-mentors at googlegroups dot com)
 * Read the tips and guidelines for org admins: https://docs.google.com/document/d/1Ah8iHIaOzi9Nj8PNCREWjnXPWMTx2Wq5qlTVBmUrt8c/edit?usp=sharing
 * In 2015, 75 available tasks in total were required at the start. Having more tasks (that we don't publish necessarily on the first day) is highly recommended.
 * In 2015, 50 tasks had to be unique ("instant count" of 1).
 * Create Google Code-in 20xx page and link from Google Code-in
 * Create #Google-Code-in-20xx tag in Phabricator with initial description:
 * Find org admins from more than one timezone.
 * Announce that we applied (2014 example, 2016 example)
 * Reach out to potential mentors 2015 example/list.
 * Explicitly reach out to Google Summer of Code and Outreachy mentors and students from the previous round.
 * Explicitly reach out to GCi mentors and students (if you can find their email addresses in Gerrit) from last year (see table on the wikipage)
 * Reach out to Possible mentors
 * Consider reaching out to tool maintainers on ToolLabs.
 * Specific mailing lists: pywikipedia-l@, mediawiki-i18n@, multimedia@, wikitext-l@, wikidata-l@, qa@, analytics@, labs-l@, mobile-l@, Kiwix, design@. Provide URLs to their latest Phabricator/issue tracker tickets marked as "easy" in their fields of interest. See 2016 links.
 * Generic wikitech-l email examples from 2013: 1, 2, 3, 4.
 * Ask on certain wiki pages. See 2016 links. Examples from 2014: English Village Pump, German Technik-Werkstatt, Commons Village Pump, Lua, mediawiki.org's Gadget kitchen, Template Data.
 * Help finding tasks:
 * Potentially go through GCI 2014/2015 tickets in Phabricator and update/comment on open tasks (or copy ideas from closed tasks).
 * Check https://www.mediawiki.org/wiki/Talk:Google_Code-in if there's some good ideas/mentors
 * Find potential beginner tasks and mentors for them. See

After getting accepted

 * Announce that we are in (2013, 2014, 2015, 2016)
 * Also announce via Social media services to create awareness and reach potential students?
 * Invite people who have expressed interest in mentoring via Google's site. They will receive an email with registration instructions. Also check the "Pending invites" and nag.
 * Update wikipage to say that we have been accepted as an org
 * Update wikipage to say that tasks should be created on the Google site directly
 * Update Google-Code-In project description on Phabricator if needed.
 * Either manually create tasks on Google's GCI site (leave the mentor field empty if mentors are not registered yet in Google's site), or
 * Import tasks from Wikimedia Phabricator into the GCI site via its API. See the API high-level info and related documentation on format and commands.
 * Get tasks out of Phabricator by using Tony's script:
 * Potentially fix stuff in that script which has changed since last year when it was used (like IDs of workboard elements in Phabricator)
 * Get a CSV file as output
 * In that CSV file,
 * Add explicit column headers like "name", "description", "external_url" in the csv
 * Keep the "mentors" column empty, so we will easily recognize which tasks on the GCI site were imported and we need to go through
 * Set "time_to_complete_in_days" to "5" for all tasks
 * Set "categories" to "1" (code)
 * Set "is_beginner" to "0" as default
 * Set "tags" to "php" as default
 * Get the API key from https://codein.withgoogle.com/dashboard/profile/
 * Run Google's "python csv_uploader.py --api-key XYZ whatever.csv" from https://code.googlesource.com/codein/api
 * Edit the tasks manually on the GCI site and edit fields
 * Move imported Phab tasks to the "Imported" column on the Phabricator workboard. Post a link to the task URL on the GCI site but note that your admin's "Dashboard" URL path will not work; public URLs have the format https://codein.withgoogle.com/tasks/6342270513053696/ instead.
 * Creating recurring/clonable tasks: Use the "Instance Count" field when creating a task in Google's site.

When contest starts

 * Announce start of contest on wikitech-l (2015; 2016)
 * Consider sending an info email to all mentors; and/or having an info session for new mentors (2016 discussion)
 * Contact mentors without any tasks via email to check their plans

General recommendations while contest is running

 * The dashboard links to tasks waiting for review. Order by the "Modified" column to check tasks getting close to the 36h deadline for reviews (mentors and admins receive email warnings after 24h already).
 * Actively find more mentors. Contact existing mentors without open tasks if they have some more.
 * Try to actively follow students' activity on IRC: We do not have email addresses to contact students and we want to keep them involved after the contest ends, so we need to be able to actively ask "Do you fancy trying some more stuff?"and point to e.g. Annoying little bugs.

Daily tasks while running

 * Review new unapproved "Draft tasks" (which were added recently by mentors and should get reviewed and then published by org admins). Check their quality and publish them.
 * Check tasks "waiting for review" (<36h intended) and potentially provide feedback to help mentors
 * Check number of unique tasks via in "Open"/"Reopened" state (>50 intended), potentially publish more ready tasks when getting close to the minimum limit of 50
 * Check for new tasks in "Unapproved" and "Unpublished" state and review/publish/subscribe to them
 * For recurring tasks with several instances, check if enough are still open and if you should "publish" a task copy (if using suffix number in a title) as one student can only claim one instance of a recurring task. If you want one student to be able to work on more than one recurring task, you must create a separate copy of the task instead of increasing its instance count.

Weekly tasks while running

 * Gather statistics on open/claimed/closed tasks and publish them as a diagram (2013 example)
 * Send summary at some point to wikitech-l (2014 example after first week; 2015 example after half time)

Before the contest has ended

 * The last two weeks, potentially be a bit "stricter" with prospect finalists to get more "quality"?
 * Create "Write a blogpost about your GCI experience" task at the end
 * When reviewing the last tasks, add "Here are more tasks (link); see you on IRC, the mailing lists, Phabricator and Gerrit" at the end of the contest in mentors' in comment

After the contest has ended

 * Update Google Code-in 20xx page that the contest is over (2015 example)
 * Move subpage link on Google Code-in to "Past programs" (2015 example)
 * Contact mentors, thank them, ask them to name remarkable students, and to provide general feedback (What was good (socially & technically)? What to improve? Which tasks should we have offered but were missing? Which tasks did not get picked up + do you have a theory why? How was the interaction with students on IRC, mailing lists, Phabricator, Gerrit? Where did students struggle? Share your ideas and impressions.)
 * Decide on Google Code-in Grand Prize winners for this organization: 1) quality of work, 2) thoroughness of work, 3) creativity of their work. Community involvement like helping other students on IRC etc. can be included. (2014; 2015).
 * Send final summary to wikitech-l (2015 example)
 * Potentially get some GCI-related blogposts out (2015: T124656, T124781)

GCI summit

 * Define who of the mentors/admins to attend (mentors with most tasks, via private emails)
 * Forward email from Google containing the PO number to the person to attend the summit
 * Afterwards, attendee to invoice WMF (via accountspayable) to get reimbursed

Tasks that did not work well in the past

 * In 2015 we had tasks about extensions that do not list their software license (and to add it). However students often did not check all files and the task turned out to be more complex when it came to required investigations than initially thought.
 * In 2015 we edited some on-wiki developer documentation but results were mixed as students often performed (more or less acceptable) copy&paste on each page without actually understanding what problem they were solving by their wiki edits.

2015 feedback from T123920

 * The CI whitelist caused confusion (and waste of time as the student had to wait for half a day due to timezone differences just so someone else can say "recheck"). Either need more documentation on how to run tests locally, or ideally add all students to the whitelist at the beginning. https://gerrit.wikimedia.org/r/#/c/261322/ Without adding, only a subset of the tests is run by jenkins and that can cause confusion.
 * Vagrant docs might need better documentation for Windows platform?
 * How to encourage having more tasks with more than one mentor?
 * Better workflow for mentors creating tasks to tell admins they are ready to publish? Or is "Either add a "[READY]" prefix to the task summary to let org admins know, or contact them explicitly." sufficient?
 * Part of GCI is "getting work/tasks done", part is "recruiting new contributors / community members"
 * We miss a "pipeline" how to direct students to further stuff (try GSoC if you are 17?) Point to local hackathons? / "GCI is missing a follow-up program for the best contributors. (Or maybe the MediaWiki/Wikimedia technical community is missing a non-time-limited mentorship system?)" Every year there are GCI participants with a "hire on sight" competence level and it would be great to keep them engaged.
 * Students sometimes still have no way to gauge the complexity / required skill level of a task, and making a task description perfect can be the enemy of good.

pre-2015

 * GCI Organization Advice (Jan 2016)
 * RTEMS mentor advice

Unknown mentors
Boilerplate text to reply to unknown mentors:

''Thank you a lot for being available as a GCI mentor! Wikimedia mentors need to be able to guide students. Hence mentors need to be experienced Wikimedia contributors and need to know the community and "how things work". Could you please share some information which specific Wikimedia projects you have contributed to and worked on so far? How would you describe your areas of expertise within Wikimedia? Are there any public Wikimedia contributions you could link to (for example your username or your Gerrit activity)? This would help us to get a better idea. Thank you! (Also, for an invitation to Google's GCI website we need your email address.) And if you have not contributed to Wikimedia yet, we encourage you to start contributing to Wikimedia by checking out https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker ! Thank you!''

Proxying for mentors not on the GCI site
Boilerplate text to add to tasks with mentors who are actually not registered on the GCI site:

You *must* use the linked Phabricator task for communication with your mentors as some of the task mentors are not registered here on the GCI website, so they will not see your comments here.

Beginner task ideas

 * Set up a Vagrant instance (your development environment), install an extension, and prove via screenshot.
 * Set up a repository in Gerrit and have a beginner task that requires students to clone that repo, create a file named with their GCI username or something, commit the file to their local Git clone, and submit the patch for review? Might also help start making students test their patches themselves earlier.

Beginner: get on Internet Relay Chat (IRC)
GCI mentoring, like most free/libre software collaboration efforts, [relies heavily on IRC](https://www.mediawiki.org/wiki/Special:MyLanguage/Communication) for success. You don't understand why? Come see yourself!

If you have not chatted in Wikimedia IRC channels yet, you can claim this task. You will:


 * install an [IRC client](https://en.wikipedia.org/wiki/Comparison_of_Internet_Relay_Chat_clients) you like, except IRC clients listed as "web" or [proprietary](https://en.wikipedia.org/wiki/Proprietary_software) (for instance irssi, HexChat and KVIrc are good, mIRC and webchat.freenode.net are not ok);
 * connect to freenode and register your nickname;
 * join #wikimedia-dev ([instructions](https://meta.wikimedia.org/wiki/IRC/Instructions));
 * introduce yourself on the channel (one sentence is enough) and mention Google Code-In;
 * wait at least one hour before leaving.

When you have completed the steps above and the time has passed, you are done: just submit this task for review; mention the nick you used if different from the one you have here.

OPTIONAL: If you want to use your time at best, follow the conversation and the updates on the channel: you will probably have interesting occasions to help another person like you or be helped, click an instructive link, fix some bug. You can also join [another IRC channel](https://meta.wikimedia.org/wiki/IRC/Channels) in your native language, for instance.

OPTIONAL: You may also want to subscribe to one of our [technical mailing lists](https://meta.wikimedia.org/wiki/Mailing_lists/Overview#General_development_and_technical_discussion) for longer help and training.

("60 task instances later, I think we proved that the IRC task is not so easy at all for the students. I think one third of them needed to resubmit their work after receiving additional instructions, or to have an extension, or abandoned the task.")

Retest 3 old open bug reports in Wikimedia's issue tracker
1. Read [How To Triage](https://www.mediawiki.org/wiki/Bug_management/How_to_triage) 2. [Log into our issue tracker](https://www.mediawiki.org/wiki/Phabricator/Help) (called Phabricator) 3. Go to [Phabricator's advanced search](https://phabricator.wikimedia.org/maniphest/query/advanced/), set the "Statuses" field to "Open", set "Projects" to "testme" & set the "Updated Before" field accordingly (see [Searching For Items](https://www.mediawiki.org/wiki/Phabricator/Help#Searching_for_items)). Tasks in the "testme" project are bugs that someone wants to see retested. 4. Read those reports that interest you & try to understand them (if they are too complicated or advanced you have to choose other reports instead. This can happen quite often but it helps getting an idea of how complex software can be). 5. If you think you understand what the report is about (this might require looking up docs): Test if you can still reproduce the reported problem (and if the steps to reproduce are clear). 6. Add a comment in Phabricator & explain clearly which steps you performed (step by step) and the version you tested with (e.g. for MediaWiki you can find this information on the page "Special:Version"). Remove the "testme" project from the task by clicking "Edit the task". 7. Note: Some tasks might be easy to retest (for example on https://test2.wikipedia.org) and some might require [setting up MediaWiki yourself](https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker) - it's up to you! 8. Paste the links here to those tasks that you retested. 9. Thanks for helping clean up the backlog of open tasks!

(but: Not many students claimed the "Triage some #testme bug reports", maybe that choice was too limited?)

Create MediaWiki-Vagrant role for a MediaWiki extension
[MediaWiki-Vagrant](https://www.mediawiki.org/wiki/MediaWiki-Vagrant) is a development environment for MediaWiki - a set of scripts to build a virtual machine, install MediaWiki on it and configure various extensions and other options.

Extensions are added by enabling roles; a role corresponds to a simple Puppet script - a declarative description about the state of the virtual machine. The task is to add a role for an extension that does not have one yet. Some suggestions are listed below but you can pick any other extension that works with the current version of MediaWiki.

Familiarity with Puppet or Vagrant is NOT required for this task; you can pick it up as you go, from the MediaWiki-Vagrant documentation and by looking at existing roles.

//Requirements//


 * [create a task](https://phabricator.wikimedia.org/maniphest/task/create/?projects=google-code-in-2016&description=TODO:TaskURL) in Wikimedia's bug tracker for the specific extension you are writing a role for
 * submit a patch for the "mediawiki/vagrant" repository in Gerrit containing the actual role
 * roles should contain documentation ([this is a good example](https://phabricator.wikimedia.org/diffusion/MWVA/browse/master/puppet/modules/role/manifests/templatedata.pp); you can use [RDoc markup](http://jan.varwig.org/wp-content/uploads/2006/09/Rdoc%20Cheat%20Sheet.pdf) for links etc).
 * if the functionality of the extension can be well demonstrated on a wiki page, add such a demo page to the role ([example](https://gerrit.wikimedia.org/r/#/c/189182/7))
 * after the patch is merged, add the role name to the wiki page of the extension ([example](https://www.mediawiki.org/w/index.php?diff=prev&oldid=1958443))

//Some extensions you can pick// (TODO: add links)

Code; Vagrant, puppet; tgr

Write tests for modules that are in the stable MobileFrontend extension and have low code coverage
Despite these features being surfaced in the stable version of [MediaWiki's MobileFrontend extension](https://www.mediawiki.org/wiki/Extension:MobileFrontend) they have very little [code coverage](https://en.wikipedia.org/wiki/Code_coverage):

TODO: Add examples

Let's get these up to at absolute minimum 50%

See https://phabricator.wikimedia.org/T103440 for more information.

Expected: Update the test coverage in at least one of the modules listed above by 5%.

QA; mobilefrontend, qunit; Baha

Add screenshots of MediaWiki extensions or skins to mediawiki.org
A significant number of extensions and skins on MediaWiki.org do not have a screenshot in their infobox. Please pick one extension or skin from the below categories to take a screenshot of.


 * https://www.mediawiki.org/wiki/Category:MediaWiki_extensions_without_a_screenshot
 * https://www.mediawiki.org/wiki/Category:MediaWiki_skins_without_a_screenshot

Tell us in this task which extension or skin you have chosen.

Please see https://phabricator.wikimedia.org/T121332 for details and more links on how to take screenshots, where they should be uploaded, and how to add them to the extension/skin page.

Doc/Training; mediawiki, screenshot, extension, skin; Andre/Niharika/Legoktm

Help fix the localisation/internationalisation of MediaWiki
Read the [internationalisation hints](https://www.mediawiki.org/wiki/Localisation#Internationalization_hints) (ideally, the whole Localisation page), keep the [messages API manual](https://www.mediawiki.org/wiki/Manual:Messages_API) at hand.

Pick 3 [i18n tasks](https://phabricator.wikimedia.org/maniphest/query/uojcohgxGwqq/#R) and/or [MediaWiki open support requests](https://translatewiki.net/wiki/Support/Open_requests#MediaWiki) (translatewiki.net threads). Comment on each bug report or thread to say that you're working on it; add Nemo to the Subscribers/CC list on Phabricator if missing.

[Triage](https://www.mediawiki.org/wiki/Bug_management/Triage) the request appropriately to identify the issue and the correct action to take. Submit patches to gerrit, or provide the translator with the information needed to translate the messages (by [editing their /qqq subpages](https://www.mediawiki.org/wiki/Localisation#Message_documentation)), or reject the request if the message shouldn't be changed.

[Add reviewers](https://www.mediawiki.org/wiki/Gerrit/Code_review/Getting_reviews#Add_reviewers) to your patches in Gerrit: at least Nemo. All questions on each task will be asked and answered on the relevant bug, patch or thread.

Post here a link to a gerrit change, bug or thread for each of the 3 issues; the task will be accepted here when they are marked merged/closed.

Code; i18n, php, language, l10n; Nemo

Add licenses to 3 MediaWiki extensions so they appear on Special:Version page
TODO: This requires thorough checking of the codebase, hence improve the task description and potentially talk to Ricordisamoa before offering this task!

Some MediaWiki extensions are missing "license-name" in extension.json or $wgExtensionCredits. This means no license is specified for them in Special:Version (e.g. https://en.wikipedia.org/wiki/Special:Version)

To fix this, you will need to make changes similar to https://gerrit.wikimedia.org/r/#/c/264553/ in the code bases of extensions. One needs to check the LICENSE or COPYING file to verify which license the extension has, and then add the license-name.

As well, some extensions are possibly missing a LICENSE or COPYING file, which would result in a broken license link.

You are expected to find three extensions missing license information (for example by checking Special:Version of some MediaWiki sites, or by checking the code via downloading the extension repositories via https://www.mediawiki.org/wiki/Download_from_Git#Download_all_extensions if you have enough internet bandwidth), write three separate patches fixing the problem, putting your patches into Wikimedia Gerrit, and receiving a +1 or a merge.

https://phabricator.wikimedia.org/T123943

Doc/Training; json, license; Andre, aude, Reedy

Pywikibot: Add one doctest to the library
Add one doctest to a docstring in the Pywikibot library

See https://phabricator.wikimedia.org/T120024

doctest are pieces of text in docstrings that look like interactive Python sessions.

They are included in the documentation generated by Sphinx, such as https://doc.wikimedia.org/pywikibot/api_ref/pywikibot.data.html#pywikibot.data.api.Request, allowing quicker understanding of how to use a class or function.

Pywikibot only has a few doctest. By adding more, we will help users quickly understand the functionality.

When you submit a change to be reviewed, it will automatically be checked for syntax errors with a report of any syntax errors will so you can fix them.

Pywikibot is a Python-based framework to write bots for MediaWiki. See https://www.mediawiki.org/wiki/Manual:Pywikibot for more information. See https://www.mediawiki.org/wiki/Manual:Pywikibot/PAWS for a easy way to explore Pywikibot. Patches can be submitted via Gerrit (you need a MediaWiki.org account). See https://www.mediawiki.org/wiki/Manual:Pywikibot/Gerrit. After you have successfully claimed this task on this site please do use the task in Phabricator for communication instead. This allows more PWB developers to be reached! General development questions can be asked on the Pywikibot mailing list at https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l and the #pywikibot IRC channel (see https://www.mediawiki.org/wiki/MediaWiki_on_IRC ). Code, Doc/Training; python, doctest; jayvdb

Fix 3 todos in MediaWiki code
A TODO is a reminder stored in a code comment. Do 3!

To complete a todo means to accomplish what the todo text says or to supersede it in another way, e.g. by executing the "order" that it contains (examples: "document this function", "move this method elsewhere", "This test method should be split").
 * Pick 3 todos from the list at https://doc.wikimedia.org/mediawiki-core/master/php/html/todo.html : each box is one todo, where the cell content briefly describes what you are expected to do and the header links the code file.
 * Understand them and if necessary edit the todo itself to clarify for future fixers.
 * Complete the todos you have selected and remove the todo notes from the code!

All the todos are in MediaWiki, so you have to follow the [general instructions](https://www.mediawiki.org/wiki/Google_Code-in_2015#Instructions_for_GCI_students) to [send a git patch](https://www.mediawiki.org/wiki/Git/Tutorial) in the [mediawiki/core repository](https://phabricator.wikimedia.org/diffusion/MW/). If you want, you can also select [todos from one of hundreds MediaWiki extensions](https://tools.wmflabs.org/mediawiki-mirror/html/dd/da0/todo.html), whose code is [in other mediawiki repositories](https://phabricator.wikimedia.org/diffusion/query/xSM3MiBclJ0T/#R). Code, Doc/Training; mediawiki, php, doxygen, todos, technical-debt; Nemo

Make MediaWiki documentation translatable for your first time: just one page!
You'll be upgrading existing English text and translations so that they are translatable with MediaWiki's Translate extension, which greatly improves translation workflow hence making coverage of translated docs vastly broader. You must not add new translations yourself, that's forbidden by the rules.

Detailed steps available at https://www.mediawiki.org/wiki/Project:Language_policy/Migration_list#Google_Code-in_task_description

Before submitting this task, you need: at least ONE page marked for translation; and a total of at least 20 paragraphs imported from a previous translation (technically, 20 contributions in the "Translations" namespace, as visible from your Special:Contributions page).

TODO: When your work on this task is approved, consider the [second task](https://codein.withgoogle.com/tasks/123) to show what you learnt! Doc/Training, Outreach/Research; i18n, wikitext, translation, multilingualism, l10n; Nemo

Localize Huggle UI
Some strings are hardcoded to English language. Make them localizable / translatable. See the full task description here: https://phabricator.wikimedia.org/T67950

In order to finish this task, you should find and replace at least 20 items that are currently hard-coded.

Huggle is a fast diff browser application intended for dealing with vandalism on Wikimedia projects, written in C++ (C++11 with Qt framework). More information: https://meta.wikimedia.org/wiki/Huggle and https://en.wikipedia.org/wiki/Wikipedia:Huggle.

Source code is available at https://github.com/huggle/huggle3-qt-lx and can be compiled on Linux, Windows and MacOS. Code; beginner; c++, l10n, i18n; Petr, Ankita

Blog about your GCI experience (findings and learnings) with Wikimedia
To claim this task, you must have completed at least 3 GCI Wikimedia tasks.

Take some time to reflect on the past GCI weeks with Wikimedia & share your thoughts with the world!

What was good? What did you learn, socially & technically? What could be improved?

Did you find enough interesting tasks? Which tasks did you miss? Was a task harder than expected + you are proud you solved it? How was the interaction on IRC, mailing lists, Phabricator, Gerrit? How easy was setting up a development environment? Which documentation pages would you improve for the next contributor, and how? (It's a wiki - you can edit it!)

Do you plan to continue contributing? Did you subscribe to some of [Wikimedia's technical mailing lists](https://lists.wikimedia.org/mailman/listinfo) to follow discussion among developers? What is the next thing you want to work on? Have you checked [Annoying little bugs](https://www.mediawiki.org/wiki/Annoying_little_bugs) for ideas?

These questions are just ideas - no need to answer (all of) them. But we do want to hear more from you than just "It was a great experience. Some tasks were harder than expected but I learned a lot." We helped you, you help us, so we can all learn together! :)

Publish your text on your personal blog (if you don't have one, consider creating one!) or any public place that you think is appropriate to reach more students like yourself. Your text must be published under a free [CC-BY or CC-BY-SA license](https://creativecommons.org/choose/). Including an image is welcome but not mandatory. You can write in English or your own language.

Please post the link (URL) in this GCI task.

Outreach/Research; gci, text, experience, summary; Andre, Nemo

Pywikibot: Improve docstrings to the Pywikibot library
Amend one docstring to completely and accurately summarise the behaviour of a method, documenting its inputs and outputs.

https://phabricator.wikimedia.org/T118423 Examples: https://gerrit.wikimedia.org/r/#/c/262668/ https://gerrit.wikimedia.org/r/#/c/262667/

Documentation is automatically extracted from the docstrings in the Pywikibot library, and converted into html using Sphinx to create https://doc.wikimedia.org/pywikibot/api_ref/index.html

Many methods in the library do not have adequate docstrings that describe the parameters, return type and exceptions that may occur.

These should be added to docstrings using epytext fields.

When you amend a docstring and submit it to Gerrit, a Jenkins job will automatically validate the docstring, and -1 the changeset if it includes syntax errors.

Pywikibot is a Python-based framework to write bots for MediaWiki. See https://www.mediawiki.org/wiki/Manual:Pywikibot for more information. Patches can be submitted via Gerrit (you need a MediaWiki.org account). See https://www.mediawiki.org/wiki/Manual:Pywikibot/Gerrit. After you have successfully claimed this task on this site please do use the task in Phabricator for communication instead. This allows more PWB developers to be reached! General development questions can be asked on the Pywikibot mailing list at https://lists.wikimedia.org/mailman/listinfo/pywikipedia-l and the #pywikibot IRC channel (see https://www.mediawiki.org/wiki/MediaWiki_on_IRC ).

Doc/Training; python, pywikibot; jayvdb

Add documentation to 3 of the most used undocumented pages on Commons
Wikimedia Commons is a file repository used amongst all the projects of the Wikimedia Foundation (including Wikipedia). We use many wikitext templates in them, but many are poorly documented and many of the most used templates on Commons do not have documentation pages that meet current community standards. The task is to find and document such pages:

1. List of templates in need of documentation can be found at [this page](https://commons.wikimedia.org/wiki/User:Jarekt/e), and I will try to keep it up to date. Also [this database query](http://quarry.wmflabs.org/query/6313) can be used. 2. Documenting templates should follow best Commons practices and should include:
 * /doc subpage and [Template:TemplateBox](https://commons.wikimedia.org/wiki/Template:TemplateBox).
 * description of all the input parameters (marked with brackets) and will require studying the template wikicode and possibly the code of pages using it.
 * All the categories should be at the /doc page and all the interwiki links should be done through [Wikidata](https://www.wikidata.org/).
 * If edits need to be done to protected templates than a message should be left at the template talk page with [Template:Edit_request](https://commons.wikimedia.org/wiki/Template:Edit_request).
 * Examples of well documented pages: [Template:Documentation/doc](https://commons.wikimedia.org/wiki/Template:Documentation/doc), [Template:Description/doc](https://commons.wikimedia.org/wiki/Template:Description/doc), [Template:Artwork/doc](https://commons.wikimedia.org/wiki/Template:Artwork/doc)

See also:

Code, Doc/Training; commons, templates, documentation; JarekT
 * https://phabricator.wikimedia.org/T120366 for more info and future discussion about this task
 * https://commons.wikimedia.org/wiki/Commons:TemplateData
 * https://commons.wikimedia.org/wiki/Special:MostTranscludedPages for live examples.