...
- Which are known to work?
- Which are known to not work? Is that okay?
- Which should be discouraged (because of effort, complexity, etc.)? Is that okay?
- Which need to be explicitly tested because answers to the above questions are not known?
- For things that used to work but won't going forward, what business need are they addressing and can it be met some other way? How difficulty difficult will the transition be for clients?
- Have we made decisions on the fly that may need to be reversed or postponed? If so, what's the impact? What's the impact of not reversing?
If nothing else this information will be needed to inform the printing wizard Heather Anne is working on.
...
What should our job control story be to the community? Given Oliver's new motto of "Do no worse" is there a chance we can make it at least as functional as the old model? Can we make it a little better?
Metrics
- We are currently collecting page count, job name, and user name information from CUPS.MIT.EDU via Virebo. Will this work via PRINTERS.MIT.EDU? In particular, what's up with page counts?
- Does PRINTERS.MIT.EDU position us any better for metrics requests that are probably "coming soon"? (Quotas, limits, overage charging, etc.?)
- Is an infrastructure transition now the right thing to do given that: at least three task forces are looking at student printing and MIT-wide printing; we don't have a lot of money to invest in printing infrastructure and we don't know future demands on it yet? Is it really mainly the "PDF->Postscript problem" and if so should we just fix that?
Documentation
- Expensive printing documentation in the clusters (SAVE project, ~$1000 total not counting labor); is it worth re-doing this? If not, are we taking a step back or is documentation no longer necessary because (printing) life is easier?
- Web pages and stock answers: who changes what?
- Printing "portal" page at http://ist.mit.edu/services/printing
...
- Header pages
- DUPLEX
- Expiring stalled jobs