• SourceForge - well established, good network connections, pretty easy to use
• Perlmonks.org - Don't know how we'd do this in the current scheme. Nodes might get a little long and lengthy.
• Someone with website space - I have plenty of storage, but limited to 400MB of traffic per day. I don't know the legality of putting up a CVS server, however. I'd have to check with the sales/legal department there. I sure don't mind doing that, if the ISP doesn't (I use pair.com)

• Perlmonks.org - Again, the node management system probably doesn't really lend itself to the kind of traffic we're talking about.
• Topica.com or OneList.com - I use topica.com for a couple of mailing lists that I'm on. They have minimal advertising (unlike OneList), and have both an e-mail and web interface
• Majordomo - I don't like majordomo. Does anyone?

• I (and these are just my opinions, not gotta-be's!) would like to see a good positive attitude with regards to code critiquing. If someone writes codes they've signed up for, and it's questionable, it needs to be approached with a good positive attitude, not a body slam. Who ever signed up to write that section is presumably doing the best they know how. If there's a better way, it's not someone elses job to rip-and-write. The goal is educate people (remember, this is about education, and eliminating cargo-cult memes (to steal a phrase)), not alienate them.
• CPAN may be the home of well written code, but from a lot I've looked at, it's not the home of well documented code. On of the things that people should walk away from the project with is a sense of documentation that allows newbies to understand what's going on, but not have a 'War and Peace' sized text explaining a for-loop. Hopefully people of all skill levels will be participating, and it shouldn't take a trip to the bookstore to figure out why a 'map' was used, and why it's better than something else.
• Maintainability - Supertight Perl code is great, but if the next person who comes along that has even a slightest clue of what should be going can't maintain it, it's for naught. I know people here can write a single regexp that will yank every 50th word, swap them around in random order and produce a semi-coherent haiku. A single regexp 640 characters long is not maintainable. Many of the new Perl users only know how to manage simple regexps. We'd like to make them a little better at it, but I still don't expect them to have to be regexp geniuses to understand it.

If I were to mentor someone, I'd let him do most of the work, but offer suggestions and ideas when necessary. Seems like each pair could take a module or a chunk of code and work on it that way.

Or I'm a huge idealist. Either way.

Yea, and that way you've got a coffee and donuts flunky, too!

--Chris (OK, who wants decaf?)

OK, so the first module is a means of transmitting caffeinated beverages and junk food by email...

- Ozymandias

It seems like queries against this would make more sense as a database, but that brings up all sorts of ugly non-perlness (OS, DB specific..) Therefore, why don't we make it focus on inputting data, selecting an indexing style, and outputting a file (CSV?). Thus, given any info, we can not only index it, we can facilitate dropping it into a database for future use.

That's exactly what we're looking for. Sure, if we could enlist vroom, mdillon, btrott, and some others, we could probably hack this out in a few days. That's not the goal. The goal is to learn by doing - and just learn more than the average perl script teaches you.

- Ozymandias

redmist, glad you're signing up. Be sure you get me your e-mail address in a /msg (and not a /msh... sigh)

As far as gurus go, that's the whole *point*. We're not looking for geniuses who could code the project in a day. The idea is that folks like you and me who *aren't* the merlyns and vrooms of the world go through through the project development stages, contributing in areas that we're not strong in. To be given opportunities to learn about designing a GUI if all you've written is command-line projects, or getting involved in the loop about how projects are designed, managed, tested, coded, etc. And since we've chosen SourceForge, learning how to use toolchains to support the project. Learning how to work on a multi-programmer project. It's not just about the Perl.

This project is a means to end, not an end to means. (Our new motto!)

--Chris

Should we scale down the project a little? An "Anything Indexer" faces the problem of normalization. I would assume that the user would enter all of the relevant fields for the data they wish to collect, and then further questions would have to be asked of the user to determine the relationships of those fields. Those relationships would be used by the program to normalize the data. The problem is, I'm not aware that it's possible to generate on-the-fly normalization for complex data. The more information the user wishes to track, the more difficult the normalization becomes.

For instance, assume that we're tracking CDs. Let's say that the user wants to track the record label. This has to go in a separate table as one record label will be on many CDs. This is a one-to-many relationship. This seems fairly straightforward. We create a CD table and a record_label table and the CD table has a field identifying the record_label ID.

What happens when the exact same CD is issued under another label? Then we realize that we have a many-to-many relationship and we should have a junction table tying the CD and record_label fields together. Oops. If the database isn't set up that way in the first place, the user may be forced to create another CD record with a new label name and we wind up with duplicate data in the database and we wind up with the potential for modification anomalies.

That may not be the best example, but the point holds. If we target the Indexer at a specific use, we can address these issues up front.

Update: A modification anomaly (as mentioned above) is where updating data corrupts the integrity. In this case, if we have one CD under two different labels, but the user got the name of the CD wrong, he/she may correct the name, but not realize that this error occurred in two places. We wind up with one CD with two different names.

Unlike swiftone, I'm not interested in realistic goals. <G>

Seriously, the points you raise are good ones - but I don't think it's a serious problem. The idea behind the Anything Indexer is that the Indexer itself is just an engine. I'm sure we'll create multiple modules for initial release, and a module RFC-style document; but the module is responsible for those issues. You have to be careful defining your fields and how they inter-relate, but that really shouldn't be much of a problem.

- Ozymandias

What happens when the exact same CD is issued under another label? Then we realize that we have a many-to-many relationship and we should have a junction table tying the CD and record_label fields together. Oops.

Well then it's time to rerun the data through the Indexer. :) Seriously though, I'm all in favor of realistic goals....but would anything less ambitious be worth doing (one could use any of the dozens of CD systems on Freshmeat.net otherwise)

I'm in a hurry here, so I have only skimmed certain parts of these discussions. But I was wondering how deadlines will be maintained? I mean, a lot of us monks have busy jobs and maybe not that much spare time.

Anyway, this project seems very interesting and I'm very interested in joining...

Gotta run now!!

I think we'll be trying to take as much of that as possible into account as we figure out what people want/need to work on, and what their schedules are. I expect there will be an occasional problem with something along these lines, but hopefully participants will have a good handle on how much time they realistically have available.

On the other paw, I don't want to see this be a 12 month project. I think we've picked a project that's not so expansive that people will lose interest, nor so short term that it'll be done in a week (hope not, anyway).

Remember, we're going to try to go through all the steps that real programmers hate: planning, writing a specification, scheduling, code reviews, etc. We may hate that part in real life, but it's something that's all part of delivering a real-world project.

Along these lines, I wonder if we need a "motto" that reinforces that project is not an end to the means, but the means to an end.

--Chris