Installfest Research

[Alan Dayley]

On Wednesday 30 March 2005 01:01 am, Trent Shipley wrote:
>
> After the Installfest for March 2005 I talked to one of the Installfest
> inner circle.  E said that Installfest only wanted a few services.

A very good thing to do!

> * A FAQ page.  (A first and critical priority.)
>
> * A web page with text box(es) where Installfest consumers would be
> asked questions about their hardware, what software they wanted to
> install, and generally the tasks they wanted to accomplish at
> Installfest.  The HTTP posted results would go to some responsible
> party affiliated with Installfest.  (A high priority.)

This certainly can be done.  Static web pages and forms that send an email 
can be created with the host server we currently have.

> *  A public-relations e-mail release tool (spammer, low priority).

That has been mentioned in the past but I, for one, had forgotten about 
it.  Glad you caught it again.

> * Installfest would like the solution ASAP (therefore without gold
> plating, critical priority).

Very good.

> The Installfester was annoyed that it was taking so long to solve the
> problem. Er annoyance was doubled since e was willing to do the web
> hacking erself if e could get access to the PLUG site and its
> documentation (so as not to crash the production site).

I am not sure how "E/Er" is but Alex has a login to the PLUG website host 
server.  It was provided to him several months ago with the intention 
that he was building an InstallFest FAQ page and the online form 
mentioned.  Perhaps he has become distracted from his goal.

> E was unaware that a sig within the Devel sub-sig was considering
> working on Installfest automation.  E was aghast that the project sig
> in the devel sig was even THINKING of solving Installfest's automation
> "problem" with a three-tier solution that would fit into general work
> on Event Software Integration.

As a project, a basic InstallFest does not provide alot of "meat" for a 
development effort.  It is too small.  But, the goal all along is to 
start small and work up to a larger solution.  Organizing a large 
InstallFest is not a trivial amount of work.

> The interviewee also thought that extending PostNuke would be overkill.
>  Even allowing that the extension were reasonable, e did not like
> PostNuke. Instead, e would rather write clean code and duct tape the
> result to the existing PLUG site.

I agree.  Extending PostNuke has not been what I, at least, had in mind.

> I start off by noting that Installfest is NOT asking for any "planning"
> or "project management" software per se.  If an Installfest is a type
> of event, and events are types of projects, it is irrelevant for the
> problem at hand.
>
> The most involved problem is basically a trouble ticket entry system. 
> Trouble tickets are a sub-problem in the CRM field.
>
> Nevertheless, I think that the interviewee should have given more
> consideration to tracking HR inputs (that is, Installfest volunteers,
> their skills, and commitment to show up--Shubes's "Who's Who") and to
> track trouble ticket outcomes.  The reader will note that both are well
> within the ambit of CRM or help desk domains.
>
> Furthermore given the classic help-desk dimensions of the Installfest
> "itch", I think that the Installfest insiders should reconsider trying
> to find a simple solution on SourceForge and the like, rather than
> trying to roll their own (evident simplicity not withstanding).

Atrouble-ticket system may be a good match for the basic InstallFest.  
That could save lots of programming effort, if such a project fits well 
or can be "tweaked" to fit.

> In summary, the Development Project sub-sub-sig should drop Installfest
> automation from its list of prospective projects.  The Installfest
> inner circle know what they want, have the skills to solve the problem,
> and no shortage of motivation.  They should simply contact the web
> master (Alan Dayley) and hack the PLUG web site.  (Well, preferably
> create a development environment, test, THEN hack the web site, but you
> get the idea.)

Yes, well, to put it bluntly: They have not done it.  Any PLUGger is free 
to create something and submit it as a contribution to the group, whether 
it be a poster, burned CDs or an InstallFest FAQ page with a help sign up 
form.  One of the InstallFest insiders has had a few months of access to 
the site, and we still have nothing there.  I'd say their motivation is 
short.

(Aside: PLUG has the flattest authority and management structure possible.  
The Steering Committee is only charged with getting done what the group 
wants to do.  Yet, there is a culture of authority hierarchy that newbies 
bring and long time members have not dropped in favor of the FS/OSS 
culture.  The FS/OSS culture expects people to do things for themselves 
without asking permission.  PLUGgers still seem to need permission to do 
things.  I wish this were not so.  PLUG would be a much more vibrant 
group if PLUGgers would just do what they think needs to be done and then 
sell it to the group as a whole.  The Steering Committee's job should be 
woking to keep the chaos organized instead of working to make something 
happen.)

Part of the impetous for the Devel project on InstallFests is to provide 
the "permission" and priority to get this thing done.  A motivated 
developer with some capable skillset could bang out a basic InstallFest 
"automation" application in a day or two.  This is known.  But, if a 
project is required to get it done and it can be grown to handle larger 
projects, we will do a project and benefit from the process along the 
way.  IMO.

> There is still the possibility that ASULUG, with its greater interest
> in Mega-Installfests, would have more interest in Devel Project's
> services.  If so, then we would still have a first client for an Event
> Software Integration Project. ASULUG's next meeting is 23 April (I am
> told).  I hope to have more after that.

Great research.  Don't foget to check the links of emails from PLUGs 
previous large InstallFests.  There is much there about resources that 
need to be handled.

Alan