Before we begin getting into detail about things, we need to go over the basic concepts behind the BMLT.
The BMLT is, first and foremost, a meeting search. It is designed to help people find NA meetings. It is not a Group search. NA Groups are Service entities, and may actually represent a number of meetings. NA meetings are regularly scheduled singular gatherings, managed by NA Groups. In many cases, one Group corresponds to one meeting, but it is not uncommon for an NA Group to hold more than one meeting.
The BMLT is designed to handle meetings that gather on a once-a-week basis. If a Group has multiple meetings, each meeting will have to gather once a week, and will be listed individually. Special event meetings, or ones that meet on a less frequent basis, cannot be handled by the BMLT.
For this reason, meetings are tracked by weekday and start time. Other "core" aspects of a meeting include location, duration, the Service Body that serves the meeting (this allows us to appoint Meeting List Editors to administer the meeting), the World Services ID (if it has one –this is meant to help relate the meeting to its analogue in the NAWS database) and the principal language of the meeting. Pretty much everything else in the meeting is "optional."
A critical aspect of the BMLT is that meeting locations are described by a longitude/latitude pair, not an address. In fact, the address is optional.
Since the meeting search is, at its heart, a geographical search, the geographical location of the meeting is a very important piece of information. This is especially important for rural areas, or areas in which the mapping services have issues with accuracy (usually rural areas). It also affords having exact locations for meetings that gather at places like beaches or parks. As you will see, you can actually drop the meeting marker exactly in front of the door you enter to get to a meeting.
The BMLT employs a structure in which there is a central "root" server, and numerous "satellite" servers. The root server is where the database is kept and maintained, and is relatively complex; involving a lot of files. The satellite servers are extremely simple implementations (usually only one or two PHP files) that are easily installed onto other Web sites. These satellite servers connect to the root server, and request searches from the root server. This encourages the use of the BMLT by cooperating Service Bodies, and encourages more people to get involved in Service, because they don't need to worry about the whole server; just the little part they control.
If you are a root server administrator, then you will probably be called upon to help satellite server administrators set up their servers. Not to worry. There's very little involved. Setting up a BMLT satellite server is almost ridiculously easy. Satellite servers can be heavily customized, but that is really up to the administrator of the satellite server.
The BMLT was designed to allow a great deal of flexibility and adaptability. It's designed to be something that can be implemented in regions with differing demographics, languages and aesthetic tastes.
For example, most elements of a meeting's data are stored as "optional" fields, that can be fitted to the needs of the hosting Service Body or geographic location of the meeting (for example, "borough" doesn't make sense in rural areas, and "county" isn't necessarily useful in an urban area). Formats can be added, changed or deleted,with some effort, the server can be localized into different languages (every bit of text that is displayed can be changed to fit a different language, or even use different terminology), and it is possible to make quite substantial changes to the appearance of the BMLT with CSS.
The BMLT is fairly "database neutral." It has a layer that allows a number of different SQL databases to be used, so you aren't limited to just MySQL, which tends to be the standard.
Every edit action in the BMLT is recorded by a change entry in the database. The entry records who did what, when, and to what. The entry has a "before" and "after" "snapshot" of the format, meeting or Service Body that was changed. Currently only meetings allow direct access to this, as you can "revert" a meeting to the state it was in just before a change was made. You can also "undelete" deleted meetings.
This also means that mistakes are pretty easy to correct.
Future versions of the BMLT should allow access to the change records for formats and Service Bodies, as well as a comprehensive set of tools for generating reports. The data is there, we just need to write the code to get at it.
The BMLT establishes a "Service Body Hierarchy." This means that any given Service Body can have a "parent," and it can also have "children." The main reason for doing this, is so that users for "parents" can affect meetings in "children" Service Bodies. It follows the traditional NA Service Structure, which is Group -> Area -> Region -> World, and even allows secondary relationships, like Metro Areas and Zonal Forums.
Service Bodies are able to be "nested" into other Service Bodies. For example, an ASC may have a number of Groups within it. Each of these Groups has several meetings. It is possible to have an ASC Meeting List Editor able to edit any of the meetings for any of the Groups, but each Group can have its own Meeting List Editor that can edit only the meetings for that Group. A Regional Meeting List Editor may be able to edit all of the meetings in all of the Groups in all of the ASCs within that Region.
There are no "rules" as to the hierarchy of Service Bodies. Any Service Body can be a child of any other Service Body. Just because a Service Body is listed as an Area, doesn't mean that it must always be a child of a Region. It can be a child of another Area, or even a Metro Area. However, we HIGHLY recommend that you strive to keep these relationships simple, as complex interrelated Service Bodies can mean that no one is exactly sure who is allowed to edit what.
The BMLT has been designed for use in a shared environment, with a number of different administrators logging in and making changes. It allows each administrator to be assigned a specific "scope," where they can only edit certain things.
The meeting editor has been designed to allow meetings to be edited in place. This means that, instead of going to a special search, you use the standard meeting search, and are able to edit meetings for which you are authorized. This is a fairly natural way to do it. For formats and Service Bodies, you need to use a separate editing area.
This means that you are required to login whenever you start an editing session. Your login will not be remembered after you quit the browser. However, as long as you have not quit the browser (even if you have gone to other sites), you will still be logged in as an editor. This is a basic security measure, and means that shared machines (such as library, business or school computers) can be used for editing.
Administration can ONLY be done on the root server. You cannot administer the server from a satellite server. This means that any administrator representing a satellite server must go to the root server to make changes. This allows greater security, and makes it much easier to implement a satellite server.
As a BMLT Server Administrator, you have great power. With great power comes great responsibility. You have the ability to go into any meeting, format or Service Body, and totally cheese it up, so be careful.
You should also be the "go to" person for helping users and satellite server administrators set up and maintain their servers. You should be prepared to help clean up any messes, and assist them in "learning the ropes." You should have the Root Server URL ready to give them (this is the URL they need to enter into their satellite server administration page), and it would be a good idea to become familiar with how Google Maps Works, especially the API Key. You are likely to be called upon to assist people.
Just because you can, doesn't mean you should. It's probably a good idea to establish a policy in which the Server Administrator doesn't edit any meeting data, and restricts their editing to the creation/deletion of users and Service Bodies, or the editing of format codes. The rest of the work should fall on the shoulders of the Meeting List Editors and the Service Body Editors.
In some cases, you are likely to be called upon to reset someone's password. We don't (yet) have a "forgot password" feature in the BMLT, so it's up to you. Make sure that folks can contact you.
Again, just because you can, doesn't mean you should. If, for example, you are a Regional Service Body Administrator, you should probably not edit meetings. If people request meeting changes for their ASC meetings from you (and they WILL), then you should send these requests to the appropriate Meeting List Editor. If the Areas have designated the Region as their administrator, then you should not edit meetings with the main Region Service Body Administrator account. Instead, set up a Meeting List Editor account to do it. You may want to set up separate accounts for each Area. It's up to you.
Now that we have the basics down, let's start looking at the "nuts and bolts" of administering the BMLT.