Parsing Team FY2015-16 (July 2015 to June 2016) Retrospective

Discussed issues

Offsite was a very good thing, very productive

We are a fully-remote team and have once-a-week hangouts, and a lot of our discussion is code-related.
Offsite enables in-person discussions, lets us spend time together, and get a bit more familiar with each other as people.
Enabled big-picture thinking
More in-depth detailed discussions
Helped reconcile our little projects, produced a roadmap we referenced throughout the year
Using flipcharts was very helpful
- We haven’t found a good remote replacement for this.
Don't change:
- Keep the length - five days
Change:
- Maybe we should have put the notes on the wiki
- Filed a bunch of tasks, but also put onto wiki for followup
- Spend some time at the end of each day doing housekeeping (notes on wiki, list of followup items); don’t want to go to wiki too soon
Followup:
- More advance travel planning: 6 or 12 months in advance, not 3
- Space out with hackathon and wikimedia summit, make it regular
- If there’s an editing wide offsite, would you also want a team-specific?
  - Yes. All-staff/dev-summit tend to be fairly packed.
  - Two team off-sites per year?
    - Scott: I’m away from family for 3 separate week+ events, which is limit for family (wikimania, all hands, offsite)
      - Wikimedia efforts to help out with families? Location, child-care, paying for travel…
    - Maybe 1 offsite plus one conference meetup

Parsoid still too hard set up for external non-WMF wikis

See complaints about this on Parsoid talk pages
Scott: is this a symptom of the collaboration issue? (ie, can we get more support help from other parts of WMF?)
- Tied to User support, community relations.
- We should be doing our own front-line support but perhaps there are resources that could help us
Arlo: I find it unpleasant to see messages on our talk page, “help me, I can’t set up Parsoid” and wish I had more time to help these people
- I want to make time to document this better
- Blocked by: prioritizing
Other projects do have tutorials at Wikimania and all-hands to help people, esp w/ initial install/setup. C. Scott proposed it for Wikimania this year and they didn’t accept it.
Tim: Problem is justifying that in terms of mission goals (which can be done, just not often talked about)
Things we don’t support
- Problems setting up password-protected wikis
- Installations on CentOS, windows
- MW core is not easy to set up either, but it’s much more documented
Followup:
- Internal discussions to identify things we can actually do.
- Next steps:
  - Get help from other teams
  - Prioritize: should we help people ad-hoc, or develop documentation in advance?

Not much collaboration with other teams other than VE(Editing) and Services

Collaboration with other teams to provide installation support for third parties
Tim: there could have been more collaboration with Language team on language converter, with mobile web team since they use our output and require features, but there hasn’t been much dialog with them
- CL or community team used to help with evangelizing changes to [?]
- SSS: Language seems to always be pressed for resources; but could talk to them and solicit avenues for collaboration after internal discussions.
- SSS: Still talk to Adam and attend services-parsing-reading meetings one-off but not consistently
Scott: What are the unknown opportunities? What are we missing by not having regular contact?
- Would be expensive to have N^2 meetings [to find out] but we have to go somewhat toward that.
Since the offsite works well for us, we could mandate that the offsite be with two teams that don’t collaborate very often. Agenda would not be 100% joint, but some overlap.
Other teams send out emails saying they have office hours, maybe we should have office hours too.
- Most useful at Dev summit: hearing other people present their roadmaps or tricky question, so I can see what overlap there could be [with the roadmap in my head].
- Scott: Structured conversation is more helpful for me than open-agenda office hours
Tim: have sought support on community engagement etc. via RFC meetings, but the relevant people weren’t there

Engagement with the RFC process

Many RFCs filed by Scott and handled ably by Tim!
The RFC process in general (Tim and Rob and ArchCom) has been really useful for cross-team coordination of outstanding questions and design issues
- Tim: wasn’t overworked; was good that we had those filed and it was really useful.
- Would like to see that continue
- Would like to have other team members file RFCs
SSS: Good place to have multiple concerns heard
Engineer-only, so we don’t get, for example, CL support
Scott: I like getting credit for writing the RFCs but the contents are from team discussions and I shouldn’t take credit for that.

Followup for Editing retrospective

Representative: Subbu

Org stability from last few months is good and should be sustained.
Facilitate cross-team / cross-dept collaboration
- to enable big-picture thinking and bigger projects than possible with a single team.
- maybe use team / dept. offsite meetings to achieve this.

Followup for Parsing team

Early offsite travel planning (6 months earlier instead of 3 months)
Better post-offsite followup
- Create tasks, notes, wiki pages instead of leaving raw notes in etherpad (csa followup: would be best to make this stuff easily discoverable to the community outside WMF as well)
Explore areas of collaboration with teams other than Services & VE
- Need internal discussion about this to get some clarity on this.
How often to do this retro? Consensus: once a year

Other raw notes

Key events over the year

Reorg, editing team created, broader parser team including Tim
New ED
Developer Summit.
October 2015 offsite
Tim joined the team
Kunal joined the team
Marc left the team
Changing from focusing on Parsoid to parsing in general
Scott: work with VE, autolink support, autolinking; con: VE team short-handed for feature dev.
Performance improvements
Deployed V3 API, VRS configuration changes, cross-team Flow/VE/CX/OCG.

Things that went well

Offsite was a very good thing, very productive
- Opportunity to meet face to face
- Week long thing

Scott: work with VE, magic link support, autolinking
- Worked well with VE Team

Developer summit was really useful
Engagement with the RFC process (especially many RFCs filed by Scott) (and handled ably by Tim!)
APB] All of our deployments in Parsoid were very smooth
Projects are easier to set up now for other people
- We have a ways to go here. Most of the comments on our talk page are about failures to get VE/Parsoid setup

Seems like more people outside our project are using VE and Parsoid
Kunal’s onboarding
Seems like we are doing well working together remotely.

Things that needs changing

Scott:
- Did more VE-ish work at expense of Parsing work
- Felt that VE was short-handed, overwhelmed with Maintenance.
Re-org and planning was based on hiring plan that wasn’t fulfilled, leading to shortages
Were a little bit rudderless over the past year
- Org, or team level? Yes.
- Had individual things to do but didn’t take on big-picture projects, eg:
  - Collaboration support for VE
  - Solutions for Chinese wikipedia
- On the other hand, we started some big projects at a local team level:
  - Depurate/tidy replacement/balancer
  - Visual diff
Projects are still too hard set up - see mostly complaints about this on our talk pages
- Could be because of more traffic?
Subbu: not enough feedback on managing remote and overall team issues?
Not much collaboration with other teams other than VE(Editing) and Services
Isolation/independence is often good (ie, insulated from org turmoil) but lingering concern about being out of the loop.

Who is representing the team in the team-of-teams?

Subbu.

Anyone else want to go or want someone else to go from Parsing?
- No

What is the #1 issue for Parsing to raise at the Editing Department retro?

Arlo: Org stability from last few months is the biggest thing. People coming and going was most disruptive, much more than re-org.
Scott: cross-team thing. Left hand talking to right hand. Big-picture thinking. (Can we decide on large projects involving multiple teams and get consensus and get them done?)
- I approve of evangelizing the use of off-site meetings as well!
Kunal: cross-team collaboration.
Tim: collaboration
Subbu: happy with collab. More practically, making travel decisions earlier to enable more face to face meetings.