Development process improvement/Communications recommendations


 * http://thread.gmane.org/gmane.org.wikimedia.foundation/46081
 * http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/49535
 * http://lwn.net/Articles/383945/
 * Communication

Mailing lists

 * Mailing lists
 * https://lists.wikimedia.org/mailman/listinfo
 * http://www.infodisiac.com/Wikipedia/ScanMail/

(not included: pywikipediabot, toolserver)

IRC channels

 * MediaWiki on IRC

Wikis

 * http://www.mediawiki.org
 * http://meta.wikimedia.org
 * http://usability.wikimedia.org
 * http://wikitech.wikimedia.org
 * http://wikimediafoundation.org

Blogs

 * http://blog.wikimedia.org
 * http://techblog.wikimedia.org
 * personal blogs

Other tools

 * private email
 * face-to-face, phone & video discussions
 * RT
 * Xplanner
 * http://prototype.wikimedia.org/en-idea/ideatorrent/
 * CodeReview

Issues

 * Lack of transparency from WMF engineering towards the world
 * Mixing of MediaWiki development and Wikimedia-specific development & operations
 * Difficulty for unpaid developers & editors to know what's going on in WMF projects, and to have an impact on those projects
 * Lack of appeal / outreach / onboarding process for prospective and new developers
 * Synchronous communication (online or IRL) excludes remote or absent participants

Peers

 * developers
 * WMF staff & management (including non-developer staff involved in software development: designers, product managers, EPMs, etc.)

Users

 * Wikimedia "editors" (e.g. Wikimedia participants not involved in development)
 * general public (including the press & donors)
 * API users
 * Data dumps users
 * users of MediaWiki outside Wikimedia (including enterprise use)

Peers

 * RfCs, peer discussion
 * report & check-in (i.e. person status)

Users

 * support request
 * bug report
 * feature request
 * call for testing
 * user research
 * strategic product research

Peers & Users

 * reference, documentation (including project status & progress)
 * announcement

Process notes

 * task tracking
 * scheduling at various levels (roadmap, target versions, milestones, daily scrums...)
 * bug squashing periods
 * CodeReview periods
 * lightweight general process applicable to all developers + additional processes for paid staff if necessary (but should still remain fairly lightweight)