Technical Team June Meeting - 18 June 2020

[mdlincoln]

18 June 2020 - 10am Eastern Time

Agenda

• discuss tech team leadership transition re Matt Lincoln retirement #1761
• Lessons' banners layout - review and implementation  #1767 is closed! Thanks @amsichani for the PR and @walshbr for reviewing, and @jenniferisasi for design discussion
• Still waiting on a new PR for Progress reporting for Lesson Sequences #1525 by @amsichani @jenniferisasi (waiting on PR for these - if you need help, please ask for it before meeting. I'd like these to be resolved ASAP as the formatting decision has been made and the change is straightforward)
• Open a wiki page documenting how to start up a new language section #1737 @mdlincoln and @amsichani figuring out documentation for new user team (incl. current Portuguese tracking ticket PT technical onboarding #1802)
• Preventing Build Errors on ph-submissions #1795 preventing build errors on ph-submissions @walshbr
• Service Agreement between ProgHist Ltd and Existing Publications #1704 review service agreement for existing teams (will send draft to slack team)

[drjwbaker]

Further to the conversation at #1729 if the @programminghistorian/technical-team is focused on maintaining infrastructure (which I think you should be), I'd like to see the Tech Team periodically audit the health of the tech on which our publications rely (e.g. are they still maintained tech, is there a big upgrade coming that we need to be attentive to, is there stuff we might need to pay for soon, et cetera) and report that back to the wider PH team.

[amsichani]

I am afraid I won't be able to attend this meeting. I ve already informed @mdlincoln on a pending ticket from my part - I am happy to finish it in the (near?) future , sorry I can't commit to a date at this point.

[mdlincoln]

Further notes from the meeting:

• @ZoeLeBlanc will be taking over as team leader

• In response to @drjwbaker, we probably should have at least an annual review of the service integrations. We also are sensitive to how we might change our technical documentation regarding how to do PRs, reviews etc. since GitHub changes its interface incrementally over time. We discussed ways to change our docs so that we point as often as possible to GitHub's own maintained documentation rather than taking lots of screenshots, so that we don't end up duplicating it (and duplicating that labor). Instead, we make sure that our docs come from the perspective of our workflow, and point more actively to github's documentation instead.

• @walshbr and @ZoeLeBlanc noted how useful pair programming has been over the past month for getting more of the team up to speed but that pair programming is fundamentally slower, so we will need to work carefully to set expectations about how quickly new tickets will be closed, and to be careful to provide regular progress updates so that it does not appear that tickets have been forgotten.