Agreement on when and how Product teams communicate
Closed, ResolvedPublic

Description

Simple, high-level version: https://www.mediawiki.org/wiki/User:Keegan_(WMF)/Agreement2

Nothing revolutionary: a product team member or CL keeps community members updated throughout a product's cycle, on relevant wiki pages, mailing lists, and broader audience platforms like Village Pumps as necessary.

Related Objects

StatusAssignedTask
ResolvedQgil
ResolvedKeegan
ResolvedKeegan
DuplicateNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
OpenNone
DuplicateNone
ResolvedKeegan
OpenNone
InvalidKeegan
DeclinedKeegan
ResolvedKeegan
OpenNone
ResolvedKeegan
DeclinedNone
Resolved Moushira
StalledNone
OpenNone
ResolvedQgil
ResolvedKeegan
ResolvedKeegan
OpenNone
Resolved Moushira
ResolvedQuiddity
Keegan created this task.Apr 13 2016, 7:46 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 13 2016, 7:46 PM

Just need to run this by product audience managers, will do at the end of the month when I'm in SF (April).

Elitre added a subscriber: Elitre.Apr 14 2016, 11:17 AM
Qgil added a subscriber: Qgil.EditedApr 15 2016, 2:48 PM

Thank you for this draft.

While all the details about the Technical Collaboration Guideline might be difficult to memorize, the principles behind it should be simple and memorable, worth spelling them out.

Here the principles could be:

  • Development teams make calls for feedback at specific project stages.
  • The main goal is to find potential blockers.
  • The calls are made in a systematic way.
  • All stakeholders participate in the same calls.
  • Results of each call are documented in the project plan.

I think the current list at https://www.mediawiki.org/wiki/User:Keegan_(WMF)/Agreement2 is consistent with this principles, but could be simpler and clearer, also at defining the kind of feedback expected.

For instance (not intended to be final copy):

  1. A project proposal. Check against principles, strategy, existing plans.
  2. A design concept. Usability, look & feel.
  3. Translatable content. Usability, i18n, L10n.
  4. A prototype. Usability, performance, bugs.
  5. A release plan. Identification of early and late adopters.
  6. A beta in production. Last details before final release.
Qgil triaged this task as Normal priority.Apr 15 2016, 2:48 PM
Qgil renamed this task from Agreement on when and how Product teams communicate. to Agreement on when and how Product teams communicate.

Adding some scope in the examples as per @Qgil's suggestions, makes sense to me. Will refine when I go over it with product people.

Qgil added a comment.May 10 2016, 10:34 AM
This comment was removed by Qgil.