Jump to content

Contributors/FY2016 Retrospectives/Collaboration

From mediawiki.org

Actions

[edit]

Full details at bottom of document.

  • Worked Well: Team discussions help in synchronizing everyone on product/engineering challenges and solutions
    • Several people: No action needed - keep it up
    • Do a better job updating Phab descriptions
  • Flow’s status and future - The question of what to do about resuming work on Flow remains unsettled.
    • Ongoing discussions within the team/organization/communities that will continue outside of this meeting.
  • Planning - short - and long-term - should be more defined and have some continuity
    • Clarify team mandate
    • Encourage WMF or at least Editing to have longer-term plans
  • Should we do more work on technical debt, especially backend?
    • Yes
  • Sometimes it’s really hard to find the tasks in phabricator - tasks in tasks, blocked, huge design task vs implementation tasks, some are split apart and tend to lose a little focus. it’s still hard to make Phabricator do what we want it to.
    • Get team to design, agree on, and follow a process for Phabricator (esp. Re: work decomposition, and two-axis tracking)
  • Worked well: Product + design scoping for Echo and special notifications made things easy to implement and release product features
    • Make sure everything is scoped, and repeat the successful process we used for Echo

Process

[edit]
  • The structure of the team retrospectives:
    • review key events and results over the time period
    • identify things that went well and should be preserved
    • identify things that should be changed
    • Vote on the things to figure out which ones are most important
    • Discuss those, including identify follow-up actions (to be reviewed at the next retro)
    • Process to select for more discussion:
      • Vote means:
        • take action (to preserve good and change bad)
        • to discuss in more depth
        • to escalate to Editing Department and up
      • Example Vote:
        • [JA, JFK, LBJ] Blah blah blah

What happened during the Fiscal Year

[edit]
  • Staffing changes
    • Danny left the team on October 1st, 2015
    • BenoĂŽt joined the team on October 1st (I’m still believing I’m here since years)
    • Joe joined the team on November 23rd, 2015
    • Kunal left the team on April 4th, 2016
    • Matthias left the team on July 1st, 2016
  • Huge changes in general in WMF (understatement)
  • Flow Reprioritization (in August)
    • Some communities have adopted Flow as a Beta feature
  • We had our first offsite in May 2016
    • (Also at Lyon, and in SF in January 2016 sort of)
  • Product Releases
    • Finished LiquidThreads->Flow conversion on MediaWiki.org, worked on it on other wikis.
    • Implemented and released Flow data dumps
    • In-progress on ExternalStore work (related to Flow); done on Beta, production coming.
    • Flow features
      • New topic title content format (links in topic title)
      • New and improved notifications
      • Pywikibot Flow support
    • Developer tooling work (MediaWiki-Vagrant)
    • Rewrote Flow’s front end (almost entirely)
    • Rewrote Echo’s front end + released huge major features
      • Yes, added significant value to users
    • Got rid of a lot of tech-debt in Flow and Echo
    • Cross-wiki notifications
      • Very well-received feature
    • Special:Notifications

What Worked

[edit]
  • Team Dynamics
    • Team works well together and has good morale.
    • 2 [SB, RK] Offsite!
    • 2 [ET, JM] Team dynamics are very very good.  More coherence and effectiveness in communications
      • IMO (RK) this is something that improved lots over the past year; e.g. compare January onsite-offsite with May offsite
    • 4 [MF, NW, SB, MS] Team discussions help in synchronizing everyone on product/engineering challenges and solutions
      • Usually
  • Tools and Process
    • 2 [MF, MS] Reorganization of phab boards plus use of Phlogiston (Phabricator reporting + burnup charts) (when it works) helped team understand progress towards goals.
    • We survived our PM-less period mostly OK
    • 4 [ET, NW, MS, JM] Product + design scoping for Echo and special notifications made things easy to implement and release product features
      • Good collaboration with design research yielded timely and useful information.
      • Great product design - specific, complete, and open to any feedback
    • User documentation has good feedback
    • Overall structure for team processes
  • Cross-team collaboration
    • Work with Research is really helpful
  • Products
    • Notification interface and message overhaul.
    • 1 [RK] Cross-wiki notifications
    • Notification bundling
    • Notifications re-sorting

What Was Confusing/Blocking

[edit]
  • Quarterly Review
    • 2 [RK, BE] Quarterly review meeting felt compressed, with different teams taking wildly different amounts of time. Perhaps we could:
    • Make it longer?
    • Bring back the dry-run/rehearsal?
  • Plans
    • 6 [JM, NW, MS, BE, RK, SB] Flow’s status and future - The question of what to do about resuming work on Flow remains unsettled.
      • RK: I’ll take some of the blame for that; the good news is it’s becoming slightly more settled
    • 5 [BE, MS, ET, JM, SB]  Planning - short - and long-term - should be more defined and has some continuity
    • 5 [MF, MF, ET, RK, SB]  Should we do more work on technical debt, especially backend?
    • 1 [MF] A couple cases where product and tech got out of sync (seen time and alerts/notices)
  • Tools and Process
    • 5 [MS, JM, BE, NW, JM] Sometimes it’s really hard to find the tasks in phabricator - tasks in tasks, blocked, huge design task vs implementation tasks, some are split apart and tend to lose a little focus. it’s still hard to make Phabricator do what we want it to.
    • 3 [MF, NW, ET] Relatedly, we can make improvements to triage.
      • The more we triage the easier it becomes
    • This also affects the alerts/notices thing, since a clear Phabricator tree helps make sure we’re feature-complete (or as feature-complete as this release is supposed to be) before deployment.
    • Related-edly, when products/features are scoped, we do great - we talked before about finding ways to organize full feature task-list for organization and “checklist”
    • 4 [RK, BE, NW, BE] Sometimes it is confusing to know what will be released and when. We mostly have to wait for standups to act on that and we sometimes don’t really document it.
      • You can check “included in” in Gerrit, or the Release Tagger Bot which includes the date on Phabricator (sometimes bot gets confused, though, due to secondary patches, so always worth checking)
      • RoanK: I can teach/document tricks for this to/for the CL team if you like
      • BenoĂŽtE: There is sometimes a time gap between the decision and the Gerrit (or any bot) notice. That’s was what I wanted to express.
      • RoanK: Right, that kind of stuff mostly happens in my head right now, which is suboptimal. I’m thinking maybe we can reform the pre-deployment meeting and make that more of an ongoing “what’s planned to be in wmfN” list that we/I maintain throughout the week. Let’s experiment with that this week?

Actions

[edit]
  • Worked well: 4 [MF, NW, SB, MS] Team discussions help in synchronizing everyone on product/engineering challenges and solutions
    • Several people: No action needed - keep it up
    • Matt: several times it didn’t work [...]
    • Moriel: all about our process, which works well except when it doesn’t, and when it doesn’t, it [fails hard (as opposed to fail gently)]
    • Moriel: when we have features, organize the [.] with a checklist so we can use it in our discussions to make sure nobody is assuming or missing something
    • Joe: That’s a solution, but Problem is the Phabricator item below
      • Matthew: not so much Phab but [engineers] knowing who [just engineering or also, Joe, Pau, CLs] needs to be involved
      • Moriel: a few cases of misunderstandings between engineering and product
    • Joe: is there a checklist or morning meeting thing or release meeting thing to catch these?
    • Matthew: make sure Joe and Pau are in the meeting and that they understand the impact of what we discuss
    • Nick: do a better job updating Phab descriptions
      • Description should always [represent the current status of the task, incorporating discussion/comments]
      • BenoĂŽt: this is a problem for users too, people outside the team
    • Matt: Not just Product, but also sometimes CLs [out of the loop]
  • Change: 6 [JM, NW, MS, BE, RK, SB] Flow’s status and future - The question of what to do about resuming work on Flow remains unsettled.
    • Ongoing discussions within the team/organization/communities that will continue outside of this meeting.
  • Change: 5 [BE, MS, ET, JM, SB]  Planning - short - and long-term - should be more defined and have some continuity
    • Joe: what are people thinking here?  About the whole Editing department?  More structure from editing department?
    • Many: This is an org-wide problem.
    • Roan: team planning isn’t very promising.
    • What exactly does the team need from Editing?  Room for internal solution, or external?
      • Roan: team has been scrambling to stay ahead with prioritization.  Mandate is broad.  Leadership turnover.
      • Nick: keep asking for five to ten year "all potential-plans", everything the org and movement would like to fix, so we can do pros and cons, and justify long-term development.
        • BenoĂŽt: +1
      • Moriel: … we work on cool stuff, but project to project.  What is the team about?  Collaboration is vague.  Political areas we cover (discussion pages, watchlists)
        • Nick/BenoĂŽt (non-verbal): BIG +1 to "watchlist" - many teams keep talking about, and then punting, the problem of "5 different Feed systems". This requires long-term plans.
      • Matthew: not just that we’re bad at planning; fundamental disagreements on how planning should work.  5-10 year plan vs pivot every quarter.
    • Actions (proposed by RK):
      • Clarify team mandate
      • Encourage WMF or at least Editing to have longer-term plans
  • Change: 5 [MF, MF, ET, RK, SB]  Should we do more work on technical debt, especially backend?
    • Yes [MF, RK, MS, ET, NW, BE (especially on what people expect)
    • No
    • It’s complicated: JM (“didn’t we do a lot already?”)
  • Change: 5 [MS, JM, BE, NW, JM] Sometimes it’s really hard to find the tasks in phabricator - tasks in tasks, blocked, huge design task vs implementation tasks, some are split apart and tend to lose a little focus. it’s still hard to make Phabricator do what we want it to.
    • Moriel: explore checklists
    • Joe: can’t organize by two axis (by process or by feature, not both)
    • BenoĂŽt (non-verbal): We need to define a protocol for Phabricator, and have it reviewed once a week (is that task well documented?)
    • Matthew: need to use better ways to organize (checklists vs sub-tasks vs components)
    • Action:
      • Get team to design, agree on, and follow a process for Phabricator (esp. Re: work decomposition, and two-axis tracking)
  • Worked well: 4 [ET, NW, MS, JM] Product + design scoping for Echo and special notifications made things easy to implement and release product features
    • Moriel: related to everything we talked about; if we know that we have a feature we’re coming up with, concentrate on clear scoping, checklist of everything, MVC, steps.
    • Action: make sure everything is scoped, and repeat the successful process we used for Echo

Follow-Up

[edit]
  • Next retro at this level?
    • In a quarter.
    • Editing retro: August 2nd, 10:30-11:50 Pacific (timing still somewhat tentative)
      • Nick would like to observe
  • Publishing the notes
    • Share to editing teams ASAP (maybe within a week)
    • Share to mediawiki
      • Joel to create a tracking task for team to review
Retrieved from "https://www.mediawiki.org/w/index.php?title=Contributors/FY2016_Retrospectives/Collaboration&oldid=2484505"