Another good reason why we need to develop a MUCH stricter system about how we're developing the community system. For example, it was *very* tough for me to find pieces that weren't too incestuous with precise customizations we've made for our clients. I'll try to think of a good way to do this. -Ben

-- Anonymous, September 26, 1998

Answers

1) I agree with Ben that this is an important issue. In general though, keeping track of things, splitting code, etc... is hard. People always wand to define a "system" that will do it for them, but sometimes it takes communication.

PlanetAll once had a rule/path of logic that led him to 4 different servers for development/QA/ Staging/Production to launch EVERY TCL (ASP) page change. We never were able to obtain enough "clean" servers to do this.

They are now are in the "super documentation" mode.

2) I believe that the "community system" was tarred up several months ago. I've made countless changes since then, some very important.

3) On Ben's side, I think he has improved the registration system. This would have to me merges into the community system. He also added some admin pages (I forget which), that can be easily added. There may be more he has done since he has split.

4) Someone should be in charge of the "Base Code" and keeping track of it. I don't know if it is me or Ben... I am going to assume it is me from know on since Ben does all the backend stuff.

As far as the current state of the community system. Ben and my changes have to be merged and we have to make sure it is generic and we need to make a stable base to start from. I don't think this will be very hard.

5) I've assumed that anything in a defs file is fair game to change and this is how I've been dealing with customizations as much as possible.

For things specific to Cognet, I took things out of the main code and put them in defs. (There are a few reasons why this may not be true - sometimes they go in and change code themselves and then I go fix it. I would like to hear Ben's side.)

6) I think the proper block of code to work with/track is the "module" - (this seams obvious).

7) I have a bit of documentation I have been building up. I also have to document the data model "In English" so a non technical maintainer work their way around. I will modularize and make generic versions of these.

8) A proposed system:

a) Community system is maintained as modules (i.e.. bboard, classifieds, bibliography, CyberCash, etc..).

The "Community System" (user tracking, registration) as a whole should be treated as a module for this purpose.

b) In general, the main developer is in charge of the module. They are in charge of a basic "list of features" that the module does.

c) When a developer need modules, they take them from the latest version. If they make changes, they should work with the module maintainer to decide if the source should be updated/maintained or if the code should be split specially for the client.

-- Anonymous, September 26, 1998

It is safe to say that I've touched/enhanced every single module and file in the Community System. At the very minimum, I changed every thing to use the user table. I've added a geography option to the classifieds, added a "ed-com" view to the bboard, put together all the admin features (chapter 3), made a fairly generic menu system, put a lot of things in the defs files so they could be customized for Cognet and basically put the whole thing together.

I think a lot of this was after you took the code. esp. if you only took it once because when you tared up the files the first time a few months ago, it was FAR from done.

I wouldn't say that it is a "problem", but it is definitely something to work out. It is a fairly new project and we've both done a lot of development and we just have to regroup a little. It's fine by me if you want to be in charge of the base, but we might want to talk about what we have to start from. (Don't worry, I haven't done anything REALLY drastic.)

For tcl files, I've been linking from the main tcl directory to a defs.tcl file in the module -- not a big issue though, it can be done anyway it will work with AOLServer.

I am not sure I understood your comments about the ad-defs file. Isn't that were you put all the client specific things, such as [ad_system_name]?

Your system of organization sounds as good as any.

I am also in favor of some form of source control for the "official" code, although Philip is not found of that idea.

As far as features go, I think we do a really good job about making it customizable in a generic way.

For look and feel, annotation, etc., we need a lot of work, although it seems next to impossible take care of every possible instance.

For example, if they don't like the

---

in our subheadings, every file is going to have to change.

I think it is also how you sell it though. I almost got the feeling MITPress, or at least their graphic designer, wanted to design every page from scratch. Phillip did a good job explaining to why they wanted to go with the generic version, but people like to control the look of our site.

Isn't life interesting?

-- Anonymous, September 26, 1998

Okay, we've got a problem here, because i've added some things to the GreenTravel site community system. Which is why we *need* organization, even though it's hard.

Tracy, I don't mean to pre-empt you, but I'd like to take control of the base code, because I've been preparing homepage to be a "bland" community system site to serve software.arsdigita.com, and I've been trying to clean up all the defs file. Furthermore, my slightly irregular schedule makes it easier for me to take care of something that is pretty stable (i.e. the base), rather than something that is constantly being improved (i.e. the modules). On that note, you should take charge of the bboard module, and any other module that you've been working on for cognet, if that's not too much work.

I propose that we make a central repository, that contains the "base" code, and each module's code. When someone wants to make improvements, they can take ownership of a module, and work on it, making regular updates back to the site (no less often than once a month). However, we never make updates back to the main repository until the code is thoroughly tested. I think it's okay to take module possession for a month, given the small size of our company.

As for the structure of our Tcl files, I think we should work as follows:

- base Tcl code in /web/community/tcl - each module's Tcl code in /web/community/module/tcl

Currently, this is difficult to have because Aolserver can only have one Tcl directory. However, I've pinged Markd to change this in the upcoming version of Aolserver, and we can patch this right now by having a special file in /web/community/tcl that evals all the other module's tcl dirs.

We also need to be careful about our naming schemes. Anything that says "ad-*.tcl" should *NEVER* contain customizations for customers. We should be able to do a cp of all the ad-*.tcl files from one site to another to make a clone community site. I'm saying this because I have seen in various community installations out there some code in ad-defs that is client-specific, and we shouldn't do that.

As for splitting the code for the client, I believe that we will almost *never* need to do that. We can easily structure things so that client customizations are always in a few select Tcl files. In the end, most clients want the same form of customizations anyways.

Okay, enough on that for now :)

-- Anonymous, September 26, 1998