On Fri, Dec 16, 2016 at 12:51 AM, Pine W <[email protected]> wrote:
> The issue which I am attempting to address is not a UI change itself > (good or bad) but rather communication about proposed and upcoming UI > changes. Communication of proposals and changes is a problem indeed. Not just for UX, the problem is common to other areas of development. We are trying to define the good practices in the Technical Collaboration Guideline, at Milestone communication <https://www.mediawiki.org/wiki/Technical_Collaboration_Guideline/Milestone_communication> . This is how I personally think that the technical solution should work, taking UI as an example. * A UX review checkpoint exists, consisting of a wiki page in MediaWiki.org where current and past proposals reviewed are logged. Users can see which proposals are currently under review (with deadlines optionally) and which ones have been resolved and when. * Each proposal lives in its own URL (a wiki page, a Phabricator task) where rationale, updates, and discussion happens. * Anyone can subscribe to the UX Reviews newsletter <https://www.mediawiki.org/wiki/Extension:Newsletter>. Teams initiating or resolving a proposal will announce the move in the newsletter. Users subscribe to this newsletter will receive updates related exclusively to UX reviews, no more, no less. Imagine the same approach for new projects/features, security reviews, new betas, release plans... This is a good way to scale communications without drowning central spaces like Tech News, wikitech-ambassadors or your nearest Village Pump. This is also a good way to attract specialized contributors and help them shine where they can contribute best (i.e. design students or professionals happy to volunteer) as opposed to trying to convince them to follow Tech News, wikitech-ambassadors or your nearest Village Pump. This idea doesn't define whether a change of color shade merits a review or whether the review should last three months, but it helps creating focused spaces where productive collaboration may happen sooner and more often without everybody dying out of exasperation or exhaustion. -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
