Phoenix Linux Project

[trent shipley]

https://tools.usps.com/go/POLocatorAction.action

Customer's problem.
* All the post offices in the Phoenix area have a backlog of weeks for
passport applications in the Summer.
* All appointments are made by telephone. A web interface is not available.
* The various post offices do not have an integrated appointment backend.
* Customer data is subject to the 1974 Privacy Act.

Suggestion.
*Build an enterprise grade, web front end, business logic, and data bases
(GIS, acceptance facility [post office], customer, and calendar) to support
passport appointment in Maricopa and Pinal counties.
*Also may need phone room and telephone appointment interfaces.


Pros.
*Enterprise size problem with room for expansion (eg. California) will
chalenge contributors at all levels.
*Affordable secure appointment systems are widely needed, and should be
commodity grade software. (FOSS appointment software exists for medical
practices and may be a reasonable starting point.)
*Solves passport consumer customer service problem.
*Matches consumer demand to appointment availability in geographic area.
*Government qualifies as a charity.

Cons.
*Largely transactional, so a poor fit for big data project (Hadoop).
*Not a novel project. (There is other FOSS appointment software).
*The government is not a particularly charitable charity.
*Neither the US Postal Service nor the US Department of State have actually
agreed to work on the project.
*To actually see real customer data (say alpha phase), the participant
would need a security clearance, as would the development ecology.


Trent.

On Tue, May 17, 2016 at 9:51 PM trent shipley <trent.shipley at gmail.com>
wrote:

> I'd like to hear some 250 word pitches for open source projects that the
> Maricopa-Pinal counties Linux developer community could work on.  Maybe the
> Phoenix Linux Project would merit 501c3 status.
>
> Desirables:
>
> Customer:
>
> *Primary (initial) customer: non-political, non-religious charity or
> government agency.
> *Wide enough in application that many customers can find a use for the
> product.
>
>
> Wide range of talent and experience:
>
> *Associate and Bachelor's and entry level developers do most of the coding
> to interfaces and with mentoring.  Also, documented experience for would be
> UX designers and technical writers at this level.
>
> *Master's, junior, and intermediate level programmers provide
> architecture, mentoring, and difficult programming.
>
> *Senior volunteers provide overall architecture, general direction, etc.
>
> *Juniors should have contribution documented so that it contributes to the
> juniors' marketability.
>
>
> Designs should be applicable to jobs in industry:
>
> *Secure
> *Scale from desktop to enterprise/intranet to internet
> *Modular
> *Use current design standards (for example, REST)
> *Microservices
>
> Technologies:
>
> *Technologies should be focused on what is currently in demand by in
> demand by industry (fostering marketable skills.)
> *Marketable programming language (I'm partial to Java).
> *If at all possible use big data tool, notably Hadoop.
> *Internet programming tools (Spring)
> *git
> *et cetera
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phxlinux.org/pipermail/plug-discuss/attachments/20160518/0b85260a/attachment.html>