[Cadre-politics] 100 org questions & answers

[Josh Harding]

One item not mentioned in the questions:
  -At what point will we press UML's bandwidth? At what point will the
relatively low reliability of UML's connection become an unacceptable
liability?

My personal opinion is that a reliable connection is one of the most
important infrastructure needs we will have as we expand.

On 7/9/06, Dan MacNeil <omacneil at brave.cs.uml.edu> wrote:
>
> --------
> MOVING TO 100 ORGANIZATIONS
>
> CAN WE MAINTAIN CONTACT INFO FOR 100 ORGANIZATIONS WITH A SPREADSHEET
> AND LISTSERV?
>
> yes, the slightly tricky part is being sure to update both.
>
> Q: WHAT LEVEL OF TECH SKILL ARE WE EXPECTING FROM OUR NEW CUSTOMERS?
>
> Probably about the same as the old customers. Some know the difference
> between a dir and a driver some won't. All will be focused on getting
> their work done and spending as little time as possible dealing with
> those pesky computers.
>
> WHAT STEPS CAN WE TAKE TO ATTEMPT TO DEAL WITH THIS LEVEL OF SKILL?
>
> We can fix some of our obvious usibility problems. Examples:
>
>         a.      /home/sites/utec-lowell/doc_root
>         should be:
>                 ~/web/utec-lowell/doc_root
>
>         b. control panel, control panel, control panel
>
> WHAT ARE OTHER GOALS THAT ARE MAYBE BETTER THAN GROWING TO SUPPORT 100
> ORGANIZATIONS?
>
>         a. training/development to get good at software improvement
>         b. adding features, (drupel, smtp auth,
>            server side msg filtering calendars)
>
> WHAT ARE SUB GOALS OF THE MAIN GOAL?
>         a. bring security to needed levels
>         b. bring usbility to needed levels
>         c. bring relibility to needed levels
>         d. start measuring quality emperically
>         e. ticking system
>         f. control panel
>                 --has many sub, sub goals
>
> WHY DO WE WANT TO BE AN ISP?
>         a. writing server based software requires understanding servers
>         b. the world should be able to use more than verizon.
>         c. discipline applies to other areas.
>
> HOW WILL INCREASING OUR NUMBERS SERVED TEND TO REDUCE THE QUALITY OF OUR
> SERVICE?
>
> It will be harder to do stuff like dealing with register.com for people.
>
> DO WE NEED A FULL TIME LEADER TO HANDLE 100 ORGANIZATIONS?
>
>         No, probably not.
>
> WHAT PROJECTS DO WE NEED TO FINISH TO BE READY TO SUPPORT 100
> ORGANIZATIONS?
>         Wait till next week.
>
>         A. WHAT NEEDS TO BE DONE TO HANDLE SERVER LOAD?
>                 I. MORE HARDWARE ?
>                 II. BETTER ARCHITECTURE ?
>
>                 Server load is definately ok for everything
>                 but SPAM processing.
>
>         B. WHAT NEEDS TO BE DONE TO HANDLE TECH SUPPORT LOAD?
>                 I.   HOW DOES EASE OF USE NEED TO BE IMPROVED?
>         yes, see above.
>
>                 II.  HOW DOES TICKETING NEED TO BE IMPROVED?
>         yes, some things are falling through cracks already.
>
>                 III. WHAT TASKS NEED TO BE AUTOMATED?
>         site creation/deletion
>                 III. WHAT TASKS NEED TO BE HANDLED BY USERS?
>                         email & account creation.
>
> C. WHAT NEEDS TO BE DONE TO HANDLE INCREASE IN BILLING ?
>
>         keep spreadsheet up to date.
>
> WHAT NEEDS TO BE DONE TO IMPROVE PERFORMANCE MONITORING?
> We need to start monitoring the load on the spam filtering boxes.
>
> WHAT NEEDS TO BE DONE TO IMPROVE SECURITY?
>         see complete project list. (next week)
>
> DO WE NEED TO BE COMPLETELY SCALABLE?
>
>         no, but it will be very, very tough to change interfaces after
> this
> next bump up.
>
> WHAT ARE SOME DEADLINES ?
>         Friday August 25, summer workers stop working
>         Friday December 29, new year.
>         Tues May 01,  presure to finish stuff for mvhub gets intense.
>
> WHERE DO WE DRAW THE LINE BETWEEN TIME AND FEATURES?
>         I don't know if we have enough info to make that decision.
>         We might when we have a draft project list.
>
> DO WE NEED TO IMPROVE MEASUREMENT AND EVALUATION?
>         A. RESPONSE TIME?
>         B. DOWNTIME?
>                 I. DURATION ?
>                 II. CAUSES ?
>         C. CUSTOMER SATISFACTION?
>         D. ABANDONED PROJECTS ?
>
> A-C yes, D maybe not
>
>
> WHAT PROJECTS ARE IRRELEVANT TO 100 ORGANIZATION GOAL AND SHOULD BE
> POSTPONED?
>         hard to say now.
>         maybe logging, cyrus migration
>
> DO WE NEED ADDITIONAL INFRASTRUCTURE TO ATTRACT 100 ORGANIZATIONS?
>         A. DO WE NEED A RESELLER INTERFACE?
>         B. DO WE NEED TO OFFER MORE SERVICES THAN WE DO?
>         C. PRECISE CALCULATION OF UPTIME?
>
> maybe, but we should worry attracting users after we can support them.
>
> WHAT OTHER COMMITMENTS DO WE HAVE THAT WILL TAKE RESOURCES AWAY FROM GOAL?
>         utec
>         day to day tech support
>         lowelldeeds
>
>
> ARE ALL OUR RESOURCES A GOOD FIT FOR THIS GOAL?
>
>         no, about 1/2 the group has little system admin experience.
>
>
> WHAT PROBLEMS BECOME STATISTICALLY MORE LIKELY BECAUSE WE WILL BE A
> LARGER TARGET?
>
>         somebody will install or write an insecure php script.
>
>
> DO WE NEED SMTP AUTH?
> DO WE NEED TO MONITOR OUR USERS FOR SPAM?
> DO WE NEED TO MONITOR OUR USERS FOR VIRUSES?
>         probably
>
> RIGHT NOW, USERNAMES HAVE TO BE UNIQUE SYSTEM WIDE, DOES THIS NEED TO
> CHANGE?
>
>         yes. Perdition seems like a way for this to work.
>   http://www.vergenet.net/linux/perdition/perdition_paper/
>
> DOES ANYONE CARE ABOUT HAVING A @THECSL.ORG EMAIL ADDRESS FOR PERSONAL
> USE IN ADDITION TO THEIR @DOMAIN.ORG ADDRESS ?
>
>         probably not.
>
> SHOULD WE AUTOMATICALLY CREATE PERSONAL WEBSPACE FOR PEOPLE WHEN THEY
> GET AN ORGANIZATIONAL EMAIL ADDRESS?
>
> no, we should stop doing this.
>
> IF WE CHANGE THE WAY THINGS WORK, DO WE HAVE TO SUPPORT THE EXISTING
> INTERFACES?
>
> yes, for email, no for shell & ftp
>
> ARE OUR BACKUP AND RESTORE SYSTEMS ADEQUATE TO HANDLE 100 NEW
> ORGANIZATIONS?
>
> almost, We need to move to virtual servers.
> we probably need periodic restore drills.
>
>
> _______________________________________________
> Cadre-politics mailing list
> Cadre-politics at lists.thecsl.org
> http://lists.thecsl.org/cgi-bin/mailman/listinfo/cadre-politics
>