The project

[Trent Shipley]

On Thursday 2005-02-24 06:13, Alan Dayley wrote:
> Joseph is the guy spearheading the project right now.  I'll just bring it
> up here like I brought it up at the last Devel meeting.  Then, as Joseph
> planned, we can proceed with the discussion.
>
> History
>
> When the Devel meetings were first started, one of the stated wishes was
> that projects would grow out of the group.  Ideas for doing applications
> for education, both testing and administration were the strongest
> candidates along with a brief discussion about a game.  None of these
> took hold.
>
> Prior to Alex setting up monthly InstallFests (yea Alex!), PLUG used to do
> big InstallFests about once a year, give or take. =20

<snip topic=3D"lost data and methods"/>

> The Idea
>
> From this experience with InstallFests, a few members thought a great
> project would be to make an application suite to handle all the
> coordination needs of an InstallFest.  Released under the GPL, it could
> benefit FS groups everywhere.  Then, allowing the dream to grow, we
> thought this could be adapted to coordinate any event, all the way up to
> conferences and trade shows.  So, the event application suite idea was
> born.  And, it simmered in a few brains too busy to do much about it.
>
> Last Meeting
>
> The last Devel Meeting found us without a specific presentation.  I sprung
> this history and idea on the members present.  An excellent discussion
> ensued.  Some present had experience working with event planners and many
> had experience doing database applications with different tools.  I'll
> just do some summary bullets about some of the points I remember:
> - Event planners currently are a small, niche industry.

Joseph brought that up.  I'm not certain I believe it.  Weddings are a type=
 of=20
event, therefore wedding planners must need event planning software.  Every=
=20
arena and civic center needs an event planner.  Every funeral home needs an=
=20
event planner and so on.  If there is an event, some agent has to plan it. =
=20
(Unless it is a "happening" which is a minimally planned event.)

> - Because the industry is small, there are not any known (at least to the
> group present) commercial applications for doing the planning.  Those
> doing it use spreadsheets and custom Access apps and the like.

Per Joseph, and this I believe.

> - Development of the application would probably proceed as follows:
> -- Support for monthly small InstallFest
> -- Then large InstallFest
(We would call this a "FOSS Expo")
> -- Then large event (type to be chosen later)

Stages two and three were not well specified.  It was assumed that IF the=20
monthly install fest folks could not find what they needed by shopping, THE=
N=20
they would agree to be the first customers for the proposed event planning=
=20
project.

Since no one at PLUG or AZOTO has committed to doing an Expo, phase two is =
not=20
yet defined.  IF we do proceed with an Expo THEN it would be a phase two=20
customer, probably THE phase two customer.

> - An open source application was found on freshmeat.  (Ed, I can't find
> it!)  It has a BSD-style license with a "no commercial use" clause.  We
> don't think that fits what the group wants.

The product was OpenConf.
See http://www.zakongroup.com/technology/openconf.shtml

At the end of the meeting the InstallFest folks had not determined whether=
=20
OpenConf would suit their needs.  My recollection was that they thought it=
=20
might well do so since the license was compatible with their immediate need=
s=20
(they would not use OpenConf commercially).  I further understood that IF=20
InstallFest opted to use OpenConf (or another existing product) we would=20
scrub the event planning project proposal to look for a customer whose need=
=20
could not be satisfied by shopping.

> - Possible platforms were discussed
> -- Java
> -- GNUe
> -- other web based tools like PHP
> -- To be decided after requirements are pinned down
> - Joseph took on the task of being the first leader of the project.

Nevertheless, there was a marked preference for creating the event manageme=
nt=20
project as a GNUe module, partly because event planning is often needed by=
=20
businesses, and partly because event planning could draw on generic ERM/P=20
functions like rolodex, human resources, inventory, finance, workflow,=20
calendering, and project tools like Gannt and PERT.=20

The concern was that GNUe might not be mature enough to actually support=20
effective deployment of an event planning and management module.  It is=20
desirable that Derek attend the 3 March meeting so that he can tell us GNUe=
=20
can do this, can't do that, and won't be able to do the otherthing for=20
another year or so.

=46urthermore, if the event planning does not pan out, then GNUe offers obv=
ious=20
room for PLUGdevel to pick up responsibility for a GNUe tool or module.

Also, my concern is that modules in GNUe must be written in Python.  There =
is=20
nothing wrong with Python, but it does not have a large market share. =20
Working in Java might be worse for the project, but better for resumes.

> Intent and State
>
> The intent is to run it like a real project (since it is real) and do a
> requirements document, design, technology selection, etc. before the
> coding starts.  Joseph and a core team can meet when they want and
> provide progress briefings at the meetings.  Some Devel Meetings may be
> dedicated to working on the project as a means of getting work done and
> teaching whatever techniques are currently being used.
>
> I have stepped back and would love to see several (many?) group members
> step up and participate as each would like.  Joseph has the reigns now
> and can proceed as he and the group see fit.  Even if we end up with the
> minimum, something the coordinate InstallFests, we should be learning
> much along the way.

Joseph said something about starting with a team of 4 to 6 coders.  I do no=
t=20
know if that includes system and application administration (host server,=20
version management software, project planning and management software, and =
so=20
on).  If not then the project could include another couple of participants.=
 =20
So to start we are looking at a few to several, NOT many, especially given=
=20
received wisdom about group dynamics in general and software project=20
management in particular.

=46rom Joseph's perspective a best case scenario is that he gets to pick hi=
s=20
talent in a "buyers" market.


> There.  Any questions?
>
> Alan
> _______________________________________________
> PLUG-devel mailing list  -  PLUG-devel@lists.PLUG.phoenix.az.us
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-devel