Paneris AGM

Change Control:

There was a strong feeling that one of the major problems encountered during the development of iglu.com was that we urgently needed a change control system.

William suggested using CVS, which has a web interface. We discussed what files should fall under this system, and concluded that it should cover everything, including html, scripts and graphics. TimJ was concerned that an additional burocracy would be involved when not necessarily required. He relented.

The new Paneris system (PanerisII) will be completely under the control of CVS, allowing us to roll back to any point in time.

 

Bug Reporting

For the iglu.com project, the paneris threaded messageboards were used, although this worked, the boards had to be archived three times and many unnecessary messages were generated when marking the threads as fixed.

William did a quick demon of the bugzilla system, which looked great. TimJ was concerned that it would not store the bugs in our SQL chalangeable database, so it was decided that we would use bugzilla as a basis for a bug reporting / task scheduling system. It was noted that we would need to generate emails from this system.

We considered linking the bug reporting system to CVS, so that a fault report can be raised which will then be tracked through the fix cycle. This link is to be investigated as to how appropriate it is both from a technical, and from an ease-of-use perspective.

 

 

Messaging

A new messaging system will be used for PanerisII, this will be based on the messageboards developed for Iglu.com. There will be a 2 way email interface to the system (you will be able to send messages to a board, which will also generate messages to the registered subscribers).

The ability to subscribe to messageboards will vastly improve the system. It was noted that subscription to a node will cascade subscription to child nodes.

Emial etiquette was discussed, with timP arguing that you should be obliged to reply to all email addressed to you. A compromise was reached where we agreed that you are obliged to reply to all emails marked 'important'.

 

Data Dictionary

The datadictionary was considered very important. It will be used to create an object model of the database, with objects based on tables.

 

Project Documentation

In order to run a successful project, the following documents need to be produced. The creation of a new Project node will automatically create skeleton documents of the following:

1. Proposal
2. Requirement Specification
3. Function Specification
4. Project Plan. This describes who does what, and in what order, and details deadlines etc.
5. Architecture Document. This will details the technical nature of the development, OSs, hardware, Libs, 3rd party sw etc.
6. Acceptance / Test Plan
7. Quality Plan. It was not clearly defined what was included in a quality plan, and it was decided that the issue required further debate.

 

Development Procedures

We considered that the development procedures for iglu were more-or-less correct, so here they are:

1. Data dictionary
2. Skeleton Site - the skeleton and the datadictionary fall out of one and other and so can be developed together.
3. Graphical design
4. Libraries
5. Module Based Development
6. Use of bug management software

 

Templates

Templates were generally considered to be a 'Good Thing'. We then moved on to the specifics of the implementation:

• Nobody except william really liked the "eating" of table cells etc. TimJ was also concerned that it was expensive, William said it wasn't.
• William suggested pre-compiling the templates "on the fly". This needs a bit of clarification.
• The else tag should be optional? FIXME
• Debugging scripts should be made easier by including @debug as a standard in PanerisPage.pm.
• Database fields are to be explicitly named. i.e. $property.skiresort.domain.info

 

 

Navigation

A brief discussion about maintenance of state for navigation took place. William suggested some sort of stack mechanism. TimJ did not take enough notes. FIXME.

 

Regression Testing

William suggested that some for of regression testing would be useful. No one else had had good experiences with this. William will investigate further.

 

Paneris - What is it?

"Paneris is a Collaborative embodied as a set of tools which facilitate distributed web development".

We will use Paneris as the main branding on all work we do.

Paneris needs a logo: action Colin.

The 4 levels of interacting with Paneris

1. The Core Members. Currently TimP (Context Computing), MylesC (MJCS), WilliamC (we all agree he needs a better name) and TimJ (HOOP) with ColinR soon to join. The core members are those that contribute to the Web site. All work undertaken by the core members will be done using the paneris systems, and use Paneris as the main branding on the software supplied.
2. Members of Paneris. Members of Paneris are free to brand their work under the paneris banner and exploit the resources available. Any member of Paneris subcontracting another member of Paneris must use the Paneris toolset to document the project.
3. Paneris Partners. Paneris Partners use the resources of Paneris by interacting with a Paneris Member (typically a Core Member). Partners will be encouraged to use the Paneris tools, but it is understood that they will often have their own agenda.
4. End Clients. These are the people for whom we build systems. They interact with one of the above.
    

Paneris Software

Whenever possible Paneris software will be developed and supplied under OSS conventions. We appreciate that our Clients will not necessarily allow this to happen.

Paneris will maintain copyright on code developed by the 'core members'. FIXME is this possible / sensible. Is it not better to leave the copyright with the individual developer.

 

Adhocracy

The term was broadly understood. Specifically for Paneris it means:

1. You can do what you want.
2. Disagreement leads to discussion.
3. Unresolved discussion leads to a call for votes.
4. Any interested party can vote.

 

 

I-way

The I-way situation was discussed and we all thought they were not very cool people. TimJ is to meet them next Wednesday and will ascertain if they are interested in an ongoing relationship. If they are, TimP will become involved and seek an apology.

TimP is to investigate hosting the PanerisII box at an ISP that is not I-way, we will then seek to build a strong relationship with that ISP.

 

Openness

This was adopted as a "Good Idea". However security is still required especially to prevent corruption of data in business critical systems.

For customers a gentle approach was agreed, we would follow this procedure:

1. Introduce openness by giving simple contact info about the customer, and judge the response.
2. Password Protect if required
3. Slowly add more information, encouraging the customer to approve of openness.

Colin expressed concern that his address was available for all to see. It was decided that there was no requirement for openness for personal information.

Data belonging to Paneris (such as invoices, timesheets etc) will always be open. NB: Flexibility (below).

 

Flexibility

TimJ made a short speech extolling the virtues of ultimate flexibility, there was loose agreement, although TimP thought that some rules should be less than totally Flexible (FIXME - TimP, I think I probably cut you off before you had your say).

 

Money

TimJ decided to adjust the process governing money again. Here it is:

A job is worth: Price for Job - Fixed Costs

80% of the job then goes to paying developers (calculated on an hourly basis)

10% goes to the finder of the work

10% goes to the manager and biller of the job.

The management fee is not sacrosanct, and will be cut by agreement if the job overruns etc.

 

Rules

We ran out of time to discuss rules. Paneris has a rules page which represents current thinking.

 

Ethics

We discussed charging for work on a "Cost to us Basis" which was broadly agreed with as an ideology. WilliamC was very keen for charging on a "Value to the Customer" basis. TimJ suggested that any price was good with the customer getting more and higher quality by paying more.

As the vast majority of jobs are under or correctly priced this is probably less of an issue than it appears.

TimP expressed a desire to educate, no one else had much enthusiasm.

We ran out of time to discuss ethics in more depth.

 

Employment and Roles

This was broadly considered a bad idea as they did not encourage the flat structure of Adhocracy.

 

Aims

Chippy had a couple of strong aims:

• Develop the perfect web solution library.
• Develop the perfect web based solutions system.

We all agreed that the one would fall out of the other and we should get on with it.

 

Document Dated: Thu Oct 7 20:05:41 1999 by TimP
Modify this document
Previous Version