Work Plans for ShowCase

Its initial configuration uses three record sets - MEMBERS, GROUPS and MEETINGS.  They interact by letting administrative staff - Joe & each group's - securely post meeting descriptions in a handy web form, and pull down change reports on members' subscriptions via a web browser. The two activities have a causal link at fundamental Mesda business levels:  good descriptions of meetings should boost member subscriptions to Mesda activities of all sorts, and hence aid its missions.

Details on this web app will evolve as described on the projects/registry page.  Strategically, it seems clearly needed if Mesda is to successfully and significantly expand the number of its user GROUPS.  Indeed, it much aids that expansion, by giving GROUPS co-ordinated support, which cuts the work to independently create and maintain their web sites (necessary overhead; not a real goal).

A trick is involved here, requiring aid from the JugSite team.  Once it installs links to employ the MEMBERS and MEETINGS data in its own pages - an easy step which adds benefits and/or cuts maintenance - it will clone, rename and trim itself into a "prototype" GROUP web site, available for ready re-use as new user groups later form.

With it, freely hosted basic sites can be quickly deployed as required (under a man day?) by just cloning, renaming and "rebranding" the prototype site, then zipping it all up into a WAR file. Each new clone provides access to all shared record-set resources - its key dynamic content - and has obvious places to graft in any new group-specific layout, images, and other text pages as desired.
 

For ShowCase this is great, as quite a lot of prep work on general "project management" types of extensions will be needed to get it off the ground.  This would be true of any open source coding effort, or any complex "community" site, both of which seem to characterize our Web Apps mission and Mesda's expansion goals.

Ultimately, as Web Apps Chairman, I hope to find JUG volunteers for all Projects listed (or close variations), plus others yet to be defined.  I also hope to organize cross-project mechanisms whereby  progress on each effort can be centrally tracked and reported as multi-level Jugnews (one of the open efforts now suggested).  It should let different people report and follow various projects at different levels of detail, depending on their stated interest and level of responsibility.

As leader of  the Projects effort, my own plans are to aid such reporting by expanding central record sets for linked PROJECTS and TASKS, then enhance the Registry logic at all levels to support them:  For example, working GROUPS and MEETINGS will be allowed as well as user GROUPS and MEETINGS, and interested MEMBERS will be able to subscribe to all of them.

Mesda's user group MEMBERS will also associate to PROJECTS and TASKS, and optionally be notified be email whenever relevant Jugnews about them was reported.  With proper permissions (from a PROJECT leader), they'd also post and adjust TASK-related descriptions, again via a browser, as a team member.  This sort of thing seems part of all open source efforts, but in our case we need to keep it especially simple (form-driven) to accomodate all types of end users.

Ultimately, I hope to expand the static Projects page into a portable "Project Tracking System" - one easily adapted and remotely maintained by the diverse MEMBERS of multiple Mesda GROUPS.  Its benefit is to the "community" process at large.  By basing it upon formal record sets (which unlike hand-edited web pages can include automatic change-tracking features), we can formalize status changes on a PROJECT or TASK, and easily add low level event triggers for Jugnews..

The ability to monitor PROJECTS and TASKS helps reward and co-ordinate those doing the work, by giving them an audience.   By managing such news flashes in personalized ways, we can also help to educate and entice those who are watching.  This is a subtle but key part of open source efforts, which in practice helps everybody stay motivated and well informed.

Ultimately, it also helps us get volunteer workers, and guides them informally via community exposure and feedback, not by traditional management fiats.  This approach we clearly need, and so may those who participate in ShowCase competitions.  We should plan ahead, and try to design all Web Apps support aids to serve expected needs of future student GROUPS, not just our own.
 

By early summer, per the above plans, we could start asking limited external GROUPS to submit various WAR files under a low key beta test program. Doing this has several benefits:

1. It gives us feedback on all support mechanisms or omissions
2. It gets MaineJUG (and others) thinking about "target tasks"
3. It lets external users test our plans, as we watch their reactions
4. It gets ShowCase some needed PR, and helps get new volunteers.

Meanwhile, four other things need to happen within Web Apps, MaineJug, and Mesda, which would support not only beta testing but the expected transformation of ShowCase into an on-going community and State-sponsored activity:

1. Ask some college faculty to get involved, as testers and refiners of the processes, and also to suggest and help plan the first Fall competitions set up for their students.  In the long run, this group of people will probably end up managing the on-going program
2. Get better hardware support, either by adding some new host accounts able to handle extra web traffic, or by migrating all our baseline software onto some waiting Mesda Linux cluster.  By focusing on portability earlier, we should ensure that this choice can be freely made.
3. Expand our support software, mostly with "filters" designed to centrally handle general timing and contest-specific functionality scoring of student Web App entries.  With any luck, it will be all we need to add, as the mechanics of posting WAR files should by then seem easy;
4. Add decent on-line documentation that explains the whole process, how everything works, and how to sign up.  Do this early enough so that a ShowCase web site can be posted and thoroughly beta tested along with all other project-support software.

If we do our parts well, we should be able to sit back and enjoy the first actual competitions, knowing that we started up something useful and exciting.  In practice, of course, any rollout uncovers a few flaws in the system, which we hope would only give MaineJug new candidate Projects for Phase 4 volunteers.