User:Sharihareswara (WMF)/TODO

Sumana Harihareswara's TODO list General, braindump, somewhat prioritized, necessarily incomplete.

Continuing

 * Every Monday, help Mark prep for bug triages, set work priorities
 * Mentor, keep systematic track of incoming contributors
 * Work with Mark Hershberger (and the rest of the Development Community group) to improve bug triage and reduce the unreviewed commit backlog
 * Hackathon prep
 * Give Victor Grigas the schedule
 * add WMFers to the featured attendees list
 * Get AHP on hackathon site
 * Reply re recruiting and note that Karen C is available for recruiting
 * continue prepping document with parking facts, etc. bring your laptop, to send attendees as PDF? to send 2 days before event
 * prep tutorials with staff in person
 * 1:1, bug triage meeting, TL;DR meeting, platform engineering meeting, commit access queue meeting
 * GSoC wrapup & recruiting
 * Push on merges, ArchiveLinks... shellbug?
 * Follow up on User:MaxSem/GSoC analysis & notes from NOLA Hackathon/Sunday
 * Women's tech event prep
 * Schedule it in February
 * outreach to local women's colleges & women-in-CS orgs
 * info@phparch.com

New/one-time

 * figure out UCOSP participation (project, mentor(s))
 * sometime this month, ask office IT to take ownership re #wmfstaff privacy

Soon

 * Tell people to propose to LinuxTag?
 * look in budget/ask Erik about 6th possible hackathon this fiscal year
 * Look into Bugzilla management ops stuff, consult with RobLa
 * * Ask Siebrand about lessons learned from doing a new contributors training in Pune
 * Get mediawiki-l, mediawiki-enterprise, wikitech-l list adminship
 * Investigate contributor agreement/ToS
 * find out if http://wiki.ubc.ca/Help:Widgets/SlideShare http://www.mediawikiwidgets.org/Widget:SlideShare is good with the new HTML5 magic
 * Send out hackathon metrics thoughts?
 * do detective work re Reflect extension
 * talk with developers who have been reverted most (proportionally) recently about improving
 * re pywikipediabot commit access: write a guide - explain how to get it; document on their manual
 * ask http://wiki.ubc.ca/Special:Version about their extensions
 * help fundraising team liaise with Wikimedia, Drupal, CiviCRM, etc. communities

Recruit

 * Sumana to document best practices for aiding enthusiastic general & specifically driven volunteers
 * find PhotoCommons testers and users, & suggest people port it to other CMSes
 * find WikiLove localizers
 * find Narayam testers
 * find someone to shepherd Josh's page-by-page-auth extension
 * reach out to http://wikiindex.org/User:Gwsuperfan
 * HipHop: Sumana will target Fedora and Ubuntu for recruiting packagers, maybe CentOS (RPMs anyway)
 * (Sumana to help get contributors to package HipHop for different *n*x distros, to make it easier to work with)
 * testers for MediaWiki OpenID extension
 * reach out to http://phpsp.org.br/
 * More on Chad's global config RfC
 * redlink off WMF GenEng page
 * recruit volunteers to work on this
 * Get into gadgets/user scripts community
 * Get into extensions community
 * Get into toolservers community
 * Get privileges on mwbot project
 * Get into templates community
 * Prepare for 1.19 beta testing by compiling a list of people who reported problems in 1.17.0, 1.17.1 & 1.18.0. Ask them to be on-call to test.
 * Mark to compile the list -- Amgine, et al.
 * Sumana to possibly ask them to test trunk versions, definitely ask them to test the 1.19 branch.
 * Discuss testing community stuff with Mark & Ashar (testing mailing list? meetings?)

Longer-term
My goal is to facilitate volunteer contributions, and there are a few missing parts right now that slow me down, and slow down volunteers who want to help. The main problems I'm worried about:
 * Code review in general. For example, per MediaWiki roadmap/1.18/Revision report, we've been stuck at 46 to-review revisions tagged 1.18 for about a week.  And the http://toolserver.org/~bryan/stats/codereview-status-diff.png chart is worrying.
 * Ideas: I know RobLa is working on this. Some ideas: Get aggressive about hiring the security engineer (who will do code review)...
 * We are simply not good enough at reviewing and responding to new volunteers' contributions quickly. They usually come through Bugzilla, and we have 146 MediaWiki patches in BZ waiting for review:  https://bugzilla.wikimedia.org/buglist.cgi?keywords=patch%2C%20need-review%2C%20&keywords_type=allwords&order=Last%20Changed&type0-0-6=matches&field0-0-4=short_desc&query_format=advanced&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=MediaWiki&type0-0-2=substring .  I predict the Bugzilla patch queue will continue to exist even after we switch to git, because many newbies won't learn git until after they start contributing patches.
 * Ideas: Mark and I try to get through twenty patches each week (we failed at sprinting in early November; maybe we need a daily meeting?); I encourage a patch review squad, especially new developers who don't have as many commitments already; do it at hackathons as a way to teach code review?
 * Our best source of interested developers will be MediaWiki administrators. But we don't provide a good pipeline for them to get involved in development.  And it's hard for administrators to even learn of the existence of extensions and to intuit which extensions would be best to install, and thus to get on the path to becoming power users (and possibly developers).
 * Ideas: get a pointer onto the last page of the install screen that to links to an extensions portal on mediawiki.org, and mention the four that people really ought to install, like Cite; do a sweep of some "powered by MediaWiki" sites and their Special:Version pages and contact them to suggest extensions to install; publicize Gadgets more when ResourceLoader 2 comes out, and suggest to them that they use the main gadgets repo...


 * Build awareness of our Great Movement Projects & Strategic Opportunities in the existing volunteer development community and in new & returning volunteers -- important
 * Goal for the TL;DR team - not just about increasing contribution, also aligning community around our goals.
 * Sumana to author post(s) about priorities from whitepaper (help from Guillaume), to reach out to tech communities, encourage volunteers
 * get Debian/Ubuntu pkg of MediaWiki onto 1.18 - low priority.
 * look at Ubuntu/Debian MediaWiki package, apt-get source, see folder of patches
 * Get toolserver account to make, host tools to gather & display stats re SVN & bugzilla
 * Get in-person MediaWiki ramp-up help from engineers, and synthesize that into training documents for future installfests
 * find PHP students/kids to encourage into MediaWiki at schools
 * help them with travel to hackathons & invite them
 * Build my knowledge of conferences, distribution channels, and other means by which we can find potential volunteers, and running pilot events as seems feasible.
 * PHPNW: (Manchester, UK) http://conference.phpnw.org.uk/phpnw11/
 * Codemash (not just PHP), Sandusky, OH January
 * Dutch PHP Conference, Amsterdam, usually June
 * php|tek, Chicago, IL, usually May
 * PHP Community Conference, Nashville, usually April
 * PHP Benelux, Belgium, usually January
 * POSSCON (not just PHP), Columbia, SC, usually Feb or March
 * Confoo (not just PHP), Montreal, usually Feb
 * http://www.catchafire.org/org_home
 * try to get pro bono security pentesting? maybe from Matasano or a similar firm
 * Consider PCF, Mozilla, GNOME, etc for QA infrastructure idea -- mailing list, etc.
 * think, and soon, about community/contributor guidelines, both behavioral & coding
 * Check how Mozilla & Canonical do Agile, + Launchpad, OpenStack & other open source Agile projects
 * investigate Mozilla (they started requiring tests a few years ago) on how they get volunteers to write tests
 * shell bugs: Communication plan. E.g. foundation-l, & think about longterm messaging for all admins, for notifications, & translations.
 * watch out for shell bug process & organize volunteer sprints
 * chase deployment privilege separation
 * travel plans -- submit proposals
 * Ramp up on my technical knowledge of MediaWiki
 * look at PHPStorm and ask jetbrains whether they want to collaborate on MediaWiki stuff somehow
 * http://blog.jetbrains.com/webide/2011/11/phpstorm-3-0-keep-your-code-in-its-best-shape/
 * http://blog.jetbrains.com/webide/

Recruit

 * look at getting volunteers to help Siebrand re WikiBhasha - removing cruft, adding support for Google MT
 * look at getting ideas, testing re hackpad as editor
 * look into code review mentorship program
 * ask ops to contribute upstream their custom hacks to OTRS
 * look up Dmitriy Sintsov,, the evil IP address, Banaticus & Billinghurst re: music sheets plugin
 * documentation: per RobLa's suggestion:
 * I would suggest is that we potentially recruit people who work on the more technical parts of enwiki, rather than just focusing on people who are already on mediawiki.org. Maybe start at "Village Pump (technical)" and then also see what editors are active on things like template help pages and other scarier parts of the system.


 * and Zak's plan: User:Zakgreant/Tech Docs Plan (2011-01/P6M)
 * recruit user Pinky, MattJ, & Lhridley
 * reach out to JeLuF, Jojo, aran per ohloh
 * http://vufind.org/
 * reach out to userscripts community
 * Zend & phpcloud
 * reach out to infochimps with Dario
 * http://wiki.dreamhost.com/Special:Version 1.16.5
 * contact Meredith Farkas to suggest upgrade* contact http://adastechnicalbooks.indiebound.com/contact-us re GLAM outreach
 * webmaster@undefinedhiddeninthesand.com re upgrade, and sheet music plugin Extension:Score
 * couchsurfing wiki -- it's at 1.15 http://wiki.couchsurfing.com/en/Special:Version and they have an extension they should put on mediawiki.org http://wiki.couchsurfing.com/en/Google_Calendar_MediaWiki_plugin
 * look at http://www.custis.ru/html/news.htm to recruit (why? made a note to myself about it on 30 Sept 2011)
 * Make our CREDITS file more complete, perhaps by looking at commit summaries.