Skip to content

Minutes

Jump to bottom
Romain Deltour edited this page Nov 5, 2018 · 14 revisions

EpubCheck developers meetings

2018-11-05

Pariticipants: Avneesh, Daniel, Matt, Romain, Tom.

Core team internal communication

We discussed how we wanted to organize the communication within the core development team:

  • weekly text chats using DAISY's #epubcheck Slack channel
  • ad-hoc audio calls when needed
  • Slack is used mostly for transient communication
  • Resolutions and important information should be summarized in the meeting minutes on the wiki

We also discussed Slack best practices:

  • we'll use a unique #epucheck channel as long as it works
  • we may add additional feature-specific Slack channels if discussions become difficult to manage in a single channel
  • we won't use Slack's threading functionality, which is deemed more confusing than useful
  • significant message editing is discouraged, or should be explicitly mentioned in the main discussion thread
  • we'll use explicit '+1' messages rather than thumbs-up emoji reactions to upvoting important decisions (for accessibility reasons)

Issue tracker and project management

We discussed the issue labelling and potential use of a column-based issue management tool (Waffle, Zenhub, GitHub projects). Zenhub might be too complex for our use; GitHub projects isn't accessible. For accessibility, we want all the information to be available from the standard issue tracker and labels. Waffle could be a good option, as it is a pure visualization of GitHub's existing dataset.

Resolution:

  • apply the labels proposed in #862 (pending comments from Daniel)
  • stick to issues/labels/milestones as the primary source of information
  • experiment with Waffle as an optional layer for visual issue management

4.1.0 release

Maintenance release, no big new features. The task is basically to wrap-up the work done by previous maintainers (and contributors). No plans to kill features like EDUPUB (yet). We should check that no "invalid" EPUB 3.1 validation is introduced.

Romain will handle 4.1.0, getting help from Daniel or Tom only if needed. The deadline is 3d week of November.

This task should not delay the work on EPUB 3.2.

A quick developers guide should be written on how to manage branches for working on multiple versions/features in parallel.

Status udpate and onboarding experience from Daniel & Tom

Status: exploring the source code, existing pull requests, EPUB 3.2 specs. Still quite low on the learning curve. Discussion will continue on Slack; Romain will answer questions and/or setup audio calls when requested.

Tom looked at issue #859 and the warnings appear to be raised at instantiation (and not for each test run). To be investigated.

Preparing and starting the work on EPUB 3.2

The first step is to identify the list of stuff that changed (compared to EPUB 3.0.1) and need to be implemented. Matt will handle this task, with assistance from Daniel and Tom. Initial work will be done based on an Google Doc draft created by Matt during the 3.1 work.

The basic workflow will be:

  • identify a change requiring to be implemented in epubcheck
  • create a new issue
  • someone else reviews and sets the label accepted
  • someone voluntarily takes the issue, or we assign someone during our weekly chat
  • this person thinks about the issue, possibly discusses it, and then sets the waiting for review or ready for implem labels

2018-10-08

Participants: Avneesh, Daniel, Romain.

Work plan until December

  1. set up infrastructure.
    • Organize the issues + review the labelling strategy
    • Move the repository to W3C.
    • Do we need to rename the Java namespaces (legacy adobe and IDPF names). This can be handled in phase 2 during the code clean up.
    • Infrastructure work can start Before TPAC
  2. Maintenance release for existing fixes (v4.10)
    • Deadline is November.
  3. EPUBCheck updated to EPUB 3.2 - alpha release.
    • In December or early January.

Development “infrastructure”

To help us triage GitHub issues, create "epics" meta-issues (group related issues, identify dependencies / development critical path, manage separate Pull Requests, etc.), and ultimately assign tasks / action items within a timeline, using:

...but there are also more powerful alternatives:

Romain knows Huboard; Daniel knows ZenHub; We all know Waffle, Trello, GitHub Projects.

Proposal (to be discussed further): exclude Trello (too disconnected from GitHub, more suitable for higher-level project management), exclude Waffle (there are slightly better alternatives than this simple GitHub "overlay"), exclude GitHub Projects (limited feature-set), consider Huboard and Zenhub (we need to verify accessibility).

ACTION ITEM: Avneesh to check screen reader accessibility of the current Github Projects (Avneesh already uses GitHub issue tracker label-based filtering, etc.)

ACTION ITEM: Romain to explore ZenHub and setup a test instance

We discussed the human resources needed to achieve the EPUB 3.2 milestone. ACTION ITEM: Romain should get in touch with the team and kick-off the development.

Communication

Communication channels for development team:

  • the development team can use the #epubcheck Slack channel (in the daisy-dev orgnization)
    • ad-hoc audio calls when necessary
  • setup a weekly timeframe for developers chat
  • the discussions will be summarized and published on a wiki page, under the heading of the date of call/interaction.

Communication call with steering committee:

  • schedule a monthly audio call on Zoom.
  • Create EPUBCheck twitter account? (requires approval of Luc/Tzviya). Its objective is to keep the public updated about the technical developments.
  • We should formulate plan for providing some light weight updates that can be used by Luc/Tzviya for marketing. It may be posted on a blog or news, social media page etc.

ACTION ITEM: Avneesh to get in touch with Luc and Tzviya to invoke discussions on these topics.

Clone this wiki locally