Technical Team

The technical team is responsible for maintaining and extending the technical infrastructure of The Programming Historian, including but not limited to the Jekyll/GitHub pages deployment, page template styling, and integration with 3rd-party services.

The technical team holds monthly Skype calls organized by the team leads, who are also responsible for tracking all tech team assignments and training other team members.

Team Leads

• Zoe LeBlanc

Team members

• Jennifer Isasi
• Anna-Maria Sichani
• Alex Wermer-Colan

Issue triage workflow

General issue workflow

1. If any member of the full editorial team opens an issue that has a technical component relating to the site's Jekyll code (particularly code in the _layouts or _includes folders), they must add the technical label to the lesson, and notify the technical team by including @programminghistorian/technical-team in the issue description. This does not mean that technical issues must be solved only by the technical team - if a member of the full editorial team is able to draft a PR to fix an issue, we will gladly review it!
2. Problems with code examples in a lesson are the purview of the appropriate editorial team for that lesson. Travis errors should primarily be addressed by editorial teams first (reading the error messages carefully, checking YAML formatting against the editorial guidelines.) Only if editorial teams are unable to solve these issues should they they contact the technical team for extra help.
3. If a member of the Technical team has the expertise and bandwidth to solve the issue, they will claim responsibility for it by adding themselves as an assignee on the ticket. At least once a week, the technical team lead will review all issues with the technical label and coordinate with the other members of the team to make sure a primary is assigned to any tickets that have not yet been claimed. Coordination will be done on the tech team's Slack team https://programminghistorian.slack.com
   • The technical team will engage in pair programming, where less experienced members will be seconded by a more experienced team member who will help them prepare a PR and review it with them.
   • When possible, more experienced members are encouraged to take on the secondary role, and proactively pair with less experienced members so that they may have the opportunity to expand their skills.
4. When accepting responsibility for an issue, members will post a comment on the issue with a proposed deadline by which they will submit a PR. Team members should commit to either submitting a fix by that deadline, or posting a progress report by that date. *Aim to have this date be within three weeks of accepting the issue

High complexity issues / feature requests

These are tickets where some combination of these conditions is true:

1. There is no immediate solution with a clear implementation
2. Possible implementations fall outside the current skill set of the team
3. The feature falls outside the scope of the current technical architecture of the site

The technical lead will take responsibility for assessing the issue with the rest of the technical team by the next scheduled technical team call, and reporting this assessment back to the full editorial team via GitHub.

The technical team can allocate its limited bandwidth to approximately one high complexity site enhancement every four months. This current 4-month priority will be listed on this page. Other high-complexity feature requests will be closed and added to the backlog list on this page, to be reopened when there is capacity to manage them. Prioritizing these feature requests during 6-month sprints will be done in consultation with the full editorial team.

Fall 2020 Priority

TBD

New feature backlog

1. Lower contrast CSS option #1524
2. strict liquid filtering #1116
3. In-lesson navigation #1023
4. Integrated translation tracking software #1571