Reading/Multimedia/Retrospectives/2019-06-20

2019-06-20

Previous Action Items

• Use the Tuesday story meetings for talking through code health stuff if there are no stories to work on

• Revisit how to improve code health early to mid July

What are we doing that we should keep doing?

• releasing!

• • What is making this easier/possible? :) [it's not easier, but we're doing it anyway]

• • It's refreshing to go to SoS with something!

• • This has been fast! See below...

• Thanks for entrusting a more critical feature to me (even though it took time), this was good learning experience

• • MM: It would've taken all of us a good chunk of time - don't be so hard on yourself (and the work was good!)

What are we doing that we should stop doing?

• story meeting gets cancelled as often as not these days, perhaps we need to make it more of a when-we-need-it thing?

• • isn't that what it is right now? or would you prefer switching to <there is none, let's call one if needed>?

• • • Having a slot is easier than finding one adhoc

• • • The offsite may yield another meeting a la design/dev

• EG: Release pace is fast and hard to keep up with

• • I'm being really explicit with my work because I'm learning, and that takes time

What aren't we doing that we should start doing?

• making our code healthier (but we're about to start, hold onto your hats ...)

• • What is impeding this?

• • • release schedule

• • • We could set aside regular time to discuss architecture (there is also a ticket template for this)

• [not sure where this fits] Can we expect feedback from outside the team sooner for upcoming (other statements) release +1

• • We could have kicked Nirkatz sooner to get that feedback

• • It's not clear who the core fundamental user is for SDoC

• • • Power users vs casual users vs experienced commonists that don't know about wikidata

• • • This to me is a significant issue – so many other things are determined by this; if we don't know who we are building for it's hard to make a solid product... -- *we* know, but we've had to communicate to others who have disagreed

• • Toby's main concern is hitting 5m files

• MM: We've had code for existing qualifiers for months and we should have dealt with that earlier

• • This is obv Eric's fault

• Make (more concrete) plans for next releases - we're running out of other statements work

• • putting this in writing somewhere would be good - I'm always hazy on what the plan *is* (when deadlines are, etc)

• • Not just deadlines, also need more tasks - I have a vague idea of what needs to be done (Campaigns, additional datatypes support), but no detail (what things need to be configurable for campaigns, what datatypes, what do they need to look like)

• Take a close look/revise/be more explicit about the existing timeline for ML tagging (design research -> prototyping)

Action Items

• Max to make sure we talk about code health at offsite

• Use "cancelled" meetings to track architecture conversations, leverage Phab ticket template for architecture tickets

• Max to update Herald for new Milestone

• Cormac/Ramsey to find tickets for Campaigns and show them to the team so the team knows what we are working on next

• Pam/Ramsey/maybe Monte and Abby to take a close look/revise/be more explicit about the existing timeline for ML tagging (design research -> prototyping)