12 replies to this topic

[DSaw]

Hi Everyone

This is just to get the ball rolling to see how many people are interested and if this could really happen


CONCEPT

bring Module Makers, proofreader's together to work on large projects



So if your Interest , have ideas, thoughts, opinions

[patchworkid]

hi,

I second the idea, I even thought of the same thing. That would be great for example: Langes cmt.

thanks

[David]

I'm rather new to this arena, but I like the idea. I've been thinking it would be great to have guidelines, best practices, and tips formally documented all in one place, which could be one of the projects that this guild pursues.

[APsit190]

Hi Everyone

This is just to get the ball rolling to see how many people are interested and if this could really happen


CONCEPT

bring Module Makers, proofreader's together to work on large projects



So if your Interest , have ideas, thoughts, opinions

Sounding good, and I like the idea.

That said, I think the collaboration ought to be headed by Josh, or someone appointed by Josh. I guess that the team could be named "BibleSupport Merry Band of Module Creators (BSMBMC) or something like that.

It would mean that the workload Josh has could be farmed out members of that group of volunteers, something similar that Dr Dave does with his little band.

It would be interesting what Josh has to say about this idea.

Blessings,
Stephen (Php 1:21).

Edited by APsit190, 01 January 2012 - 09:26 PM.

[jonathon]

bring Module Makers, proofreader's together to work on large projects

There have been several previous attempts to create something similar to this.

The most enduring has two core members, and half a dozen or so people that wander into and out of the project, depending upon the content that is being worked on, and upon what else is going on in their life.

The largest has three core members, and several others that wander into, and out of the project, depending upon what else is going on in their life, and their interest in what is currently being worked on.

The others have had one core member, and however many people haven't been affected by what else is going on in their life.

Lessons learned

In no particular order:

• For the organizer, this is, for all practical purposes, a full time job that generates neither revenue nor appreciation;
• The contents of the resources that are created will be criticized. There are going to be "you should have converted content x, y, z first";
• Typos and other gremlins will be overlooked. They will be caught by the person who created the resource months later;
• A programmer is needed. Their function is to create tools that are needed, but not available. Tools to simplify the process of creating the resource. Tools that verify the quality of the resource. Tools that locate errors, typos, and the like in the resource. And to fix the bugs in those tools, when they are found;
• Resource Testers are needed. These are people whose only function is to install the resource, fire up e-Sword, and check the resource. Look at what works. Look at what does not work as expected. Look at what is missing;
• Clear instructions on what is expected of each person is vital;
• Clear instructions on how to do each part of the work flow process is crucial;
• Copyright Clearance person: Their sole function is to verify that either the resource is in the public domain, or that permission to distribute the resource has been obtained, for each format in which the resource is to be distributed. You really don't want the team to spend 250 hours creating a resource, only to get a cease and desist notice saying that you can't distribute it. That is very bad for team moral;
• Team communications are vital. At a minimum, have a project management site that members can refer to, so that they know where things are. Ideally, there is:
  
  • A mailing list restricted to team members. This is where all discussion about the project occurs;
  • A publicly available calender that lists target dates;
  • An internal project management board that lists current status of each stage of each resource that the team either worked on, is working on, or will be working on;
  • A list of who team members are, and how they can be contacted;
• Do not accept every warm body that volunteers;
• The team must be free to work on resources of their choosing. This means rejecting resources that they are uncomfortable working with, and creating resources that any "sponsoring" organization is uncomfortable with. (Rephrased. If the team wants to convert The Watch Tower Library, they must be free to do so. If the team decides that they don't want to work on any content that supports Mainline Protestant Christianity, they must be free to do so.)

jonathon

[DSaw]

The Ball just stoped and appears to have sprung a leak and is rapidly deflating

[Josh Bond]

...something similar that Dr Dave does with his little band.

It would be interesting what Josh has to say about this idea.

Blessings,
Stephen (Php 1:21).

If you guys want to do something like Doctor Dave does, we can. I already run an informal "mentoring" program where I help people learn T3, where I provide custom macros/code and advice on conquering hurdles some face. There's a lot that goes on outside of the message board.

I'm rather new to this arena, but I like the idea. I've been thinking it would be great to have guidelines, best practices, and tips formally documented all in one place, which could be one of the projects that this guild pursues.

The most beneficial thing we can do is arrive at a set of module standards--which would mean making them the way Rick Meyers does.

For example, Rick's modules always have size font 11 for the main text of a Bible, Commentary, etc (headers are bigger of course, but the main text should be 11.) Formatting issues like this are critical. Why? No one wants to resize their Bible view or their commentary view because your resource uses font sizes that are above or below e-Sword's official resources.

Greek or Hebrew should be in Titus Cyberbit Basic font, blue colored, and a little larger for easier reading. A module should have adequate white space between paragraphs (either a line break or paragraph spacing afterwards) but not too much spacing (multiple lines). Modules shouldn't have "OCR" line breaks at the end of lines that aren't the end of paragraphs. There are some "tricks" to working with Hebrew/Greek in T3 so that Greek/Hebrew appears correctly on all computers. Topics should use e-Sword's topical categorization (not a whole document crammed into one topical category).

---There's a whole quality assurance list we could make that every module maker should strive for. I'm all in favor of publishable quality resources, which is something Dr. Dave and I couldn't agree more on.

What I'm not interested in is running a top-down organization with a lot of bureaucracy. I founded BibleSupport.com on the basis of simplicity and "let's get this done" not "let's make this complicated". (You'll notice my moderators do lot more "doing" than "talking". It's worked well. I despise large bureaucracies, long meetings, a "committee" for every decision, and the mindsets that lead to that. I had enough of that when I worked for large companies that specialized in such. This should be fun and we keep it fun by keeping it simple). You don't work for me and I don't won't want you to work for me because I'm not paying you. Therefore, it's all volunteer and you work on what you want to.

A group effort would work like this: when a large project comes along and we're on the same page as far as formatting, then we can split it up and each person take a portion, complete it, and then take another portion as their schedule permits.

[DSaw]

The most beneficial thing we can do is arrive at a set of module standards--which would mean making them the way Rick Meyers does. For example, Rick's modules always have size font 11 for the main text of a Bible, Commentary, etc (headers are bigger of course, but the main text should be 11) Greek or Hebrew should be in Titus Cyberbit Basic font, blue colored, and a little larger for easier reading. A module should have adequate white space between paragraphs (either a line break or paragraph spacing afterwards) but not too much spacing (multiple lines). Modules shouldn't have "OCR" line breaks at the end of lines that aren't the end of paragraphs. There are some "tricks" to working with Hebrew/Greek in T3 so that Greek/Hebrew appears correctly on all computers. Topics should use e-Sword's topical categorization (not a whole document crammed into one topical category). ---There's a whole quality assurance list we could make that every module maker should strive for.

YES we need this

[Live4Jesus]

The Ball just stoped and appears to have sprung a leak and is rapidly deflating

No josh wont let this degenerate into the old esword users site. He has already proven the "failed experiment" was just run wrong.

[Live4Jesus]

A group effort would work like this: when a large project comes along and we're on the same page as far as formatting, then we can split it up and each person take a portion, complete it, and then take another portion as their schedule permits.

And some type of proof scanning system on the big projects?