A watch that runs alongside console-printer could be useful for testing, and as another example watch. Having it be interactive would be valuable for testing new printers.

e.g. possibly:

$ node example_scripts/interactive.js
Commands: print, new, check
> new
Project: Example Ticket
Title: Testing out the interactive example
...

It should have no extra dependencies if possible (not sure how text input works in Node).

Code the printer interface for the mini thermal receipt printer.
https://www.adafruit.com/product/597

The original intent of this project was to use this in conjunction with the Tessel 2, which seems easiest because it offers a Node interface.
https://www.hackster.io/zaccolley/thermal-printer-module-for-tessel-74293b

:P

Printers should have a test function, that prints a pseudo "printer test page" like in real printers.

The readme should include how to install this from npm, and a link to the project there.
https://www.npmjs.com/package/ticket-printer

Should users be able to add watches after they started the ActivityWatcher?

It should be fairly fundamental to do, and could help for watches that are added interactively, or have a delay to their startup.

However, this functionality could induce more headaches, if ActivityWatcher continues to get more complicated.

Since this function no longer returns anything, it should be renamed.
Possibly updatePrintQueue, seeing as that is now the side-effect it causes.

This needs to be updated in the existing watches, tests, and in the documentation.

Create a watch that can get tickets for a github user, or github repository.
It should grab tickets made after the script starts up (or at a specific start time), and print all the important information about the ticket.

This is the pinnacle example, so if printers or tickets should change to better accommodate this watch, we should discuss that. Images and other artifacts that could not be displayed on a text display should be ignored. Logging in should probably occur in the script (DO NOT ASSUME THERE IS A DISPLAY).

The watch should probably use this repository: https://github.com/mikedeboer/node-github

Watch to get tickets for a trello user or a board.

This watch should only create tickets once a description has been filled in for a ticket. It should not just be the activity feed. Images and other artifacts outside of text should be ignored.

Almost every ticket tracking system uses Labels, Milestones, and Assignees. These should be arrays in the spec of the tickets.

e.g.

var exampleTicket = {
  watch: "Example Watch",
  title: "Messages are lost in queue",
  project: "Chats-R-Us",
  number: "#27a",
  body: "When sending messages using ...",
  labels: [ "bug", "help wanted" ],
  milestones: [ ],
  assignees: [ "jrjurman" ]
};

Create a watch that updates for a JIRA board for a user.

This may be the hardest one to implement, as JIRA is not free / open source. The feasibility should be researched. Extra fields should be intelligently concatenated into the body.

Research needs to be done to include this in the workflow of the system. Hooks should allow tickets to be added to the queue as soon as they are made.

The npm install for this package is extremely slow.
Babel should be removed as a dependency, if possible.

Not sure if this should stay, or if there should be a check for any printers before removing the ticket.

There should be a linter for sane javascript defaults. The rules should be cross-platform, and obvious.

The numbers for ticking the clock forward, and setting the watch intervals should not be hard-coded. We probably should expose a list of values in the tests/server folder, that detail what they are for.

e.g. possibly:

// tests/server/values
export const BEFORE_ONE_TICKET = 9;
export const ONE_TICKET = 10;
export const AFTER_ONE_TICKET = 11;
export const BEFORE_TWO_TICKETS = 19;
export const TWO_TICKETS = 20;
...

// tests/server/activity-watcher.spec.js
testActivityWatcher.addWatch(testWatch, ONE_TICKET);

clock.tick(BEFORE_ONE_TICKET);

It's a little unclear to have watches unshift tickets onto the print queue... Perhaps we should create an enqueue function that does the same thing?

Whatever the terminology is, it should be updated in all the watches, documentation, and tests.